, , , , , ,

Author’s Note: This blog is an aggregation of the notes I made for a presentation I did last night in Singapore.  My general approach to developing presentations (once I have the basic structure) is to write out what I want to say in full and then distil that into phrases and bullet points that become my speaker notes.   In the heat of battle, the audience rarely gets to hear the far more polished script I started with, so I thought I’d try publishing it as a blog just to squeeze a little more re-use out of it.  Forgive the tone of the text which is still very much written as though I am talking to a live audience rather than writing for a remote one.

The central premise behind the presentation was to help startup founders who are mulling over way to get to market quicker by potentially cutting corners on technical quality, essentially trading off software design for speed…

Slide 2: Agenda

    • Quality/Speed tradeoffs
    • Technical debt
    • Architecture
    • Hints & tips

There are four main things I want to cover tonight.  The first one is the main topic, but in order to give it justice I cannot avoid introducing and describing Technical Debt and the place software Architecture has within startups.  Finally because I’m going to be speaking at a reasonably high level for most of this chat, I wanted to leave you all with some more specific actionable advice.  Now, I cannot guarantee that each and everyone of these Hints and Tips will be eye-opening revelations, but I do hope that at least one of them will be useful for each of you.

Slide 3: Can you tradeoff internal quality for speed?

So let’s get back to the original proposition…

Can you tradeoff internal quality for speed?  Note than I’m limiting this discussion to internal software quality.   As many of us will be aware software quality has two aspects to it; (a) the external quality – that which is observable by your customers and end users (b) and the internal quality – how the software is designed and architected to deliver the external facing functionality.

To which the answer is…

Slide 4: “No”

Although that seems like an awfully absolute and abrupt end to the conversation (and I still have some time left) so let me put a bit more ambiguity around the situation.

Slide 5: DesignStaminaHypothesis

This is a graph from an article written by another ThoughtWorker called Martin Fowler titled the Design Stamina Hypothesis.  I heartily recommend you read this article when you get a chance, but I’ll extract the key elements for now.

The central premise behind the hypothesis is that there is mathematically a tradeoff point where spending less time on software design (internal quality) does provide increased speed.  This is shown by the blue line.  However there is a tipping point where consistent attention to internal quality (the red line) will result in a more maintainable codebase which enables faster delivery.  This is where the red and blue lines intersect. From that point onwards investment in internal quality increases the speed of the team relative to the no design approach.

Now as Martin himself recognises, this is truly a hypothesis as it has not been proven empirically, but I’ve yet to meet many developers who don’t instinctively understand these curves and their impact.

So the big question is – at what point in time on the X axis is this tipping point?  Again, this is a hypothesis, so I cannot give anymore than a strongly correlated group opinion but I would strongly urge you all to be thinking a matter of weeks rather than months.

With that in mind, it does open up the options for startups to consciously sacrifice internal quality if they have an impending date in the very near future that they need to meet.  Now this is not a decision to take likely and not one to take without understanding the consequences, but I believe the judicious use of this approach can be useful from a business perspective to hit crucial deadlines in upcoming weeks.

Think of it as you hopefully do a big night out.  Once in a while you can stay out to the wee small hours and be reasonably productive during that time.  But for the vast majority of us, this is not a sustainable practices as the payback for such planning is usually only one sleep away.

Slide 6: Technical Debt

Which brings us nicely to the number one idea around managing software quality – Technical Debt.  This was a topic that was name checked by Brian Wong at Echelon but explored no further, so I’ll dig in a little for those of you who aren’t familiar with the concept.

Slide 7: Technical Debt – Debt/Interest/Principal

The metaphor was first coined by a software engineer called Ward Cunningham and is now 20 years old.

The basic idea is that when you cut corners on internal quality you are taking on a debt of a technical nature because you are leaving your codebase in a state which is harder to maintain.

As with all debt, there are interest payments you need to make – this is the slowdown that the team experiences when working with the codebase.  You can choose to continue to pay only the interest on the debt by continuing to work slower, or you can choose to repay the principal of the debt by going back to the parts of the design you ignored and working on them.

Technically, there is one further option which is to ignore paying off either the interest or the principal.  With technical debt, as with financial debt, the end game of this path is bankruptcy, or the inability to do anything with your assets.

