Stop Writing Code

I know first-hand how engineers couple the value we deliver to the volume of code we produce. But by being smart about what we use code for, we can move faster, test hypotheses with ease and adapt with less friction.

By Robin Weston, Engineering Leader, BCG Digital Ventures

While the overall product that software engineers build is an asset, each line of code that composes it is a liability. Any line of code could contain multiple bugs, cause performance problems, or be hard to read and understand. Even if, at the time of writing, a line of code is “correct,” it may well become unfit for purpose at some point in the future. This could happen for a variety of reasons, including but not limited to: Changing customer behaviors, increased system load and new security vulnerabilities. So we can consider each line of written code as carrying some kind of risk and associated maintenance cost.

It is therefore unfortunate that many software engineers (myself very much included) couple the value we deliver to the volume of code we produce. If we’re not writing code we start to feel frustrated or like we’re not contributing to the wider team.

On a recent BCGDV venture I was involved in, we built an online marketplace for matching homeowners with quality traders such as carpenters, painters and plumbers. It’s a reasonably well understood domain, and as a software engineer you could probably start to think about how one might go about modelling and building such a product in code without too much effort. Traders would need to be able to register on the site, homeowners would need to post jobs and reviews…the features would be easy to sketch out. After a bit of thought, you might be able to sit down, choose a suitable technology stack, and get to work writing code.

And you’d get it wrong.

However much thought you put in, however much customer research you perform in advance, however well crafted your user stories are, you’re inevitably going to make incorrect assumptions about the way humans will interact with your product. Writing code solidifies what you’re thinking at the time, making it harder to change in the future. Even the most well-structured, readable, test-driven code in the world is harder to change than no code at all.

So when we started to build our online trader marketplace, we tried something a little different. Against all our natural instincts, we turned away from our IDEs and threw up a simple enquiry form using WebFlow, connected to a Google Sheet using Zapier to capture enquiries.

Within a day, we had our first customer. Within the first week, many more. We fulfilled these initial customer enquiries with a combination of human effort and more Zapier and Google Sheets automation. There were even times when software engineers were calling up our customers directly in order to find out more about what they needed and how we could find them a suitable trader.

Did the product feel hacky and stuck together with sticky tape? Oh yes.

As software engineers, did it hurt our pride and feel like we weren’t doing our jobs? It certainly did.

But were we rapidly learning from real customers using our product? Absolutely.

By creating an end-to-end skeleton product and putting it in the hands of not just our external customers but also our internal product and customer operations teams as early as possible, we were in a great place to explore the domain we were operating in, find out how such a system would actually function in the real world, and either prove or disprove our initial hypotheses.

As the product and customer base continued to grow, we fell into a pattern. Any new areas of functionality, which by definition contained more risk and uncertainty, were built quickly using what we had by that point come to call “Zapier Driven Development”: A combination of Google Sheets, Zapier,and other off-the-shelf third party tools. As our understanding of an area solidified and its rate of change slowed, we replaced the hand-connected Zapier system with well-tested code.

The business continued to grow, and it’s now alive and well as its own independent entity at jaimy.

I found our experience on the jaimy venture to be quite profound, so much so that I now often joke that I spend more time trying to avoid writing code than actually writing it. As software engineers we must always be aware that writing code is just one of the many useful tools in our toolbox. Jumping in and trying to solve problems with code too soon, without considering the other available options, can result in a longer learning feedback loop and higher initial maintenance cost.

As engineers, we must endeavour to stay humble, see the bigger picture, and write code judiciously when the time is right.

Interested in working with us at BCGDV? Want to find out more? See our current vacancies.

Find us on Twitter @DV_Engineering.