Software Development – Waterfall, Agile or Cowboy coding?
Jan. 22, 2008 by ravishan
Hope all of you enjoyed the football games last Sunday. The upset by Giants was the most amazing and I just could not believe that there were people out in the field with bare hands and exposed faces at -4 deg C (windchill of -24 deg C). When the Giants missed the field goal with 4 seconds to go, I thought here we go… the magic of Lambeau Field somehow coming into play. But, they persisted and we have a replay of the game that Vivek and I saw on Dec 29 at the Meadowlands…
Patriots didn’t have a great game, but who cares? It is all about bottom line. One could see how they never panic… It is apparent that they are managed extremely well and execute with precision and most importantly they change course as the game develops.
Several of my friends in software industry talk to me about what are some of the hot topics in software development these days. Increasingly, I am hearing about Agile software development from everyone I talk to. So what is it?
You can read about this and other software development techniques that the computer scientists have formally defined, in Wikipedia. In simple terms it is the practice of breaking up a large project into smaller ones each with requirements definition, coding, testing etc. built in. But, by breaking them up in such smaller chunks, the goal is to release intermediate versions of software quickly to the users. The key here is to make sure that everyone including the users are on board with this and to have very strong communication all through the process.
Those of you who have worked with me will already relate to my preference for this model… I just discovered that it has a name and it is called Agile software development. Now I can tell my friends that this is what we have been doing for quite some time. Many of the electronic portfolio (including the portfolio itself) applications followed this path. In simple terms, we begin with the bare minimum functionality that the application requires and create data structures anticipating the future enhancements as much a possible. Then, after we roll out the application, add new functions, some are requests from the users themselves.
The other model, called the waterfall model, is to follow a rigorous sequence and when one phase is done, you move to the next one. If the requirements change while we are designing, then we either decide to go back to the drawing board and start over, or the new requirements are collected for consideration in the next major revision. The large administrative software projects fall in this category because without this discipline, they cannot succeed. Besides, the return on investment for going back and reworking will be huge.
Of course, then we have the cowboy coding… roughly defined as team members do whatever they feel is right. We don’t have this, right???
In the end, we do an excellent job overall. There are little bumps here and there, but with the checks and balances we have in place and with the collaborations that are going on, we deliver excellent software which is the envy of our colleagues in the other institutions.
It is also the case that our software projects are somewhere in between agile and waterfall on the administrative computing side and between agile and cowboy in many others… As long as we make the cowboys agile every single time, we are in business…
Technorati Tags: Agile, Software development, waterfall model
Here is another opinion about agile programming. In cryptography, there is a principle that says your encryption needs to be as strong as your data is valuable. Similarly, in software development, your process needs to be more formal as the complexity and importance of the project increases. For relatively simple portfolio applications, the agile method can work very well, if we keep good coding practice.
As the comic points out, rapid development does not mean we can ignore classic coding rules of thumb: database item, variable and subroutine names should be meaningful; comments should be plentiful, especially in perl, where syntax can crazy very easily; subroutines should be small – no more than 100 lines or so; don’t copy and past code – abstract it; and test, test, test!
Failure to adhere to coding discipline causes the Big Ball of Mud problem, where maintenance becomes and ever increasing problem. What we need are sheriff coders to keep the peace by going after the meanest code creations and either rehabilitate them through isolation and rework, or as a last resort, get a posse together and hang ‘em high.