Coding Best Practices

I l @ ve RuBoard

Over the last few years , Extreme Programming has developed some excellent best practices for the coding of software that apply very well to Web site development. These include the following:

• Learn to love an onsite customer.

• Write code to agreed standards.

  Balancing the creation of unit tests and code keeps the project from falling.

  

• Code the unit test first.

• Use paired development.

• Stick to continuous integration.

• Leave optimization until last.

• Avoid overtime.

Each of these practices will increase your productivity and the quality of what you produce.

Learn to Love an Onsite Customer

Much of what has been written about XP is targeted to internal IT departments, with the goal having a member of another department on the team. Imagine that person coming from another company altogether, with the added worry that how you are seen by her could affect the future of your company.

Certainly nothing in XP Web projects has been more resisted than working with an onsite customer. Having the person you have tried to impress so much in the sales process see how you actually operate can be alarming.

True, it is very frightening at first. But once the customer is in the group you will find that he is not a spy and that he has the same goal that you have. Any secrets he uncovers, like the fact that your company is a little smaller than you led him to believe or that your experience with a language is less than expert, are going to be less of a problem than you believe. We have found that customers are only going to care about one thing ”can you do the job. If you can't, they are going to find that out, and if you can, they won't sweat the small stuff.

An onsite customer learns the processes, whereas one at arm's length never does. Also, understanding how you work, and what this work is, will make her a more realistic planner and far more accepting of the costs involved.

The final argument for an onsite customer is the efficiency she brings . Having someone there to approve a design, explain a business process, or suggest a way around problems drives the project faster.

Write Code to Agreed Standards

Far too many hours are wasted in trying to figure out what a programmer has done because code isn't in tabular format, or even trying to find where the graphic designer has saved headers or buttons . For this reason it is wise to develop a set of standards for coding, naming conventions, and directory structures. Make sure that you have a consensus on these standards before you start and then stick to them.

Code the Unit Test First

Writing unit tests is beneficial for many reasons, one being the great help they provide with the actual writing of code. Unit tests are an excellent tool for breaking down each programming task into "To Dos." Once you have finished your "To Dos," you will have finished your task.

Use Paired Development

Paired programming builds trust within the project team as well as between your company and your customer. Moreover, it increases overall skills development and speeds the work along.

Leave Optimization Until Last

According to XP you should always wait until you have finished a story and run your tests before you try to optimize your work. Only then can you analyze what exactly it is that needs optimizing. Don't make work for yourself by trying to anticipate problems before they exist ”wait until you have the results of your analysis before you focus on resolving whatever issues arise.

Avoid Overtime

Avoiding overtime is as relevant to Web projects as it is to software. Everyone knows that you can never do your best work when you are tired or burnt out, because you are much more likely to make mistakes and you become less efficient, taking longer and longer to complete tasks .

If you're sleeping at your desk, something has gone wrong!

If you find that you are putting in a lot of overtime, something has gone wrong in the planning of the project. If you have taken on too many stories, don't try to make up by working more hours. Instead, defer a story to the next iteration. Don't forget that the customer has agreed to an estimated number of hours, so overtime will affect her budget.

I l @ ve RuBoard