Sunday, December 16, 2007

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.

Thursday, December 13, 2007

Process: A Set of Guidelines Not Rules

Who has not heard about the waterfall model, extreme programming, or agile software development. Many books have been written and speeches have been given about these topics. News articles, success stories, and web-sites appear all the time about them (well, less and less about the waterfall model, but this is besides the point of this article).

Processes give you the set of rules your team must follow to insure project success. They keep everyone in the team on the same page, and insure things are done according to the guidelines. Or at least, that is the idea.

The problem with any software development process is that one size does not fit all. People are different; projects are different; company cultures are different. What worked for you does not work for me, no matter how hard I try. The ideas are good, but the rules are too tight to fit my needs.

Team dynamics evolve as team members change, as people learn how to collaborate with each other, and as experience is gained by the team. We cannot pretend to keep the processes static while all this evolution is going on.

If we blindly follow rules, we will not see what we are doing wrong. It is easier to blame people for their mistakes than to understand what went wrong and how can we prevent it from happening again. Rules always tells us who to point our finger to, but they would not solve our problems when mistakes happen, and mistakes always happen, no matter how much experience we have, how well our rules are defined, or how hard people work to follow them.

Does that mean processes are useless? Not at all. It means that processes to be successful need to be flexible. It means that we always have to keep an eye on our process and improve the things that are not working. It means that we need to learn from experience.

But what it really means is that rules hardly work. Guidelines work much better. When implementing a process, you need to evaluate your situation and make the necessary adjustments. Do not underestimate your team members and what they believe it will not work because they would not follow rules they do not believe.

Your team probably knows as well as you what needs to be done. All they need is a set of guidelines to coach their decisions when confronted with tricky situations, and open communication will solve more issues than any written rule, even if is carved in stone.

When you read or hear about a new software development process always think: Processes are good. Now, how can I adapt this process to my environment? Embrace change, but do not force changes without consensus. The people in your team are more important than the processes you intend to follow. they are the ones that will have to do the work, so listen to them and adapt your process to their needs. Keep people in the same page by letting them buy into the book, and everyone will be happy.

Monday, December 3, 2007

Hello World

Welcome to the developer's corner! the place where I intend to share my views about software development and use it as a point of contact with other developers, programmers, hackers, or code writing hobbyists. I hope you get to enjoy my postings and that we can get into constructive discussions where we all can learn about each other's practices.

This is my "Hello World" in blogging, and I hope to learn the ins and outs of it to make this practice more joyful for all of you. Your comments are more than welcomed and all criticism within the normal guidelines of politeness and respect is accepted, and I will do my best to reply to all of you who live me a comment as time permits.

And since good things when short are twice as good, here I end my first post, and I will see you soon with something more interesting and that hopefully will open a debate.