Rethinking Software Development

I guess it's fair to say that most of us who are in the software delivery field are familiar with the implement->build->review cycle in software development. Regardless of the development methodology practiced, those phases will be there, with similar names or not. To reiterate, typical software development usually goes like this.

1. Implement - This is where you get a few developers to implement the functional requirements of an application. Additional activities which might happen in this phase are (re)engineering, sub system deprecations and so forth.


2. Build - Once the functional requirements are implemented, you build your application. The built application could then be used in various testing activities.


3. Review - This is judgment day for the built application. Implemented functionalities are validated to ensure they meet the requirements' specifications. Existing functionalities are checked to ensure there is no breakage. This is also the point where the stakeholders of the application decide whether to pass the current development iteration or to steer it into another one, possibly with new specifications and directions.

Pretty standard and complete? Yes, I would agree. However, if you look at it from another dimension, a few areas could really use some improvements. At least, that's true from my experience.

Most of the timelines I was fortunate enough to see have a similar pattern.

• Time available for development is short.


• Time allocated for each build usually has a duration of 1-2 man days.


• Time allocated for testing is very significant.

Immediately, a few problems stand out:

• Your developers will be racing to a close-to impossible due date. Just to ensure the implementation is delivered on time, the importance of proper design and impact weighing are reduced. That has serious consequences. There is a good chance your testers will be crushed by testing work. There will be significantly more defects with the application.


• Even a day of time allocated for application build is a waste. Building an application should not be difficult at all. The complexity of it doesn't justify for the time allocated. While I have been in situations where building the application (in effect, is really integrating the various components in the system) revealed unimaginable amounts of problems, that happened because we did not have a good enough infrastructure. More on that later.


• While it is undeniable that testing is the most crucial part of application development, that must not be represented by a huge chunk of time allocated for it. Take a moment to think. Do you foresee that many problems with the application that you need to have this gigantic testing phase? If you do, don't you think that might be a precursor of something bigger that is wrong?
  
  The testing and implementation phases have direct effects on each other. The less time you have for implementation, the more time you need to validate the quality of its outcome. If you follow that and go through each development cycle, there will always be more issues passed to next development cycle for fixing. More time will need to be used to validate the fixes... and then it goes on. The cycle is almost vicious.

At this point, you may ask, what's the revolutionary idea to solve all the problems? Well, there is none. The idea I will be proposing soon is proven. There is nothing revolutionary about it. That's what made me so compelled to share.

I still remember a joke which a friend of mine made about how a country got things done. He said, the idea of the country is.

If you can't do it with a machine, do it with 1000 men.

But what I want to say is that if you need 1000 men to do something, there is a good chance it can be done with a machine. What I'm about to propose will require a lot of changes in the development practice which I have described earlier. The time allocated for the phases in it will be completely different. How different?

• Instead of allocating the least time for development, have it to take up the largest amount of time allocated for the application delivery.


• Take some of the time allocated for the testing phase and give it to the implementation phase.


• Eliminate the time allocated for application build by introducing automated continuous integration. At least, make it really insignificant.


• Automate most of the testing.

That model gives us the following benefits.

• With more time available for implementation, your developers will be able to take the best implementation path by carefully reviewing designs and analyzing impact. This should allow them to produce better quality work, which will lessen to load on the coming phases.


• Your developers, with the time given to them, will be able to write test cases, both unit and functional. These tests I'm talking about are automated tests. Tests which are repeatable anytime to validate the application. There are plenty of technologies which the developer can use to automate the testing. I have a preference for Selenium for functional testing. It is an excellent tool to test web applications using browsers as the test agents. It is very close to human testing and it can be completed with a fraction of the time taken by a human tester.


• Since your developers are required to write test cases, application defects will be realized earlier - even before they reach the build phase!


• Allows for shorter but more frequent development cycles. Implementation is an overhead. Once the code base is ready, changing it requires dramatically less effort. With the time taken to test the application a constant (or close to), the next development cycle will almost always be shorter than the previous one. More development cycles translate to better application quality and that, in turn, translates to a happy customer in the end - what really matters.

What's your take?