Chris Johnston

For the past year I have been involved in creating a piece of software where I work. Some parts of this process have been really good and other parts have been really bad. Since tomorrow is my last day, I decided that I would try and capture some of my thoughts stemming from that process and some of the things that I have observed and learnt.

Test-Driven Development

Over the past year I have definitely developed some very deeply held views on how to properly create software. Probably the strongest of those ideas is in the area of test-driven development. After using this method to create my own software and watching other developers go through the process to create their software (okay, we forced them to do TDD) I am strong believer in this method. Not only does it give you the regression test suite requried for proper refactoring and maintenance, but it also forces developers to really think through their designs and their understanding of what their software is suppose to do. You can not create a test if you do not truely understand what a method, object or component is suppose to do.

Planning and Design up Front

Another thing I have seen is what happens when proper planning is not done. For this I am refering to both the proper gathering of requirements and the design of the software up front. Now, you may be saying that this sounds a lot like a waterfall method, but it isn’t. I am not saying that all requirements must be done before development can start, nor am I saying that all the design work must be done before development saying, but I am saying that a lot of requirements must be known and a lot of design must be done before developers start to code. This is both at the architectural level at at the class diagram level.

In order to properly development software, you need to think about that software, you need to design the software and you need to understand what the software is suppose to do. However, you also need to be flexible. At no point in time should the design become cemented or carved in stone. It should always be fluid and open to change. The initial design is simply a path leading you to the final product instead of a blueprint of what the final product will look like. But without that initial planning, that initial path, how is anyone going to know which direction start in and if that is even the right direction to begin with.

I disagree with the XP people on this that just a little planning should be done up front, I think a lot of planning should be done up front and the more planning and design that you do up front, the less time will be wasted later on with course corrections. If I had to boil this all down into one statement it would be:

prototype early and often

In my mind at least, prototyping your software is as much a part of design as UML diagrams and test plans are.

Keep your team small

My last observation is related to team size. I firmly believe that a small well oiled experienced team is far better then a large team, regardless of the skill level of that team. I definitely think that a small, agile team of developers will be able to accomplish a lot more then any large team. And by small I mean 5 developers or less, preferably less. However, as a corrolary of this, the team must be given the freedom to be agile. They must be given the freedom to work on all the code, the freedom to have the code owned by the entire team, and the freedom to work and organize themselves according to their rules. This means that the team decides who should work on what and who should do what as opposed to managers imposing these roles onto the team.

It does not take a small team to figure who should be doing what. And not everyone is going to be good at doing everything. Some people are really good at the initial design and upfront coding while others are good debugging and integration while others are really good at creating documentation. But the team needs the freedom to figure these roles out for themselves.

I think that is enough for now. As more thoughts come to mind, I try and record them. I don’t want to loose these observations as I have learned a lot about software development over the past year. My only regret is that most of what I have learned is in response to it being done poorly instead of it being done well.