Would you rather?


#insert story about Susie and nappies and painting the house

#insert software quality triangle

When someone comes and ask for a change to a piece of software, or to change an estimate that you've given, the answer is never simply, "No".  Rather, the answer should be, "Would you rather...?".  You see, any change impacts one of time, cost, or functionality.  Or indeed some combination of the three, but never none of them.

If the task needs to be done sooner, it's either going to cost you more (i.e. more people working on it, or buying a faster machine, or a 3rd party product, or something) or you can cut out some of the functionality (defer some until later, drop the gold plating etc).  But the answer is never working longer hours.

Similarly if you need to bring your costs in, you can reduce the number of staff working on a problem, but it will (obviously) take longer to complete.  Another option is to deliver less.

And finally, if you want more functionality in a release it will cost you more in either time or money (more people).  Or a combination of the two.

We shouldn't be frustrated when change happens[1].  It's what keeps us software developers in a job.  It just needs to be managed in such a way that our work-life balance isn't whacked too far out of kilter.



[1] We should remember though, that The #1 cause of project failure is Requirements Volatility.  It's good to keep that in the back of your mind whenever a change request comes along.

Comments