Treating the Development Department as a Business Within a Business

I've come to realise lately that no-one is going to sort out our problems as a development team for us. Seems a bit obvious, but let me elaborate a little. What I mean is that no-one is going to reconcile the challenges we face to produce software on demand while planning and developing for the future. In fact, most people outside a development team usually seem to make it harder, rather than easier to balance the two pressures.

What's the answer? Treat your development team like a business.

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

First of all, income and outgoings are perhaps a bit tricky, as a development budget is usually put on the company balance sheet as one whacking great loss. To make this work, we have to do some basic accounting ourselves. Our income is what the company is willing to put on the balance sheet as that loss. Our outgoings are what we pay our team and spend on resources. Simple, and the two figures should be equal (or someone's going to jail). But how do we spend that money? No private business really lets its customers tell them now to spend the money they pay for products and services, and they never will. That is because businesses plan to develop and grow, and they have to spend their profit wisely to do so. Within a development team, we aren't as free as the business, because when push comes to shove, we have to do what the CEO or the MD wants. But we should strive to give them what they need, while conducting ourselves according to a set of goals (consistent with the company's mission statement) that are created internally. If we can do this, then we can modify our internal balance sheet to have two outgoings:

• Developing what the customer has asked for
• Investing in future developments

The first of these isn't open to much negotiation in terms of price, scope or timing, but the combination of the two is. We must strive to sell a service to our employers that involves the timely delivery of software to a budget that results in a tidy profit at the business level, together with a promise of growth in terms of quality and market share. We do this by making sure we invest internally in the later of the two categories above. As much as people malign the pressure put on us by management, if management ask why you need to re-write your application (again!), can you really look them in the eye and say:

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.

Moving on to the next topic, how do we balance what the customer (our parent business) wants against what we want to do?

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.