Suits v. Techies.. the neverending battle..

Developers are proud of their work. The best way to get unhappy developers is to force them to create and deploy some crappy software. Sales however, does not care about crap software.. it just needs to work, it needs to be created quickly and cheap so they can sell even more…

Both departments have conflicting interests that 9 out of 10 times the developer will loose.. After all: at the end of the month, it’s the customer who pays the developer salary (and sales’ big bonuses). So, 2 departments, 2 different interests. Normally, the project manager is the person that sits between sales (or management) and development. It’s his job to make sure projects are constructed according the specs of the client, on time and on budget. Not an easy task when the two sides you are working with are in constant state of war.

As said, the sales department never really looses a battle since they generate money, while development generates code. How well written this code is, is never really an issue for a customer. But what if it actually is?

Technical debt: a VISA card, but with an even higher interest rate.

Understand technical debt and it can be your best friend. Don’t, and it will haunt you for the rest of your life. Really..

Every time you create a quick fix, hack some feature into your code base, or quickly fix an error in a production environment, you take on a technical debt. Although you reap the benefits now, you have to pay it back. This is something that most developers will concur, but it’s not something that sales or management always know (or care). It’s a project manager job to keep the technical debt into acceptable limits so both development and sales are happy with the end result. Not an easy job that everybody should do.

One thing is important when dealing with technical debt:

You can plan the hours you work on something beforehand, but you cannot plan the amount of work when you actually need to pay your technical debt back.

It make sense actually. When I have a choice in implementing a new feature quickly the “normal” way, it would cost me 4 hours. Doing it quickly it would be done in an hour. However, as soon as you need to pay your debt back because you broke something, it collides with another new feature requests, support cannot handle questions about the feature, nobody else knows what the feature is about, or how it’s written etc etc… exactly how much time you need to spend on actually fixing it correctly? 2 hours? Then it would still be a good deal (compared to the original 4 hours work), but most likely it would be much more than those 4 original hours. So now a new feature doing it the RIGHT way, would take - say - 4 hours + an additional 6 hours of debt payment.. And not even your best sales guy could sell that to your customer…..

Paying back debt is very easy, and most developers would love to get rid of bad code.. The problem is getting sales and management to green light the nonchargeable hours that comes with paying back the debt.. Stop thinking in quick fixes, or at least, take the debt you creating in account when selling something so not only you, but your customers as well don’t end up with surprises later on..