The Tech Startup CEO’s Guide to Good Development Practice. Part 3: Ad Hoc & Long Cycle Practices

An interesting person — the founder and CEO of a technology startup — asked me an interesting question:

Where do I go to learn about good software development practices? I want to understand how my dev team works (or should work) and why they work that way. I want to be empathetic and not question things just because I don’t understand them but I also want to make sure we’re doing the right thing for the business.

(Undoubtedly I have paraphrased this somewhat)

This is Part 3 of what I think will be a four-part series. Part 1 examines daily practices, [Part 2 Weekly/Monthly practices and Part 4 looks at adopting and adapting practices. In this article we’ll take a look at some of the practices that take place on a long cycle (every few months) or ad hoc basis.

Managing Technical Debt

What is it?: Technical Debt (Tech Debt, TD) is what accumulates when dev teams implement, deliberately or inadvertently, a solution that will work for for today but may have limitations in the future. A simple example would be an API that easily handle 1,000 requests per minute but that would struggle to handle 10,000. If your user base is currently calling that API a couple of hundred times per minute you have a workable solution for now. But if you scale you will need to do some work to handle greater loads. Managing Technical Debt is the practice of actively tracking the areas of the system where there are these limitations and addressing them before they become problematic.

Why do they do it?: There is such a thing as over-engineering. Maybe your ambition is to scale the business to the point where this API needs to handle 100,000 requests per minute. But the engineering effort required to do that may be significantly higher than that required to handle 1,000 requests and maybe the way the business evolves means that you never need to handle more than this. The time saved on handling about the number of requests we need right now can be used to work on other areas of the system. Later, when the need is there, the dev team can come back and start to remove the limitations.

How does this help our business?: Getting something of value into the hands of your customers is the primary purpose of every business. With start-ups, doing this doesn’t just generate revenue it helps you learn what people want from your business. Spending a lot of time over-engineering a product that it turns out nobody wants isn’t business, it’s playing with technology.

How do I know it is going well (or not)?: One of the hardest parts of Managing Technical Debt is knowing when to do the rework. In a perfect world it will always be done before the limitations become problematic. But in the real world there will be times when the tech team is arguing to deal with some limitations and you can’t see the real need for it just now, and other times where the need comes along faster than the limitations can be dealt with.

This is normal and as long as the tech team don’t constantly spend all their time reworking code long before any need is established, and you’re not always struggling with limitations every time your business evolves, you’re doing it pretty well. TDD and Refactoring will help the removal of limitations when it becomes necessary.

Retrospectives

What is it?: A retrospective is simply a review of some work done and how that work went. Some teams like to do very short retrospectives very frequently, others prefer a slower pace. In my opinion, the exact frequency doesn’t matter so much, what matters is that where areas for improvement are identified, they are acted on.

Why do they do it?: Good development teams are always looking for ways to improve quality and throughput. A team that is looking to reduce time to delivery, reduce defect rates, find ways to keep Tech Debt manageable, etc. is a very healthy team and Retrospectives are a sign that they are looking to continuously improve.

How does this help our business?: It’s tempting to think that good techies just know how to deliver good technology and they should really focus on doing just that. But computers and computing are relatively young and the pace of change is extraordinarily high. The technology I use now looks quite different to what I was using 10 years ago, and nothing like what I was using 10 years before that. New technology requires new ways of thinking and new tools so spending time looking at where improvements can be made is all about trying to improve business performance.

How do I know it is going well (or not)?: This may be difficult as Retrospectives are peer-group activities and so the CEO is unlikely to be invited. Good retrospectives will produce a set of actionable outcomes and the team should be positive about running the next one. If people seem reluctant to attend a retrospective, or no concrete improvements are being identified, it is possible that the team are just going through the motions or, worse, it is being used as a forum for airing gripes and complaints rather than one for tackling areas needing improvement.

Roadmap

What is it?: It can be hard in a start-up to know what you’re going to be working on in six weeks time, let alone in six months. Continuously delivered technology allows for the fast flow of ideas to delivery. But unless you’re just embarking on a series of disconnected experiments, there will be some overall concept of where you’re trying to get to, even if that concept is a bit vague in some areas, the route from here to there is unclear, and you’re certain that things will change along the way. Update: I have since published an article on the style of Roadmaps I use

A Roadmap lays out the picture of what a team is trying to do in the ‘mid-term future’: the next 6–18 months (how far out you look will depend on the nature of the business and its maturity). It will likely be fairly concrete for the first 3–6 weeks, get a bit more vague and aspirational for the middle 2–6 months, and may just be a collection of possible areas of interest thereafter.

Why do they do it?: The thing a Roadmap does for the development team is put some context around their daily and weekly work. When you’re working in a Continuous Integration/Continuous Delivery way it’s very easy to get fixated on the stream of immediate work; what you just delivered and what you’re just about to deliver. So a Roadmap helps the team keep one eye on slightly longer term goals and ask questions like “how might this help or hinder that thing we’re thinking about doing in a couple of months time?”.

How does this help our business?: Even if the Roadmap is necessarily malleable in an early stage startup, a dev team with a sense of where it is going is likely to make better decisions than one with no better idea than just the next set of deliverables sat in front of them. It can be very motivational to see what is coming down the line (or the opposite, if poorly done) and an active involvement in the roadmap gives the tech team a sense of ownership. If you’re a B2B business a roadmap is also an essential tool for communicating with your customers about where your product is going and a vital mechanism for eliciting useful feedback that your tech team can fold into their work.

How do I know it is going well (or not)?: A good Roadmap will change. In an early stage startup there has to be some acceptance that it can change dramatically but, even so, it will provide a sense of direction even when the likelihood of change is ever present. As the business and technology mature the Roadmaps will become more predictable. Change doesn’t cease but it becomes more about the detail and the subtlety than the substance.

However, if Roadmaps constantly change radically and never start to settle down, or are setting completely unrealistic goals that the tech team has no hope of meeting, they can be demotivating and the focus becomes about what was not delivered rather than what was.

Is this really just for Start-up CEOs?

I’ve worked with the CEOs/COOs/CIOs of later-stage and larger organisations who are struggling with technology delivery and much of the argument for these practices is the same. But different challenges and opportunities present themselves to those in a start-up trying to get itself going.

In many ways, an established organisation has already solved the number one problem of building a successful business and so any issues with technology delivery are ‘just’ efficiency/optimisation problems. A start-up needs to find its market fit and whilst a lack of good development practices won’t entirely prevent that from happening it can seriously hamper the effort, to the point of severely constraining the business’s ability to deliver just at the point of where some market fit is achieved.

Isn’t there more to it than this?

If you’re familiar with these practices or software delivery in general then you’re probably thinking “but there’s so much more to these practices (and others)” than this.

Yes, you’re right.

But I’m targeting a very specific audience here. There are loads of books and blog posts written for techies to explain why they should use these practices (and others). There are many that explain them to tech-savvy CxOs. What I’m trying to do is focus on the key practices and give simple explanations about why they’re used and what they achieve for someone who doesn’t have that context.

Having said that, if you think I’m missing a good ad hoc or long cycle development practice, please do comment.

Further Reading

Part 4 of this series looks at adopting and adapting practices.

Eric Ries’s The Lean Startup describes how to start and grow a technology business and talks about how and why to apply some of these practices.

There are a lot of articles out there on Technical Debt. I wrote a couple (here and here) in 2011 that have links to others and I like this article from Mathias Verraes.

There are lot of opinions on Roadmaps, some quite conflicting! I think there is some good stuff in this article from Melissa Perri. I have since published an article on the style of Roadmaps I use