Co-location and Remote working

One of the things that drew me to the emerging XP practices in the late ’90s was their embrace of the humanity of software development. So much of contemporary practice was concerned with removing human messiness from the process: unambiguous specification; meticulous design; error-free coding; precise testing. If every step of the transformation from ideas to running system was executed perfectly it all worked perfectly. But if not …

XP recognises that trying to become more machine-like is not the answer to delivering better machines. Instead XP practices and values (values in a software development process, what an idea!) are all about recognising the inevitable messiness and working with it. Find requirements hard to specify without ambiguity? Have a conversation and keep returning to that conversation as the vague and uncertain elements become recognised. Find it hard to deal with all the variance of an idea in one go? Build the software incrementally with a growing set of tests to describe all the subtle deviations and contradictions. Find it hard to decide which UX approach is better? Sit with the user/customer and try things out as you build.

Co-location is a crucial and somewhat assumed aspect of XP. Physical co-location was required or implied by many of the practices: Whole Team, Planning Game, and Pair Programming were all originally conceived as things to be done in the same place (indeed ‘Onsite Customer’ was an idea that became subsumed into ‘Whole Team’). But co-location of activity and focus is equally important: the purpose of having an ‘Onsite Customer’ is so that if an ambiguity or inconsistency pops up even as some code reaches the point of delivery the expert user can give feedback and changes made as necessary. No drama, no artificial separation of decision/design/development/deploy activities, just another short loop around the delivery cycle.

As a long-term XPer co-location is the norm for me, so much so that I am in the office with our engineering team for most of every week despite the fact I live about as far away as it is possible to live and still be in the same country. I love being there, in amongst the hubbub of it all, and the days I work from home – a necessity if I am to have any form of home life at all – are never quite as much fun.

And yet, from today we’ve requested that our engineering team work remotely for a period, as so many others are.

Partly this is to protect the health of our employees; we can’t possibly prevent them from becoming infected with COVID-19 but we can certainly help reduce exposure by not asking them to spend hours on tube trains and buses every day travelling into the busiest areas of London and New York. Partly it is to protect the health of the business; even if it is inevitable a significant proportion of the team will become ill, we can reduce the chances that people working closely together on important initiatives become ill at the same time.

But mostly we’re doing it because we can; in this period of uncertainty, while the scientists and politicians work out how to interpret the data and and what a good response looks like, we don’t need to require people to come into the office. We can spend a little time getting good at remote working while we have the opportunity to do so and we can give people back a little time to figure out how to deal with the impact of the pandemic and our government’s response to it on themselves and their home lives.

Because what concerns me isn’t the practices or the processes of building code remotely. There are tools for remote pairing, planning and meeting that have worked well for a couple of decades now (and will improve rapidly this year). I’ve no doubt that we’ll be shipping quality software just as quickly and productively as ever.

What will be harder is replacing that hubbub, the sense of shared purpose, the ease of micro-interaction and the subtle glue of togetherness that comes from being in one place; and the positive impact that has on our peoples’ mental health. But we’ll work hard at maintaining these aspects of working together even as we work remotely, starting with our first ever fully-remote ‘All Hands’ this week.

I’m already looking forward to that first day back in the office though, hopefully not before too long.

Pot Odds: Maximising the Value of Success

I’m inspired by Kent Beck‘s fantastic post on how Delay Chokes Innovation to write something that has niggled around at the back of my mind for over a decade. If you haven’t read Kent’s post, please do so as it provides the context for this one which is a ‘yes, and’ rather than a ‘yes, but’ response. It is also a poker story.

Poker

I hate tournament poker, largely because I’m crap at it. I don’t like the ‘winner takes all’ dynamic and the use of artificial escalation to force a result. I once played a tournament at the Luxor in Vegas and it was the most grindingly grim poker experience of my life.

I learned to play poker in an ever-evolving group working on a project away from home. Once we’d quickly exhausted the delights of the local town we turned to making our own entertainment and a poker school playing two or three nights a week was born. Sometimes there would be four players, sometimes twenty. There were a few regulars, of which I was one, and a number of people who drifted in and out. The standard of play was high and a couple from the group went on to be successful semi-pro tournament players.

