I had an interesting conversation with a long time friend and fellow IT worker, Eric Moore, today. Our conversations tend to ramble unpredictably at times, and this evenings was no different.

In the course of the conversation Eric elaborated a series of connected thoughts about IT projects that hit home with me. It was not that anything he said was a new concept in and of itself, but the way he said it was what I found so compelling. I’ll get to what, and how, he said in a moment, first I need to set the stage a little.

I believe that Agile development, TDD and the other iterative approaches to development offer significant benefits over more traditional Waterfall approaches. I believe this, getting clients and employers to understand and accept the benefits is more difficult.

Over the years I have seen a familiar pattern play out in Waterfall style projects. As the project nears or completes the Verification portion of the life-cycle, one of a number of things happens.

Because of the long(er) duration of time between the Requirements/Design phases and the Verification phase in Waterfall projects as compared to typical Agile projects there is often a period of frantic redesign and tweaking during verification.

This is caused by a number of issues but a frequent cause is the fact that the stakeholders that participated in the Design phases are gone by the time the Verification phase begins.

Or, the Stakeholders were not committed to the process and did not take seriously the necessity to actually design first. Remember this fact, it becomes important later.

One way or another, by the time your project reaches the Verification phase it degenerates into a series of recriminations, “thats not what we meant/wanted/needed”, meetings, and emergency changes in order to achieve what was really needed.

Waterfall development tends to exacerbate this tendency because of the longer timeline as I mentioned before. Agile development on the other hand tends to minimize this symptom due to its short cycle iterative approach.

(Agile development can also be abused to inject continuous never ending scope creep precisely because of its shorter cycles. Keep this in mind as well, it to becomes important.)

Because Agile builds the design as it goes, with minimal requirements gathering, it usually results in delivering exactly what was actually needed. Its iterative approach allows the stakeholders to continuously fine tune their goals and design within a feedback loop that is typically very fast.

But if you are working with someone that wants to keep tweaking and tuning with no end in sight then you have entered the Agile “death spiral” and need to break out.

So no matter which methodology we use, we are often faced with a similar set of frustrations, both as developers, and stakeholders. The “Just one more thing” syndrome, or the “thats what I asked for, but it’s not what I wanted/needed/meant” syndrome.

In order to avoid these sources of frustration and project failure you need to deal with the “Economies” in software development.

Finally we are back to my friend Eric, he pointed out a general truth that applies to both IT projects and life in general.

Paraphrasing, Eric said something along the lines of. If something is free and seemingly plentiful, people tend to be wasteful and careless with it.

They will take more than they need, tend not to treat it with respect and in general not show appreciation for it. But when you make that same thing “cost” in some way, then they will tend to be more careful of it, take it more seriously, and treat it with respect. The trick is how to instill “cost” into whatever it is you are dealing with.

Design and requirements are often looked at as “free” by the business side, in the sense that they can continue to revise and expand on them, therefor they don’t really need to put a great deal of effort up front, since they know they can tweak and expand on them “once I see the product running”. In Watefall approaches that is a red flag that indicates the project is going to go over budget and exceed schedules. In Agile approaches that is expected behavior, too a point, but not when it becomes excessive.

So how do we prevent this in either method? Add cost to changes. Make the participants have to “pay” some kind of cost for making changes. This could be time or effort on their part. Have them participate in the design sessions and change sessions along with the rest of the team. Not going home on time, or loosing time in other areas of their life and work is usually an effective “cost”.

If it is a client that is making changes frequently or inappropriately, begin to micro manage their expectations. Call and email them about each and every step along the way, literally drown them in information and requests for clarification. Sooner rather than later they will realize that changes are costly to them, then you will begin to find out what is really important to them.

I am sure I will expand on these thoughts later. This is not meant to be an exhaustive comparison between design methodologies or project management and risk management approaches. Just some thoughts on the “Economies” of Software Development.

Cheers,

Robert Porter