7 Strategies Software Development Processes Must Define

In my previous post, I talked about the necessary flexibility in a software development process. There are different needs in different teams and projects, and the process needs to be flexible to adapt to those needs. I like to think about processes as a set of guidelines as opposed to a set of rules, but those guidelines need to be categorized in groups of strategies. Today, I will talk about what strategies you need to define for any software development process, no matter how simple your project or small your team is.

1. Source Control Management.

No matter how small your team is or how simple your project is going to be, you need a source control management strategy. Simple projects tend to be come more complex are changes are required, and changes always happen no matter how simple the project once started.

You need a strategy to manage changes in a project and understand who made the change, what was changed, why was changed, and how was changed. A source control management strategy will provide the information you need to manage changes and understand better the evolution of your project.

Even if you are a single person team, and you think you do not, you do need a strategy to manage your source, you do. Notice I am saying you need a strategy not a system. Keep in mind, I am not talking about a source control management system, which is a tool that can help you, but a strategy that you must follow to understand the changes in your code.

2. Documentation.

Any project to be successful needs a strategy to document the project. The level of documentation created might change depending on your actual needs, but any project, even a single person project needs to define a strategy for documentation.

What the project does, how was implemented, and why was implemented in that way might be very clear while your mind is deep involved in the project, but it only takes a few days after the project completion to forget a huge chunk of what was done.

Documentation will help you to remember. It will also help you with the maintenance of the project, and as a tool for new members of the team to understand your applications.

Again, I am talking about having a strategy to document your project. I am not suggesting a particular way of doing it. How you do documentation will change depending on your needs, but always keep flexibility in mind.

3. Automated Build Process.

Any software development project will produce a set of deliverables that will end up in a user machine in a way or another. An automated build process will help you to generate those deliverables faster and more accurately.

Manual processes are error prone, and we tend to make more mistakes when we are working under pressure. You do not want to risk a manual mistake the day you have to provide your customers with your final product. An automated build process will help you to deliver your project faster and insuring no manual errors were introduced during the production of your application. It will save you a lot of hassle, especially in the final stages of your project as you get closer to release date.

4. Coding Standards.

I have read many things in favor and against coding standards. What I usually see is that people against a coding standard do not really understand what a coding standard is, and that misleads them to think they are not necessary.

When I talk about coding standards, I am not talking about where you should place your brackets or what level of indentation you should use in your code. It is not about whether you should use the TAB character or spaces when indenting code. Those are very personal preferences, and that is why there are so many arguments about them and no real consensus.

A coding standard should define the guidelines and idioms to be used while writing the code. A coding standard can help to decide, not dictate, whether something should be implemented in a way or another, and it usually eases the understanding of the code by all members of the team.

5. Testing.

How your are going to test your code at the different levels is one of the most important decisions you need to make to make sure your project is successful. You must define a testing strategy that accommodates the different levels of complexity in your project, from unit tests for low level functions, methods, and classes, to system tests that prove the application as a whole.

The sooner you start testing, the better. The sooner you define your testing strategy, the sooner you can start testing. The better you define your strategy, the more chances you have people will follow it.

Testing is the best way to find defect in your software, and the faster you find those defects the easier it is to fix them. Never start a software development project without a testing strategy in place; otherwise, by the time you start testing, it might be too late, and your project will go out the door without the quality customers expect.

6. Code Reviews.

Code reviews are very important, not only because they provide a way to catch defects soon, but because they also serve to keep people informed about what is happening in other parts of the application.

They are also an invaluable resource when it comes to coaching and mentoring less experienced members of the team. The experience a new comer can acquire from a more experienced programmer through a code review is invaluable. Code reviews will help your team to gain experience, to do things better, and to understand what is going on.

Your code review is tight together with your coding standards. The review process should insure your coding standard guidelines and idioms have been follow, and should stretch the importance of following those guidelines and idioms.

Do not underestimate the power of code reviews. I know they take time and are a real pain. That is why you need a code review strategy that adapts to the needs of your team.

7. Communication.

The way your team communicates is of high importance on any software development project. Establishing a strategy to communicate within the team is important to insure all communication is as efficient as possible.

Many software projects have failed because of lack of communication. In today's world, there are many ways you can communicate, all of them have their strengths and weaknesses. It is important to define which way we will communicate under which circumstances, and your team most be clear on the communication protocol.

There are many reasons why people do not communicate with others. There are also times where people communicate too much in a highly inefficient manner. Your communication strategy should be clear so everyone understands it and uses it in the best possible way.

These seven strategies are indispensable in any software development process. Unfortunately, sometimes we do not think about them way in advance, and by the time they cross our minds is more difficult to implement them.

In subsequent post, I will dive more into each of these strategies to make very clear what I really mean about them and why I consider them so important. Let me know if you find I am missing some important strategy or if you disagree with any of the ones a expose.