I was one of three complete novices when we started with four or five others who had been playing for a few years. My first night was a shock as I lost hand after hand, quickly ripping through my €50 budget for the evening (they were kind to me and suggested I set a budget to avoid financial ruin on top of the inevitable humiliation). So I sat and watched, itching to buy back in, and resolved to learn how play properly.

I set myself an overall budget of €300: if I was still losing hand over fist after I’d spent that I’d give up on it. The second night of play I lost my €50 limit again but managed to last the whole night and from then on I started to lose less, then win a bit, then win a lot. I never quite spent my €300 ‘tuition fee’ and at the end of the project I had a drawer stuffed full of 5, 10 and 20 Euro bills.  I learned an awful lot about bluffing, mirroring, psychological manipulation and risk management, not by reading books but by watching and responding to the actions of my friends/foes across the smokey, dimly lit table.

Pot Odds

Some poker players know the odds of every possible hand given the cards they hold and the cards on the table. I once played against someone in the final year of their PhD in game theory whose party trick (deployed before the game to intimidate us) was to play open hands reciting the odds of winning as he went. Very impressive*!

Less clever players like myself work on the concept of ‘outs’ rather than exact odds. An ‘out’ is a card that leads to a possibly winning hand and if you can identify all the outs you can do a rough approximation of odds: the greater the number of outs and the stronger the hands you end up with the better your chance of winning. ‘Possibly winning’ is important here: many published poker strategies focus on having the best possible hand (or something very close to it), bluffing hard, or else folding quickly to minimise losses and tournament poker tends to favour such strategies. School poker is different because it is played out over many nights and there tends to be more risk taking because the cost of failure (whether losing a hand or losing out over the course of a night) is lower: you can always come back later.

Both forms of poker work on the basis of ‘pot odds’ but these are more important in school poker than tournament. Pot odds is basically the ratio of your odds of winning to the amount of your money in the pot (the total of all the bets on this hand). Let’s say your chances of winning are 1 in 5 and your current stake is 10% of the total pot. A 1 in 5 chance of winning isn’t great, and most poker strategies will tell you to fold such a hand, but with a potential 9:1 return on your money it’s worth hanging around for a bit to see what happens. Conversely if your chances of winning are 1 in 5 but your share of the pot is 25% it’s likely time to get out.

It’s not as simple as that because factors like the number of players left in on the hand, the amount of money you and your opponents have left to bet with, the stage of the evening, your’s and others’ propensity for bluffing, etc. all contribute. But it stands as a basic heuristic: if the pot odds are with you stay in, if they’re against you get out**.

Innovation and Maximising the Value of Success

So what’s this got to do with innovation? As Kent says:

The cost of delay in choking innovation is insidious. From outside the company looks to be doing fine. Smaller wins times a larger market equals continued growth.

This is basically the tournament strategy of folding unless you’re going to bluff hard or have the best hand. The thing is that unlike in the movies those ‘nuts’ hands, where you’re dealt a pair of Aces and another one turns up on the flop, are very rare. You can wait for hours for something like that to turn up, and then try to eek out the betting only for everyone else to fold because they have dogshit and your moment of triumph nets you all of €15 with €5 of that being your own money. There is definitely a role for smaller wins times a larger market in a stable business but sometimes you need or want to do more.

Invisible are all the little roads not taken that could have turned out to be superhighways

Playing pot odds helps you look for those little roads that can turn out to be superhighways.  If you do want or need step-change growth you have to find the opportunities that, even if more risky, have much more reward in return. It’s all about maximising the value of success rather than minimising the risks of failure.

If you’re a company owner or senior manager you need to encourage a ‘play big, win big’ attitude but know how to direct that to areas of innovation that have a chance of disproportionate reward, not to safe projects that will almost certainly bring a modest return and not to vanity projects that deliver all the buzzwords but little value. And sometimes it’s right to go ‘all in’ on an initiative because, as with school poker, there is always the chance to come back later.

