I’m Michael Carr and I am the Founder of UK startup - GoRoadie. I started GoRoadie (https://www.goroadie.com) with the aim of helping driving students in the UK find the right driving instructor for them. Think AirBnB for driving instructors.
During the 9 to 5, I’m Software Development Manager at Amazon (Edinburgh, Scotland) where I lead a team of eight on internal HR projects. Previously, I lead a fast-paced development team at FindMyPast (Dundee, Scotland), I even acted as an Agile Consultant for many teams where I helped delivery in several locations. On top of Amazon, I have worked in Sony Entertainment(London), and Realtime Worlds(Dundee), having worked in software for 10 years, I have a passion for lean and agile delivery.
Every development team has suffered from Technical Debt, and most developers love refactoring these issues into the early hours, like an accountant making sure the books balance on the eve of Christmas.
Sometimes though, software teams focus too much on technical debt than key business metrics, or sometimes we focus too much on features and not enough on software architecture which bites the business later in development. When thousands are trying to build startups and business are trying to move rapidly, how do you balance acquiring technical debt and feature delivery. Simple, stop seeing it as debt.
What I am going to propose goes hand-in-hand with Eric Ries’ The Lean Startup (2011). One of the key takeaways from Lean Startup was to validate your hypothesis by using minimum value products (I know this is 2018, and here I am still talking about MVPs). As a development team, you could build software as if you were running an experiment, have a clear hypothesis and measure to see if your assertions were correct.
In 2018, developers should be used to developing with uncertainty like this; shipping code and measuring if the changes are having any impact on key metrics. There are a number of methods that allow teams to release code and to accurately measure the outcomes like A/B testing. By releasing code and measuring the impact (or value), the team is aware of what changes/features have value to their customer, then you repeat this cycle to continue building a successful product. This build-measure-learn cycle is key to fast and scientific development. By building features in this fashion, developers will know where to spend the time and effort as the results will be clear through experiment outcomes.
Technical debt is like a loan — having to pay off interest. and sometimes its too much and you stop enjoying life… or development. Not good.
I will talk through technical debt; what it is, why we call it debt and what real impact it has on the teams, the individuals and the business.