Slide 8: Technical Debt – Impact

And speaking of impact, one of the biggest impacts is on the ability of the team to delivery software quickly.  But it’s not only straight line speed which is affected.  High levels of technical debt also impact steering as well.  Code that is difficult to work with is difficult to change, let alone augment, so if you need to pivot your product, that process is also going to be more costly and less effective, unless the pivot results in the entire codebase being thrown away, in which case the technical debt goes with it.

Imagine if you’re designing a car and your assured by the product owner that each car will never need to turn, never need to change direction once it’s started on it’s initial course.  Think of the savings you could make working under those assumptions!  Think of the elements of the car that would be needed if it didn’t have to do anything but go in a straight line!  No steering wheel, no indicators, no differential, no power steering, no rack-and-pinion stuff.

Slide 9: Technical Debt – Measurement

The key to controlling technical debt is to manage it, and a very helpful way of managing it is to start measuring it.  Either by using the vast army of software quality tools that are available for most popular languages or by allowing the team to visually track where it thinks the smelly parts of the codebase are.

If you like, you can treat the level of technical debt in your codebase as a hypothesis in the Lean Startup sense and devise tests to assess whether you (as the customer) are happy with the level of design.   Keep running those tests as frequently as possible to keep a handle of the level of debt.

If you’re a Founder looking for a Technical Co-Founder or CTO, you want to make sure potential candidates understand these tradeoffs quite well and also the impact of technical debt on a codebase.

Slide 10: Architecture

Which brings us nicely to the idea of Architecture and how that fits into the technical vision of a startup.  Again, I spend a lot of time trying to stop large corporates commit technical suicide by way of architecture.  However, whereas they are more likely to over-architect than anything else, I suspect that doing not enough thinking about design or architecture is more of a startup issue.

Slide 11: What is your Architecture?

I think this is an important question because it points to the fact that every application, every codebase has some underlying organisation to it, some general way in which the component talk to each other.  There are some key technical decisions which need to be made to allow development to begin and continue.  The sum of these key decisions is effectively your architecture.  It doesn’t matter if you don’t ever use that term to describe your codebase.  It doesn’t matter if you don’t have anyone with that role in your startup.  Your codebase has an architecture, whether or not you actively do anything about it.  For many of you I suspect your prevailing architecture will be the one imposed upon you by your main development framework; Django (Python) or Rails (Ruby) or YII (PHP) and deployment platform; Heroku for example.

And one of the great things about the fact that there is such widespread acceptance of these frameworks and platforms means that some of the heavy lifting around defining key elements of an architecture has become a solved problem.  True, these commodity architectures aren’t going to suite organisations that require the scale of any of the high profile Web 2.0. companies, but for startups they should work just fine.

Slide 12: Evolutionary Design

But regardless of how much of your design has come out-of-the-box as a result of the existing software components you are leveraging, there will still be a non trivial amount of software design or architecture that needs to be done for any startup.  My advice (and again, I’m standing on the shoulders of giants to give this advice) is to let your design evolve as you learn more about the problem you’re trying to solve, more about your market, more about your customers, what they want, what they don’t want.

The Lean Software Engineering movement has a term for this approach to decision making in general – the last responsible moment.  Used a philosophy of inspired laziness to delay and put off key decisions as late as possible.  Again, this may seem counterintuitive for some, but it should result in a better opportunity to make decisions.

Slide 13: Hints & Tips

And I did promise some actionable advice, so here we go.  Again, I’ll make the caveat that as soon as you get specific, you risk saying stuff which is either not applicable to some people or something they’re already well aware of, but so be it…

Slide 14: Value (Using) Libraries over Frameworks

So I mentioned before about the prevalence of frameworks like YII, Django and Rails, but an over reliance on these things can be a source of pain in some circumstances.  Provided your application does hit the sweet spot of the framework, things are generally rosy, but as soon as your requirements take you to places not ever imagined by the framework’s creators, you can be in a lot of trouble as you try to code around the framework to meet your needs.  Generally speaking, you should choose a framework only for the most stable aspects of your system, which is why Rails, etc are so popular because it’s rare that people start out building a web application and find that the MVC model Rails mandates isn’t really what they want.