Last Words

Those nights playing poker against, amongst many others, Darren, Darren, Phil, Johnny P, Johnny B, James, Brett and Klaus were amazing fun and a greater understanding of human psychology and risk management was just a happy by-product. If any of you happen to stumble across this, thank you.

Thanks too to Kent for a great post and also for this wonderful ‘separated at birth’ opportunity:

Woody Harrelson and Kent Beck. Or is that Kent Beck and Woody Harrelson?

*also completely hubristic. By revealing his key strength up front he told me all I needed to know to play him. Two hours later he was all out.

**basic heuristics don’t last any longer in a game of poker than any other rule or formulaic strategy. It’s the foundation for a strategy, not a strategy itself.

Delivering Software with Cards, Magnets and a Wall

“We need some new development task tracking software. What is everyone using?” asked someone on a CTO email list I’m a member of. “Is Jira still the standard?”

Jira, Trello, LeanKit, Pivotal and their ilk have never been for me. Since I first started practicing XP mumble, mumble years ago it’s always been about cards, magnets and a wall. Above is the old Singletrack office with two separate boards for our two main product strands and a third for customer roll-out work.

“But what if you have a dispersed team with remote workers” a Trello fan will ask. Well, maybe if we were entirely dispersed I’d use something like Trello but I’m also a fan of co-located teams so even with several remote workers at any one time we have most people working in front of the wall and stick smartphone pictures onto Slack for those not in the office. Local people move cards on behalf of the remotes.

“What about reporting?” asks the Pivotal advocate. Who needs reporting when I can go stand in front of the wall for a few seconds, see where everything is, and ask devs questions about what they worked on and are working on now?

“What about losing cards and work not getting done” says the Jira guru. In those mumble, mumble years, even working with teams of 50-odd devs it’s never been a problem. Very occasionally a card goes missing but we realise that pretty quickly and write it afresh. And you can’t tell me tasks don’t get lost in Jira sometimes; in fact I hear that is more the norm than the exception.

However these objections miss the fundamental point. The real value in using cards, magnets and a wall is in the physicality of it. Cards get written collaboratively, not entered into a system. A card might get written once in a planning session then ripped up and re-written as two or three more cards: it’s such a low-friction process. We use different coloured cards for different types of work, badges to indicate different initiatives, coloured star stickers for priority work. Stuff get’s written on the front and on the back and related cards get clumped together.

And it all just sits in front of the whole team, and indeed the whole company, the whole time.

We had a developer in for interview the other day and she told us her current team had to schedule a daily reminder to make sure their Trello got updated otherwise they forgot to do so. The mind just boggles.

But that’s just the day-to-day mechanics. Last year I got to fulfil a long-held ambition and  had a custom wall built to replace the old magnetic whiteboards when we moved into a new office:

In explaining what I wanted to the initially very skeptical designer, who was a big fan of Basecamp,  I had to describe the purpose of the wall, not just the function. Here’s what I wrote for them:

“To me, it is not just a functional tool. It is where the challenge of what the technical team needs to deliver is quite literally writ large. You can see the cadence of releases in the ebb and flow of cards on the wall and the hither and thither of developers and QA as they go to move cards.

“It is easy to spot when a card gets stuck in the backlog or priority cards aren’t being progressed. I know when we have just reviewed all the work because the board is all neat and when we’ve got a good chunk of work done as it’s all messy again.

“It is a physical manifestation of what we’re tasked to achieve and we celebrate that rather than hide it away in an electronic tool like Basecamp or Trello.”

A week or so after this exchange with the designer one of our graduate developers had a real aha moment after a couple of months with us. “I think I get it”, they said “it’s not about “here’s the work” [mimes being given a card], it’s about “here’s the work” [waves their hands across the whole of the wall]”. Spot on; not the work you have to do as an individual or a pair but the work we have to do together as a team.

A couple of months ago someone on the same CTO mailing list asked if anyone had an example of an inspiring bit of office design and Jonathon Lister Parsons of PensionBee was kind enough to suggest our wall. Which was such a thrill as that is exactly what it is designed to be: an inspiration to the team.

