Title: Professionalism in programming

The team is working together to finish the construction work. Not only do they have the target in sight, they must reach it within certain time constraints. It is part of the building work specification that it will take a certain amount of time to create.

There is a frighteningly strong parallel with 'building' software here. How many large constructions take longer than expected to complete? How many programs are delivered on time?

Someone (or rather, some company) will have contracted the builders for the work. They do this because the builders are skilled at building where they are not. The construction company specialises in construction. Their reputation is based on the quality of their building work.

Once the building is complete there are users who will occupy it and use its facilities. The building has been created to serve a specific need.

All software is written for users for a purpose. In many cases the 'customer' for our software may be another part of the same company (many commercial banks have huge software teams working on their electronic infrastructure). However, a particular development team is commissioned to do a set piece of work for a set purpose.

There are many people involved in the building's construction, and each one's work is important. The building would not be completed if they did not do their particular piece of work.

There are different roles within the team. This is a natural thing and boosts productivity (as first observed by the Scottish economist Adam Smith). Each member of the team is skilled in a particular field. They each play a different part in the creation of the final product. They have each been trained to do their task, and their skills improve with experience.

There are the architects who envision, design and specify the building being constructed. They need to write detailed plans to convey their vision to those who are going to implement it.

There are the builders, the plumbers, the electricians who do the building work. There may be many people working in these roles (depending on the size of the construction) organised by a manager.

In software we too have architects, whose blueprints are the software specifications. Programmers implement these specifications - paralleling the builders, plumbers and so on.

If a builder has architectural skills, it is not appropriate for him to ignore the plans and rearchitect his allotted piece of work. That is more than incorrect practice, it is downright dangerous. His work will not fit in to the overall building plan. When someone comes back to maintain the building, it does not match the architect's plans. The rearchitected work is unlikely to fit properly with adjoining bits of work - this may lead to structural weakness. The building will lack the overall consistency of the single architect's vision.

The foreman is the people manager. He looks after each person's role, and ensures that the work is progressing to schedule. He, along with other managers take responsibility for the work being undertaken - both in terms of quality and timely delivery.

Building work cannot proceed without the necessary raw materials. This is in addition to the requisite amount of time and labour. Without the building supplies, the building simply will not be possible - it's hard to build a wall without bricks.

Without the electricity, computers, test-equipment, bought-in components and so on, our work would not be possible.

The hods and JCBs of our trade are our compilers, our IDEs and our software libraries.

If each team member works harder and tries to produce their work to a higher standard, exactly to specification, then the overall building will be of a higher quality. Each team member needs to contribute to the best of their ability for a truly successful outcome. Good software depends on good software engineers skilled at their tasks. A programmer who writes non-future proof code will diminish the overall quality of the end product, even if he is only working on a small part of it.

But, of course buildings are different from programs. (And you do not see many programmers revealing their 'bum cleavage', do you? If you know otherwise I do not want to know about it.)

Buildings cannot really be developed in an iterative and incremental manner. Any change to a building's specification will result in costly demolition prior to rebuilding. In our world of 'pure thought stuff' we can tear down and rebuild with very little material cost (but with the costs of time and labour). In software we are better able to build abstract interfaces between certain software blocks. The engineering discipline is different, but that does not mean we cannot learn from the parallels with other professions.

Teamwork is dead without communication. The parts cannot move as a whole without communication. How can the goal and vision be shared without communication.

Projects really do fail because of a lack of communication.

Inter-team communication occurs in several ways: conversations between individual engineers, phone calls, meetings, written specifications, email correspondence. Each has a particular dynamic and use.

Communication should involve (or at the very least be visible to) all relevant parties. It should be sufficiently detailed, but not consume too much time. It should be performed in a suitable medium - for example the recording of design decisions should be in a specification, not by word of mouth.

In addition to inter-team communication there is also the important aspect of communication between teams. The classic exemplary scenario of bad communication in practice is between a company's marketing department and its engineers. If marketing do not ask the engineers what is possible they will sell products that the company cannot make. This kind of problem is cyclical: once it has occurred once, the two teams are less likely to talk to each other (due to resentment) and it will just happen again and again.

This is an essential characteristic, and often the most lacking in our profession.

You cannot want to hoard all the work for yourself - it is just not possible for one person to do everything. You have to be willing to let another team member contribute - even if it is something you want to do.

Humility also implies actually wanting to make your contribution to serve the team, not slacking off to let others do all the work. You should not only listen to the opinions of others, but also value them. Yours is not the only solution. You do not necessarily know the only, or the best way to solve a problem.

We have to be realistic: some people cannot help grating against each other. In this kind of situation, we have to be mature and responsible in our attitudes, and learn to resolve potential conflict situations. Conflict and animosity severely degrade the performance of a team.

This does not just mean learning new technical skills, but learning to work as a team. It is not always a God-given gift.

Ask yourself what can you gain from your peers? Learn from what they know, learn from what they are like, how they react. Learn to communicate with them. Seek criticism from them at all levels, from the formal code review to their passing opinion on something your thinking about.

Good teamwork builds the project and also builds the team. Part of building up the team is for each member to be learning as they work. For this to happen each member should seek to share their skills, where appropriate.

This is tied closely with learning.

If the team has a need no one can currently fill and doesn't have the ability to bring in an outside resource a solution needs to be found. Adaptable people can learn the new skills quickly to be able to fill the need and serve the team. It can also be beneficial for them to learn the new skill.

If you commit yourself to perform a bit of work that you know you cannot do, or later find out that you do not have the skills to complete (and you cannot realistically learn them in the given time scales) then you should make your manager aware of this as soon as possible. Otherwise, you will fail to deliver your piece of the project and the whole team will suffer as a consequence.

Many people see admitting that they cannot do something as a weakness, but it is not. It is better to admit your limitations than to be a point of weakness in the team. A good manager should provide some extra resource to help you do the work, and along the way you will learn the new skills that you previously lacked.