Libraries, by way of contrast, are generally far less opinionated in terms of there usage and place less constraints on the developers’ than frameworks.  If you want to quickly know the difference between the two, it’s quite simple: if your code calls the other code, it’s being used as a library, if the other code calls yours, it’s being used as a framework.

Slide 15: Value anything over Building Frameworks

Startup technical teams have no right or time to be building frameworks of their own IMO.  Unless your product itself is a framework, as soon as you start thinking about building a framework you’ve internally pivoted the direction of the codebase.  Unfortunately, some developers love this sort of stuff and are struck by that most cruel of diseases: “premature generalisation”.  The only valid way to build frameworks is to evolve them from within working applications, and usually only after you’ve written those applications enough times to see that there is legitimate re-use opportunities involved.

Frameworks – use them if you have to, don’t build them, certainly not when you have a product to focus on.

Slide 16: Value NoSQL over SQL

I’m not a believer that NoSQL databases will replace traditional SQL databases in all applications.  I see a future where polyglot persistence becomes the norm, where applications use a variety of relational and other models based on “fit for purpose” criteria.  In the short term though, evolving a domain model for your application is not an easy activity and it usually takes quite a few cycles to get right.  For these reasons, using a NoSQL database can free you a little from the overhead of managing a dynamic schema and will allow a technical team to more a little quicker during these formative days, weeks and months.

Slide 17: Value Automation over Manual

  • Setting up a development environment for a new person on your team – one click
  • Deploying your application to production – one click
  • Migrating your production database into a test environment – one click
  • Anonymising that production data – one click
  • Scaling out/back your fleet of servers to handle changes in traffic conditions – at most one click
  • Rolling back a deployment – one click
  • Verifying your application is behaving correctly and hasn’t suffered any regression issues – at most one click
  • Capturing key metrics for your application in production – zero clicks.

And if I can shamelessly self promote for a second, I run a user group in Singapore called DevOps Singapore which focusses almost exclusively on these issues if you’re interested.

Slide 18: Value Functional Tests over Unit Tests

I should potentially have spent a bit more time talking about this earlier but there is one thing I don’t think any startup can do without for any period of time and that is automated testing of the functionality provided.  Unless you are planning absolutely no manual testing of any kind during development, then there is really no additional cost to doing some level of automated testing and all the languages you are probably using have some level of maturity around the automated testing tools they provide.

That said, not all automated testing is created equally and if you have a gun to your head, I would favour testing of the external functionality of the application over the internal functionality using unit tests.  In reality, experienced automated testers will do both as a matter of course, but if your team doesn’t have that level of experience, please do at least spend some time automating the main workflows of your application to ensure no regression occurs.

Slide 19: Value Cloud over Colo

For the vast majority of startups, the ready availability of virtualised servers in the cloud have greatly lowered the barrier to entry.  There really is no need to use traditional data centres in the early stages of your startup until you have proven your business model and likely traffic needs.  The setup costs will quickly consume any loose cash you have lying around.

I doubt anyone here is using colocated data centres at all anyway.

Slide 20: Value PaaS over IaaS

Likewise, unless your product demands it, Platform as a Service providers like Heroku should be a compelling idea for startups when compared to rolling your own platform via Infrastructure as a Service providers like AWS.  There will probably come a time when the Herokus of this world dont provide the configurability that your product may need, but if you’re looking for speed then PaaS will do just fine.

Slide 21: Value Just-Enough over Kitchen Sink

Another niche form of technical debt is the usage of software components where you only need a fraction of that components’ functionality.  Don’t think that just because you’re not availing yourself of 50% of the features of framework X that those features are not causing some drag on your team by the mere fact that they could be the source of defects or updates to the framework that you don’t really need.

Slide 22: Conclusion

So here we are at the end.  I hope there was at least one thing in the Hints & Tips for everyone here.

I’ve covered four main areas around the interplay between speed and the internal quality of codebases.  My original assertion that there is very little opportunity to sacrifice the former to optimise the latter still stands.  It’s not quite a false dichotomy, but it’s at best a mostly false dichotomy.  Make haste slowly by making sure your internal quality is permanently cared for by a team which understands how to do so.