Technical Details

The Singletrack Wall is constructed of plasterboard mounted on batons attached to the office wall underneath. Glued to this are sheets of 0.8mm ferrous metal (avoid magnetic paint or self-adhesive magnetic sheeting, the magnetism isn’t strong enough) which is covered with mildly textured, hard-wearing wallpaper. Strip lights at the top and bottom give the Wall a ‘glow’ and we have office lighting directly above it so the cards are never in shadow.

The wall is divided into sections using magnetic tape so it can easily be reconfigured. We have a variety of magnets as different people prefer different styles. Our Head of development likes multi-coloured ones, the lead on our analytics product stream only uses black ones (you can see those in the top section of the board) and I love these neat little extra-strong Neodymium numbers. This mixture does nothing for my OCD tendencies but, self organising team, what can I do?

Exciting news: we’re just about to move the Product Engineering team to their own office so I get to build a WHOLE NEW WALL. Any suggestions for improvement?

 

How XP helps me keep coding

“But do you still code?” is a commonly asked question when I tell people I’m a ‘hands-on CTO’.

“Yes. Not every day, but most days.”

“Real code? Like production code, not just R&D?”

“Yes, production code.”

This is extremely important to me. In amongst all the other responsibilities I have as CTO I feel that being able to get hands-on with the code keeps me grounded in the reality of delivering our technology, it helps me relate closely with our developers, and it keeps me sane. Well, sane-ish.

Then someone asked me a question no one else has asked before:

“How do you do that?”

As their company grew they had less and less time to code and, when they tried, it just didn’t work. The codebase was so unfamiliar that they struggled to get started and if they got started they never had time to finish. Within just a few months they felt they no longer had the ‘right’ to change a system they had single-handedly built the earliest versions of.

It turned out the answer was simple: an XP process, specifically, TDD and Pairing, and a bit of commitment.

Last week we needed to make a very quick change to an important data processor. The change was subtle but complex so rather than asking the dev team to read the spec from the data consumer, or get a lecture on it from me, I paired in with one of the devs to write the tests and then the new functionality. Pairing on the tests was actually pretty quick which meant that if I had got dragged away to deal with something, someone else could have taken over on the functionality update. But, as it was, a couple of fun hours later we had all the changes deployed for final testing and then into production by the end of the day.

Recently I ran a new static code analysis tool that highlighted a specific set of code quality issues. I wanted to understand the cost and the benefit of addressing the highlighted issues before raising them with the dev team so I spent a few one hour sessions refactoring code to address one or two examples of each issue. TDD is more than just having tests but not for the first time I was thankful for the comprehensive and trustworthy test suite to prove I’d not screwed things up. Making these changes was valuable for me to evaluate the validity of the issues and served as a good set of exemplars for a team-wide initiative to address all the issues and add the tool to the build process.

TDD and Pairing are easy, they’re just how I work. Commitment is much harder but just a few hours a week is all I need to retain a very real connection with our technology and our development practice.

How could I not do that?

Collaboratively Choreographed Chaos (with Common Cause)

I recently discovered that the best way to spend some time in Venice is to buy an all day ticket for the Vaporetto (ferry bus), find a seat at the front, and just take it all in. Over time I found my attention drawn to how the various users of waterways picked their way through the Canal Grande.

Elegant Gondole present tourists with a facsimile of romance and a personal tour of the city’s heart.

Luxurious Taxi d’Acqua provide both the fastest way of getting from A to B and a comfortable way of touring.

(c) Ted McGrath https://flic.kr/p/dQGrm6

Utility barges bring wine and beer (and presumably other goods) into the city, and take the garbage away.

Lumbering Vaporetti move large numbers of tourists and workers en masse through the city.

And so on, all sharing the same small area of water.

