A recent post over at the 37signals blog got me thinking about the importance of careful planning in software development. The 37signals folk are quite strongly in favor of agile methodologies in software development, repeatedly pointing out the value of releasing software early without a full set of imaginable features.
The projects they work on are such that the cyclical process in which the software is refined over several iterations of the develop-and-test-cycle (with several steps thrown in) doesn’t cause any problems. In fact, rapid prototyping in these cases gives the testers (internally or the users at large) something to play around with and offer feedback on, often refining the user interaction from what was originally envisaged.
A definition of Agile (or Xtreme) Programming points out that it’s a methodology better suited for situations with unknown or unstable requirements as changes to the requirements are to be expected during the development of a product. More rigorous change management is better suited for those situations in which the requirements are defineable at the projects initial design phase.
While I agree in principle with the separation of when the two different approaches to change management are to be used, I’d like to see more discussion on how to balance the use of agile programming and rigorous change management. I argue that most applications that aren’t limited to trivial input/output data scenarios have areas in which there are initially unknown requirements and well-defined requirements. Especially applications which require user1 interaction have undefined requirements which may change as prototypes are tested by the actual users of the program.
For example, the intranet application that I’m working on at work has quite a bit of well-defined unchanging requirements. After all, we’re using nationwide agreements on how to calculate salaries based on daily and weekly amounts of hours worked and how the date and time affect the modifiers of such calculations. But at the same time, the business logic of the application has been very poorly defined. In fact, I’ve found that the choices and decisions I made to establish a prototype from which to start off, have defined the way the organization works.
My biggest problem with an approach to software development that encourages rewrites is that tried and tested code may be deleted and bugs reintroduced. Especially when security is an issue, rewriting tested code shouldn’t be the first approach to refactoring. Or then the rewrite needs to be planned and well-designed to utilize the important parts of the tested code.
Of course this doesn’t solve the issue in which you need to rewrite the tested code because changes over time have made it into a spaghetti-like tangled mess. Ideas on how to solve this dilemma are well appreciated here, I’m in that awful place right now at work.
- Yes, I do talk about users. Especially when developing a product that will have a defined set of people using it, users is a term that is actually beneficial. And it doesn’t mean that I’d think of users belonging to a different set from people.