Anti-Pattern #3: Cheat To Win

If ever there was a phrase that I've heard in project management that made me immediately worry, it was "Cheat To Win". You maybe need some more context to understand, and perhaps some alternative phrasings that may ring a bell. Try "Quick and Dirty" or perhaps even "Low Hanging Fruit". Ringing any bells? Good. No, that's bad!

To examine why I think that this type of practice is almost always a terrible mistake, I'll look at the two important words in the title and ask:

Who (or what) are we cheating?

What is it we're trying to win?

First of all, software development isn't a 100 metre dash that we can walk away from, safe in the knowledge that if we cheated the dope test on the day, we get to keep the medal forever. We have to race again next weekend, and people will be disappointed if we pull a slower time. The the next race is the next development cycle, following the one we just sprinted through on steroids. The muscle damage, fatigue and general tardiness we're going to feel is technical debt (on which there has been a lot written). What we have to remember about technical debt for this discussion is that it gathers interest.

And why are we trying to cheat anyway? In my experience, it's usually a business priority. Actually, make that, business short-termism. Looking at it from both perspectives (what a clearly daft short-term win it is, and the long term perspective of how much extra it costs to pay back technical debt than to stay debt free), gives us the clues to what to do about this mantra should we be faced with it.

If someone does suggest that you, or they, cheat to win, simply ask them if they actually want to spend more or less on development. So someone wants a new release out this financial year, or something finished for the next big games event, ask if they want to spend 20% more on the following release. Granted, there are truly isolated business cases for making a quick buck now if this really is the last or only thing you're going to do (running like it's your last race), but they are few and far between. Even the case for cheating to be the first in the market doesn't quite hold up, and I've written previously about this ("do you want 100% of the market share for 12 months, or 90% of it for life?")

Reading back over the last couple of paragraphs, I find myself wondering whether my arguments maybe sound s little too over-cautious, and that perhaps we do need to take some risks, and do a small amount of throw-away coding. I keep remembering YAGNI (You Ain't Gonna Need It), and the XP principle of doing the simplest thing that works. Rest assured, I'm all for these principles, but what I'm against is bad coding habits to get to the finish line quicker. Perhaps I should enumerate these bad habits, for completeness:

• Not writing tests
• Not doing tests (the worst I've seen being commenting out a unit test that no longer works, rather than fixing the test)
• Not re-factoring
• Writing strongly coupled code (after all, it's quicker and easier with fewer interfaces)
• Adding bad dependencies (if I just cast to the concrete object, I get what I want without any re-architecting!)
• Leaking information (just make that member public, and Bob's your Mothers's brother)
• Copy-pasting, rather than sharing (OK, it's a form of re-factor avoidance)
• Being generally lazy (leaving prototype code in, leaving in huge swathes of commented out or conditionally compiled out code, leaving in stale dependencies)

I could end with some Head Master style speech about "you're only cheating yourself", or similar, but I don't think I need to. We're all adults, and we all know the real costs of cheating at software development, because most of us have to work with legacy code every day, that's riddled with the sins and mistakes of the past. We leave the code-base in the state we'd like to find it, and do our best to be honest and transparent about the consequences of business pressure to cheat our way to a fast buck.