Sustainable engineering – avoid big re-writes

By October 5, 2015Forward Partners

Last week friend of Forward Partners Douglas Squirrel published a post about Sustainable engineering on The Path Forward in which he advises founders on how to scale their engineering effort. When the focus is on validating the idea and building first versions of the product it usually makes sense to take shortcuts in code and process quality to accelerate learning, but when the focus shifts to scaling the company it’s important to shift to scalable and sustainable software development practices.

Squirrel’s advice is to eschew ‘big bang’ changes such as re-writing in a new language or framework in favour of incremental changes using techniques like ‘inline’ refactorings and ‘spike stories’. ‘Big bang’ changes nearly always come in late, over budget, and under specification whilst incremental techniques have lower risk and keep the feature set moving forward. Interestingly given he’s an experienced startup CTO himself, Squirrel says to be wary of the advice of developers who “always want to re-write everything”.

If you are in this situation, or think that you might be I highly recommend you read the full post.

Our plan is that more and more authors like Squirrel will become Pathfinders and contribute to The Path Forward. Squirrel is actually our second Pathfinder, the first was Matt Buckland, who used to work here but is now Head of Talent at Lyst. He wrote a about How to read a CV and we have more articles from him coming in the near future.

If you would like to become a Pathfinder let me know via the comments or otherwise reach out.

  • There are times to do a big rewrite and times not to. Consider the compete rewrites Microsoft has done — MS Dos, Windows, OS|2 (failed), Win/NT. Without those rewrites Microsoft would have died. On the other hand Linux has never done a big rewrite, but it started off on an architecture similar to Win/NT so it was never necessary.

  • Lukasz Marek Sielski

    Big rewrite is something that require all parties to know what they want, what is before and after. Single weak link in chain burns everything down. Been there.

  • Squirrel makes some good points, but I think he misses the most important point of all: plan ahead. In the early stages of a startup there is much emphasis on throwing something together as quickly as possible and getting it out of the door so as to receive customer development feedback early in the cycle.

    The problem is that frequently these hasty design decisions come back to haunt you further down the line. So I always counsel taking a little more time in thinking through how requirements may change and expand over time and factoring this information into the initial architecture and data design.

    Think of it in architectural terms: we may only be building a shed, but let’s lay foundations which could support a skyscraper….

  • Usually, devs come with all kind of reasons for changing the framework or the language. For example:
    #1 Pages will load way faster!
    #2 We will use less resources!
    #3 This old crap slows us down!

    There are no guaranties that #1 and #2 will do better, as most of the performance issues are marginal when it comes to the language itself. Even in this conditions, a successful transition will not really impact the faith of your startup. At least not in its first year of existence.

    Regarding #3: well, if we talk about legacy crappy code(modified by a long series of developers, a cheap freelancer etc), this might really become an issue, especially if you have a long list of features that you want implemented in the next following months.
    If you are a non-technical founder, consider an external audit – nothing fancy, just get the advice of a senior developer, or of a founder who’s using that same technology. Or, if you are a techie, some questions might help you decide:
    – how long it will take for this changes to complete? (multiply whatever you get by 3);
    – does this transition require my close supervision? How my other activities as a founder will be affected?
    – even if we change the technology stack, is my current team capable to actually deliver those initial features in time?