Like all businesses, development teams have incomes and outgoings, profit and loss. We produce a product not only for our customers, but for our company (in fact, many dev teams produce only internal products) and our customers don't pay us directly, rather the company does. So, it stands to reason that the company for which we work is our customer and we must treat them as such. This is probably more just a shift in understanding and perception, rather than a radical change in the way we should actually do things, but I think it's essential if we wish to grow.
I thinks there are two main areas of importance here:
- Income and outgoings
- What the customer wants us to do versus what we want to do
- Developing what the customer has asked for
- Investing in future developments
I told you so! We gave you a cost-benefit breakdown on quick-fix versus long term investment last time and you wouldn't listen!And even rarer, perhaps:
We gave you lots of options for delivering the software you need and developing the next generation alongside, but you still wouldn't listen!Maybe my weakness is always considering how I might be blamed for shared failure, but I believe it is our responsibility to have a long term technical strategy, to plan accordingly and to manage the expectations a business has of a development team. If we don't go on record and state our legitimate fears and offer solutions to mitigate them, then we can blame no-one other than ourselves if these factors are not taken into account by those making decisions.
Take a "typical" project: the next generation app or website for your company. You know what you should do, you should "do it right", right? Re-write it, because it's so flaky now after 2 years of hacking and bug fixing and the core was based on OLD technology anyway. And there are some great new tools you could use to generate the GUI, new tools to generate automated tests and possibly even a different language you should be using now. However, the hard facts are that a polish of the existing GUI, a decent bag of new features and a big bug fix effort is probably sufficient to create a product that can start making the company money in 6 months rather than 18.
How do you make the case for what you want to do? Simple, you know why you want to do it, and it's because it's better in the long run, so just communicate this. But communicate it in a language that can be understood by the people who will be making the decision. More to the point, present options that aren't completely at odds with the goals of the people making the decision.
How about 9 months to deliver? in that time, perhaps promise to deliver a demonstrator of some of the new technology ideas you have, such that they are beginning to grow. Get agreement to commit some of your team to keeping this going out to 18 months and you'll have even more to show for it. OK, by your original "best job" projection, you won't have a finished next generation product, because you committed people to the quick-fix the company asked for, and as sure as eggs is eggs, you'll have been forced to commit staff to other projects after that. But you'll have something pretty decent to show for it. At this stage, your sponsors can start to get excited about the next generation of software that you can deliver, and this time, when they ask, you'll be ready for it. I've heard Tom Gilb talk of "front-room/back-room" development in relation to delivering successful software products using Evo, and I think this is a sound idea in terms of the business of creating software. This "Russian Doll" development department gives you control (hopefully) and the capacity to keep creating for the future, but you'll probably have to fight hard to protect it.
I'm not suggesting that this is easy by any stretch of the imagination, but I am saying that it's possible. Negotiating with your product management, sales and marketing people will be difficult, but - as I've already said - if you don't state your case, then no-one else is to blame for not knowing what you know. And as they say in the North-East, "Shy bairns get no sweets".
To wrap up, no business grows without internal investment, and I believe that to be true of a software development team, not just the whole business. It is our responsibility to ensure that our company's technology base moves forwards and no-one else's, so we must take the reigns and lead from the inside within our own team. Remember that our development teams are mini businesses and we must generate income in order to spend on what we believe is the right thing to do. A final point I would like to get across is that the person that runs a software development team has to treat their efforts in a business-like manner. Leaving all decisions about planning for the future in the hands of senior management is not as likely to produce results as entrusting it to someone fluent in the business of creating software.