Our leaders are doing it – spending large sums of money now bailing out banks with the assumption that one day, when the recession is over, that there will be someone to pick up the tab. And as individuals we are doing the same thing – if my boiler were to need replacing tomorrow I may forgo the top-of-the-range model with a four year guarantee in exchange for one half the price that may require some maintenance after a year or two. People have stopped buying cars with the free maintenance and reliability that is worked in to the price, instead preferring to spend less money now keeping their old car going. Across all levels, commercial decisions are made differently to how they were a year ago and deferring costs until the next financial year (or until after the recession) is fashionable and makes business sense. Cash and liquidity is king and the future is uncertain – something best left for the people in the future who can (or are forced to) deal with it.
As software professionals we are selling our services, be that as an organization or and individual, in the same market and we have to be aware of the cold hard realities of how decisions are made and how we can tweak our pitch in order to get buy-in. Regardless of what you believe, you have to imagine that last years’ slide deck that you used to pitch a new project to business is as out of date as a glossy brochure for a flashy sports car.
Trendy software developers have recently been going on a lot about TDD, software craftsmanship, practices and principles that further the ability of software development teams to build good, reliable, fast, secure and maintainable software. A big part of the current themes is maintainability – with lots of statistics relating to the total cost of software over its lifetime indicating that the initial development costs are minimal (say30%) compared to the cost of maintenance in future. Tests are written, concerns are separated, control is inverted, things are decoupled, design is done by writing tests and refactoring is frequent – with one of the benefits being a system that can be easily maintained by simplifying navigation, understanding, breaking changes and minimising the decay of legacy code that doesn’t have tests. You have heard this pitch before in various formats (more correct and detailed than the two sentences above) and have probably given a couple yourself – to geek friends and bemused users.
Regardless of how we may feel about how our tools, skills and approaches may increase maintainability we must consider that, in most situations, that we should shut up. Your half hour pitch on the best methods and how they relate to maintenance costs may be summarised by your audience as
“We are going to spend twice as much money this quarter so that when the recession is over we have a system that is easier to fix if it breaks”.
Eighteen months ago that is the summary you would have wanted (except for the recession part) and you could move in for the kill close, prying the cash from the sponsors’ hands. Today, with the same summary, you are dead in the water and the project gets shelved.
While I don’t advocate the resurgence of RAD with its accompanying pain and suffering, I do advocate reviewing your message and making sure that it ties in with the current needs of the market. Right now, today, most businesses would rather defer expenses into next year. Today it is easier to find customers for low cost, high maintenance boilers than super reliable expensive ones. This advice, I believe, applies to organizations (obviously), teams and individuals – would you want to be branded in the office as the developer that always estimates that things will take three times longer than your peers? How is that going to impact your career when jobs are on the line?
The trick of course is to find ways to reduce the upfront costs while minimizing the impact on future maintenance. Perhaps you can come up with differentiators whereby you are able to manage technical debt in a way that is low risk and allows for it to be easily worked off in the more distant future. You should, at least, have a message that reflects that kind of view.
I leave you to update your slides.
Simon Munro
@simonmunro