February 20, 2011

...Learn TDD with Codemanship

Start-Ups Must One Day Become Stay-Ups

I've been lucky enough - or unlucky enough, depending on how you look at it - to work on a fair number of dotcoms, ranging from everything to job sites to social networks and gambling (y'know, all those philanthropic sites that benefit humanity), as well as some very high-traffic "portals".

I've been hands-on involved with business models, raising capital, hiring development partners, sorting out infrastructure, choosing offices and hiring and firing up to CTO level. I've been there right at the start, and been there very near the bitter end.

If there's one thing I have a grasp of, it's the lifecycle of the dotcom, from cradle to grave. And I've reviewed a shitload of dotcom code. Millions of lines of the stuff.

And I'm here to tell you one thing: there most definitely is a relationship between the quality of your code and the long-term health of your dotcom. They are "joined in death", to quote a line from Dune.

When a start-up starts-up, code quality is the furthest thing from most people's minds. A start-up is like a child. When you were a kid, did you worry about eating too much red meat? Did you worry about not getting enough exercise? Most kids think they're indestructible. We eat worms and make mud cakes and, given half a chance, stuff ourselves full of fatty foods and drown ourselves in sugary, fizzy drinks.

When you hit 40, it's a different story. You curse all those daily runs you didn't go for, and all those times you opted for the Full English Breakfast instead of the healthier continental. You feel the wear and tear. (Well, I do, anyway.) You feel distinctly destructible at times, and you look at these foolish young whippersnappers playing fast-and-loose with their health and think "yeah, you just wait".

You see, one day your start-up will get old. Sure, there has to be initial success to get past those first difficult stages, but we tend to underestimate just how quickly our code can age. It may very well be that your first rip-roaring success will be your last.

Software that lives fast tends to die young, and pretending tomorrow will never come won't stop tomorrow from coming.

Start-ups who don't pay into their clean code pension fund are banking on never growing old, or on that other fallacy of the young - "something will turn up". Either way, little or no thought or care is put into the long-term future of their software product. Because the future's, like, years away. Right?

Wrong. The future is right around the corner. Oh, here it comes now.

Old age sneaks up on you, and old code comes quicker than we care to admit. Sure, it may start out all lean and flexible, but a few too many fried breakfasts and a few too few push-ups, and before you know it your code can't touch its toes any more, and then it can't get up the stairs.

As a coach, I'm often called in at around the time dotcoms are thinking they may need to install a stairlift for their decrepit code base. They had plans for the code - big plans. But they will only work for a young, nubile code base. Can I make their code young again?

Well, maybe I can. But the operations are going to be very painful, and very expensive. And the code will need months to recuperate.

It would have been cheaper and easier to keep the code clean and well-tested from the start. In fact, all the evidence shows it would have cost nothing to produce cleaner, more reliable code. It might even have worked out cheaper.

It's a demonstrable fallacy to suggest that start-ups have to trade away quality in exchange for getting to market faster with their first release. Up to a point, the relationship between quality and developer productivity works in the opposite way. And very, very few teams ever reach that point.

This is a pension fund where the interest accrues as fast, if not faster, than the payments go into it.

Now, it's absolutely true that dotcoms have a million other things to worry about alongside code quality. But here's the thing, as Uncle Bob very eloquantly pointed out, what makes software development - and software-reliant business - so risky is the enormous cost of writing software. And it's not just the cost of the developers. If Feature Request X takes 1 day, then that's developers, and offices, and heating, and phone bills, and business rates, and human resources - whatever the hell they are - and blah blah blah, for one day. If Feature Request X takes two days, then that's all of that for two days. Add to that the opportunity cost of waiting an extra day. Then rinse and repeat for features A-Z.

The ultimate risk in business is that you'll spend more money than you make. When things take longer, this magnifies the risks. It's like a poker game where the minimum bet is raised with every new hand. How long can you stay in the game?

The art is not in starting up, it's in staying up. That initial success may deal you into the game, but the game doesn't stop there.

Writing clean, reliable code only adds to the risk if your developers are on a learning curve where writing clean, reliable code is concerned. With old hands, there's no extra initial risk. they will likely-as-not deliver that first working release in a similar timescale. And maybe you asked for the right features, and maybe you didn't. Whether or not the code is clean won't affect that outcome.

What it will affect is your ability to play another hand, and then another hand, and then another. So even if a competitor got it right and you didn't, their first-mover advantage will eventually evaporate as you learn the lessons they're unable to respond to because of the crippling cost of changing their software.

Posted 3 weeks, 4 days ago on February 20, 2011