Given the vast differences in speed, size and agility of all these craft you might expect a series of strict rules and controls to govern all this, but it appears not. There are no traffic lights or aquatic roundabouts, there is no requirement to stick to one side of the canal or other and no clear right-of-way precedence. What there is is a series of calls and signals that indicate the intentions of the pilots, taxi-drivers and gondoliers to each other. There appear to be a number of common-sense conventions based around the needs and abilities of each craft which are applied, or not, as each situation demands. And the men and women that navigate the canals on a daily basis are highly skilled at what they do.

It is a chaotic system in the physics or maths sense of the word: a complex system whose behaviour is so unpredictable as to appear random. But it is not the randomness of total mayhem, rather the collaborative choreography of a diverse group united in common cause: to service, directly or indirectly, the tourists who are the lifeblood of the city.

Returning to work I was struck by some parallels between the seemingly random and yet ultimately highly effective Venetian waterways and our development process at Singletrack. As a team we have lots of different demands on our time: core product development, support, customer-specific customisations, new customer roll-outs, support of sales efforts and so on. All of these move at different speeds and have different, sometimes competing, characteristics and constraints.  Our development process is a mild variation of late-90s XP: a variant because we’re self organising and most of the team wasn’t doing development in the late 90s, and mild because those core practices and principles still work. Its very lightweight, everybody understands it, and its very effective.

I’ve recently begun to worry that this lack of evolution from how I learned to do things nearly two decades ago demonstrates an unwillingness or inability to change. To keep up with the state of the art. I spend time looking at new and different processes and techniques but somehow they fail to engage me and, other than the occasional cherry-picked idea, I go back to what I know.

I realise that it can’t be that Scrum or Kanban or Modern Agile are sham approaches that deliver nothing. It can’t be that NoEstimates and NoProjects have nothing worthwhile to say (even if they do seem to be determined to say it in a particularly negative way). MobProgramming must be good for some people somewhere. But I’ve found them to be limited in value to me.

What my Venetian experience helped me understand is what’s important is that you have a set a of calls, signals and conventions that allow you to collaboratively choreograph your movements, not what that those calls, signals and conventions actually are. The ones that are called XP work for me, maybe the ones called Kanban and MobProgramming work for you. What’s important is that your approach actively works towards the common cause of your organisation not that its the one that gets the most hashtag traffic on Twitter.

