Software development: Quick fix or long term solution?

The most important word you can say to a customer is 'yes'. Yes, we can do it within budget. Yes, we can do it to your specification. Yes, we will deliver on time.

The other, equally important but often forgotten word is 'no'. Don't be afraid to use it. 'No' there is too much scope for us to deliver a quality product in the available time. No, we cannot give an accurate estimate until certain scope is pinned down. No, although you want this functionality, the public at large will not understand it and it will cause the website to confuse them.

There is a balance to be struck. I've worked on a large number of projects over the years for a wide variety of organisations where project managers were a lot keener to say "yes" than they were to say "no". These are symptoms of the industry as a whole where projects are cutting corners for testing, there are over running budgets, and a failure of large scale projects from Taurus (500 million pounds) to the national firearms register and no doubt the national ID register too. The Scottish Parliament Project has become so well known it is now used as a case study in management classes.

However, on a more subtle level there's another balance between the apparently successful project which meets the customer's needs but which is achieved at the expense of longer term goals.

We're all happy to bend over backwards to meet the customer needs on a project by project basis, but I have a saying that seems to be gaining in popularity particularly amongst those who deal with the longer term effects and it is that if you bend over backwards enough, you eventually break your back.

The problem is that many projects are delivered on fairly tight timescales to limited budgets and when the project development costs are quoted, the overhead of long term planning and strategic development can easily be sidelined and this simply stokes up problems for the future. Too many quick projects layered on top of one another adds quick fixes on top of quick fixes and the whole infrastructure starts to snowball in complexity, bugs increase, testing time increases, performance can suffer and team morale declines.

Time to take a time out and say where to we really want to be with this infrastructure and what do we need to get there? This shouldn't be a big bang every 4-5 years where you go through a massive, expensive rework and address all those "quick" fixes, it should be an ongoing process as part of each project so that the problems don't pile up to haunt us down the road.

My concern is that this has been problem has been a recurring theme for more than 20 years. Today, as we move to an increasingly Agile development, quicker development cycles and faster development environments (e.g. Ruby on Rails instead of Enterprise Java) we need to work harder than ever to ensure that the mistakes of the past do not get worse as we adopt these new techniques.

In the new world of agile development, are we doing enough in the strategic corner or are we simply stoking up more problems in the future for the sake of a quick fix?

Craig