When I thought about writing this blog post I did a bit of research on Venice and its waterways. It turns out that what rules and restrictions are imposed had remained unchanged for nearly 200 years until the death of a tourist in 2013 (http://www.telegraph.co.uk/news/worldnews/europe/italy/10268403/Venice-to-control-boat-traffic-on-crowded-canals.html). The response to this tragedy wasn’t to impose a totally new regime of strict controls but simply to update the conventions slightly to reflect Venice in the modern era. Barges have had the hours they can enter the city limited, and illegal docks and piers have been removed, but the fundamentals of the collaborative choreography to suit the common cause remain intact.

So don’t look for the latest or the ‘best’. Look for the calls, signals and conventions that work for you. Find the collaborative choreography that marshals all the disparate people with their disparate needs and disparate talents towards your common cause. Make it work and then keep it working.

 

 

 

Getting the best out of Tech at Sales meetings

Like most enterprise software there is usually a point in our sales cycle where the prospect’s technical team want to do a bit of technical fact-finding or due diligence on us. As we grow one of the common internal complaints is Sales find it hard to secure time from our tech team to attend these prospect meetings. So I wrote a short guide to getting the best out of tech at Sales meetings which I realised is not particularly specific to Singletrack:

Tech at Sales Meetings

Its primarily aimed at Sales but its also partly about what a tech team should be able to support.

A Paean to Speccy

“Remember the ZX Spectrum?” the Guardian asked a few days ago. Remember it? That fragile black-and-grey box with the jaunty flash of rainbow colours and precariously attached ‘RAM Pack’ set me on a path that has come to define my entire life.

I remember hooking it up to the battered second-hand black and white portable that served as our family TV in the early 80s and loading in a copied game from tape. Brrrrr, chi. Brrrrr, CHEEEEE etc.

I remember getting it to print ‘Hello World’ 10 times using BASIC, and then modifying that to print ‘Hello Paul’.

I remember the hours of typing Hexadecimal from cheap-paper magazines smudged with sweaty fingerprints. “Is that an E or an F”. Like alchemists we toiled over our steaming cauldron of a computer trying to turn the base metal of those listings into the gold of a simple game. We even succeeded once or twice.

I remember the animated Valentine’s card hand-crafted in Z80A for my first girlfriend. Diagonal scrolling, jaunty tune, teenage poetry. She dumped me the next day for reasons I still haven’t fully grasped.

Getting a chord out of a one-channel sound chip. Creating a spinning wireframe cube. Ghhhhheestttbushhhhhterssshh. High Speed Dubbing tape-to-tape ‘sharing’. And Elite. Oh My God Elite.

Eventually, of course, like my Star Wars wallpaper and Superman duvet cover I grew out of the Speccy and replaced it with a ‘proper’ computer – an Atari 520ST.

But i still miss that little box of magic. And that wallpaper.

“Magic, suggestion, psychology, misdirection and showmanship”

“Magic, suggestion, psychology, misdirection and showmanship” is how Derren Brown describes what he does. I’ve long been a fan of Derren’s – I managed to wangle front-row seats to one of his shows years ago and was utterly blown away – but of that list its not the psychology or suggestion that intrigues me, its the magic and, particularly, the showmanship.

The longer I spend doing what I’m doing the more I’m convinced that magic and showmanship are fundamental to the success of a technology product company.

Arthur C. Clarke said “any sufficiently advanced technology is indistinguishable from magic” and whilst I wouldn’t claim that what Singletrack does is so advanced that our customers and users think we’re a group of warlocks and witches, I certainly think there are magical elements to it. Fundamentally I believe software development is close to magic and I’ve written before about how amazing it is to me that we can integrate diverse cloud services to add incredible levels of features and benefits to Singletrack’s product with disproportionately little effort.

But what is magic without showmanship?

Imagine a magician who said “well I suppose I can show you a trick if you want but you won’t like it”. Who said “yeah, but to be honest anyone can do that with a bit a practice”. Who went through their routine in surly silence, sighing at the boredom of it all. Actually that’s not a magician at all its just someone with a bit of dexterity and some specialist knowledge, like a hairdresser or a masseuse*.

Building a product and a product company has taught me to think differently. I no longer see “a simple integration with Amazon S3 using their web api” I see “the addition of an unlimited capacity, edge-cached, versioned document store”. Its not “a bit of AJAX and a few queries returning some data” its “a live data dashboard showing key management information”.

I’m guessing that there is a bunch of people I know who, if they’ve decided to read this and have made it this far, are rolling their eyes and thinking “great, he’s discovered marketing hype”. But that really isn’t what I mean by showmanship. I’m not talking about lying or making inflated claims. I’m not talking about conning the customer or bullshitting the user.

I’m talking about communicating the excitement and the wonder of what you deliver to the people you deliver it to.

I’m talking about making the magic you do, magical.

I love the fact that, over the last 15 years, software development has become so much more open, so much more honest, so much more about delivering quality and value rather than simply working to plans. I love the constant striving for improvement in what we do and how we do it. But I also hope that as we take the mysticism and myth our of our development teams and processes we don’t accidentally remove the wonder and beauty of what they deliver.

That we leave a little room for magic … and showmanship.

* Please note that I have nothing against hairdressers or masseuses, but I wouldn’t pay for front-row tickets to watch them perform for two hours.

Why we don’t Continuously Deploy

Continuous Deployment is very much en vogue; its seen as the natural extension of Continuous Integration and is a part of the lean startup philosophy. But we don’t do it and I thought it might be interesting to explain why.

1. Our users like improvement but they don’t like change. We build a business system for business users and our users each spend 2-8 hours a day using our system. They want to see the system improve but having a consistent, recognisable user experience is more important than having one that is constantly changing, even if that change brings improvement. So we gather all their feedback as they use the system and package that into a release. When that release is ready we do demos and distribute documentation to make sure everyone is aware of the changes coming. Bundling up all improvements into one big change allows us to make sure everyone understands what is coming, is happy about what’s new, and there are no surprises when they log in.
2. We do QA as well as testing. To me QA is a separate activity to writing and running automated tests. My experience of developer-written tests (unit, functional, integration and so on) is they tend to take a rational and logical view of the functionality under test: what happens when used correctly, what happens when expected parameters aren’t supplied, what happens when parameters are supplied with unexpected values? But users aren’t necessarily ‘rational’ or ‘logical’ as developers see it and having humans bash away at the system, hitting the back button randomly, pasting parameter values from surprising sources, leaving the browser open for an hour while they have lunch, and so on helps us to spot the gaps in the automated testing and the assumptions we made whilst writing them. But manual QA takes time and having continuous pressure to have it done as quickly as possible to support continuous deployment will be counter-productive. So we bundle our changes up into weekly QA releases which means QA can be done at a pace that suits the assurance of quality rather than speed of deployment.
3. We’re still learning. To me there’s a bit of a paradox in Continuous Deployment as applied to lean startup. On the one hand, multi-variate testing and continuous deployment allow you to gather and act on lots of feedback very quickly. On the other hand, a constantly changing user experience makes it harder to make sense of that feedback. In our system there is a piece of core functionality that users use for ~3 hours each day. If that changed on a daily basis they’d quickly get pissed off with it and wouldn’t use it until it was ‘ready’ or ‘done’. We’re now on our third major re-working of that functionality and the latest version is vastly improved, based on real user feedback. But each new version has been introduced as a whole, with all the change management mentioned above, and so we’ve kept our users onside whilst making quite radical changes to the product.
4. ‘Continuous’ is a relative, not an absolute, term. Sounds like a stupid statement but its a lesson I learned a while back. In a previous job I was doing some work with a company and their supplier to improve their responsiveness to change. We were pushing for weekly releases but quickly realised that, to a pair of companies used to 18-24 month release cycles, quarterly releases would be a big improvement and much more achievable than weekly. Were we being unambitious? Perhaps from our own point of view as eXtremists, but in terms of the goals our clients had, quarterly would take them along way to achieving what they wanted. At Singletrack we do releases every 6-10 weeks which is so much more continuous than other systems our users use (upgrades every 12-24 months is more the norm) but avoids the disruption that ‘true’ Continuous Deployment would cause.

So we currently do: Continuous Integration in development; Daily Builds with full runs of automated tests (takes about 3 hours otherwise we’d do this more frequently); Weekly QA releases; End-user releases every 6-10 weeks. A lot of this stems from our business: we sell a complex, powerful SaaS product to sophisticated and demanding business users. If we were running a B2C website with a host of irregular and infrequent users (from the point of view of our system, a user that doesn’t log in for hours every day is infrequent) then we would certainly go for a much more continuous process than the one we have now.

An economic model of technical debt?

A lot of what I’ve read about technical debt assumes that it is generally a bad thing. A lot of these articles also use credit card analogies to compare technical debt to personal finance and I think this is missing a trick. Businesses take a different view of debt to people and I wonder if using a more mature model of technical debt  would allow us to take a more nuanced view? [Caveat, I’m not an economist or an accountant, I’ve just run SME businesses for a few years and so have a little knowledge, possibly just enough to get this badly wrong].

Start-ups like ours run on credit. Whether its founders taking no salary, people working for sweat equity, friends and family or Angel funding, buying kit and services on personal credit cards, whatever – there’s going to have to be a bit of debt incurred to get from having nothing but an idea to having enough paying customers to sustain you. When we incur technical debt in our start-up it is in very much the same spirit: if things don’t pan out the debt isn’t going to have to be paid back. That doesn’t mean you take on as much credit as is being offered because loading the business with debt may quickly become one of the causes of its failure. But you take sensible risks, take the credit you need and work bloody hard to pay it off before it becomes a burden.

As a business starts to establish itself things like cashflow become more important. A business might use credit (e.g. order factoring or  bridging loans) to smooth the flow and to reduce their risk of running out of money. Many projects I’ve run experience a similar ebb-and-flow of requirements and I wonder if taking a longer-term view of the ‘requirements flow’ of a project might allow a more structured approach to technical debt; when there are lots of requirements to deliver in a short period, be prepared to take on a bit more technical debt. When there is less pressure to deliver requirements, pay the debt down. If the ‘less pressure’ phase isn’t looking like coming, take extraordinary action if it looks like the TD might get out of hand.

Once a business is established and looking to grow, it often takes on debt in order to achieve strategic objectives. What would be the equivalent in software delivery?

The problem with all the above is that it is still very much an analogy and I’m no great fan of analogies in software development. But what struck me about the conversation leading up to and following my previous post on Technical Debt  is that technical debt isn’t really a metaphor as such. It’s not like monetary debt – where taking a bit of extra risk and incurring a greater overall cost in the long term allows you to achieve important things in the short term – it is monetary debt. By accepting technical debt you are (presumably, or why else are you doing it) incurring a lower cost, or enjoying a higher income, today but incurring a higher cost in the long run.

So what if we stopped treating technical debt as metaphor and started considering it as monetary debt? Could we quantify the costs we save by not doing something today (e.g. pairing, refactoring, resolving limits issues, optimising, or even just applying good old YAGNI) that may cause us pain at a later date? Could we quantify the value gained by doing something valuable sooner? Could we quantify how much more it will cost at that later date when we have to deal with the pain? Could we use these numbers to base decisions about whether or not to incur technical debt?

Here’s a simple example from our start-up. Two customers wanted broadly similar features adding to our product but had different timescales and some differences in detailed requirements. We took the decision to build two separate versions of the feature, one for each customer, even though we knew that this would give us two broadly similar sets of code to maintain and, if we wanted to sell the same feature to other customers, we would not only need to refactor them into one code set, we’d also have to do some additional work to migrate the customer’s data from their individual versions to the new unified model.

In this instance it wasn’t about cost saving as such. Both customers were willing to pay for the feature to be added if we could do it to their timeframe. So we got some money up front, lets say $100 (I’ll preserve the ratios but I’m not prepared to reveal the real sums). The cost of building it twice was a bit more than building it just the once, let’s say $20 instead of $15. We then had an additional cost of maintaining two code sets for  awhile, lets say $3 instead of $2, and we then had the cost of the rework and migration: $12. All in, the gross profit for this was $100 – $20 – $3 – $12 = $65.

Now suppose we’d built it once for one customer, and then evolved it for the second customer. Immediate income is $50. Gross profit is $50 – $15 – $2 = $33. If we then sell to the second customer the profit goes up but probably not to $83, lets say $80 because there’s bound to be some migration or re-work required to keep customer 1 in alignment with what customer 2 wants.

In this economic model it is $15 more profitable not to incur the technical debt. But, and its a big but, in any business and particularly in a startup cash is king. $100 dollars this month is way better than $50 this month with the expectation of another $50 three months later. And that assumes customer 2 still wants to pay in three months time. By then they may have bought or built an alternative. If they don’t buy you’ve only made $33, not $65; by any conventional business model, a certain $65 profit is vastly preferable to a certain $33 profit with the possibility of an additional $47.

But whether or not you agree with the decision to go for the $100 now and incur the technical debt isn’t the point. The question isn’t whether we made the right choice in this instance, its whether quantifying like this makes it easier to surface the benefits and liabilities of technical debt? A lot of the blog articles about technical debt say its hard to quantify but making rough guesses about this stuff isn’t that hard and rough guesses should be all you need (let’s face it, most successful business are run on far rougher guesses about predicted revenue, predicted costs, etc.). And it seems to me that if, as techies, we could get better at using terms, equations and numbers the business understand we could get much better at communicating why we should or should not incur technical debt, what our current debt level is, what it will cost to pay down, what the financial, reputational or other forms of impact might be if the risks inherent in the debt don’t pan out, and so on.

Perhaps we could stop treating technical debt as a metaphor and start using it as a real tool for planning and delivering our products and projects.