The tech debt death spiral

Here’s what the death spiral looks like:
  1. The company sidelines engineering’s concerns as a nice-to-have.
  2. The codebase itself quite literally becomes a “difficult work environment”.
  3. It gets hard to recruit strong engineering talent.
  4. The company’s best engineers start to leave for blue-sky work at other startups where the codebase is more enjoyable to work in.
  5. New features start shipping very slowly. Or stop altogether.
  6. Gradual attrition of all engineers who like building things until only “maintenance-style” engineers remain.
  7. Company falls irrecoverably behind the times.

If you accrue technical debt without budgeting time and resources to pay it off, parts of the codebase become too unmanageable to modify. Engineering deliverables get smaller and less frequent.

Gradually customers experience the zombification of your product.

Eventually the codebase goes bankrupt. And the only practical choice will be to rebuild the entire thing from the ground up—something which very few businesses ever get a chance to do.

Is Bulb at point 5 in the spiral? We know that there is a huge discontinuity in the code base between service for SMETS1 and SEMTS2 smart meters. This is technical debt that was likely incurred when quickly developing test services for SMETS1 without knowledge of how SEMTS2 might end up operating. Well written code (often with the benefit of hindsight) wouldn’t suffer this, and it would be easy to attach the two systems to a common billing API and customer data visualisation API. Bulb clearly have a lot of work to do in paying off technical debt.

How long before Bulb gets to point 7? Are they already there? Just from posts on here, we know that one of their best devs has left (point 6?) which is what has resulted in the much-requested data API getting delayed indefinitely.

Hi @Hooloovoo

In answer to your first question, we don’t believe we’re at point 5 in the spiral.

The problems we’re facing with the SMETS2 installations go beyond our code. From the DCC to the manufactures, we’re working collaboratively with our smart partners to ensure that any errors with the technology are fixed. This will take some time but we’ve already seen a significant improvement in the number of successful installations. Smart is complicated so it’s likely that we’ll always come across new problems to solve. But we’re confident that the installation success rate will continue to improve.

The issues with the smart meter roll out are industry wide. You can read about the problems that other suppliers are facing such as Octopus and OVO on their blogs and communities.

We let our members know in early 2018 that we would not install SMETS1 meters. This was because in most cases when you switch supplier, the SMETS1 meters stop being smart and revert to ‘dumb’ status. We didn’t want to install a technology that disincentives members from switching suppliers or have to install a SMETS2 meter at a later date.

Whilst it might seem like smart is the only thing happening at Bulb from comments on this forum, we’re busy developing other features across the business. You can check out all our new features on our app release notes, our blog and I’ll update the Open Road Map shortly.

Smart is an important part of what we’re doing but it’s not the only thing. We have over 20 teams at Bulb working on different aspects of the business.

Yes, one of our developers decided to make a life change and go travelling but we’ve since had lots of new and talented developers join teams across Bulb.

Thanks for the info @“Eleanor at Bulb”.

My thoughts were going beyond just the smart meter fiasco. I see all those devops roles Bulb had listed for close at the end of June got reposted on June 25 with a new closing date of July 24. I guess that means Bulb didn’t/couldn’t appoint anyone.

I also see there’s a “Python Engineer, Platform” role which I’m sure is new? I don’t remember seeing that.

The Bulb Platform team are building a completely Greenfield system for a set of core services responsible for things like Billing, Metering and Account Management. It’s the software at the very heart of Bulb’s business and absolutely vital to both our day-to-day operations and its future ambitions.

So Bulb are rewriting the whole platform in Python. Yeah, I’m still pretty sure Bulb are at point 5 of the spiral.

All my recent experience developing SCADA and system automation platforms is in Python. I’d be a pretty good fit to that role. Still not moving to London. Now where’s that thread about the possibility of investing in Bulb, I need to take my name off it …

Hi @Hooloovoo

We’re always working to improve our billing, payments, meter readings and communications. We want to make energy easy to manage so you don’t need to get in contact with us. That’s why we have over fifty engineers working in teams across the company to improve products like the Bulb account, app and our website.

We currently use external platforms but as our member base increases we’ve gradually been adding more of our own customisations on top of these external systems so we can maintain an effective service as we grow.

These are not new ideas or overnight projects. There’s no limit to improving things to make our members experience better. So no doubt you’ll continue to see more engineering roles come and go on our careers page.

The Platform team have grown from a team of six to around fifteen great engineers in the past three months because of how important this is to Bulb. We’re hiring more Python Engineers to join the Python, Full Stack, Senior and Principal engineers already in that team. You’ll probably continue to see more jobs advertised as the team expands.

The Platform team have released a lot of new features recently. We’ve not done a great job at Communicating these with you. That’s partly because there’s been lots of smaller changes and back end preparation work rather than member facing things. I’ll talk through some of them:

Improved statement emails
Our statements used to be generic and not that useful. They now tell you whether it’s time to submit a meter reading, whether you should set up payment methods, and various other things depending on your account. We’ve been slowly releasing statement features to give members personalised information so they don’t need to get in touch so often.

Soon we’ll give members a personalised payment recommendation based on their current payments and balance. We’re also working on automatically identifying when you have an unusual statement and giving a better explanation of why that’s the case.

Improved monthly payment reminders
Monthly payment reminders have had the same treatment. They’ll intelligently tell you whether you submit a meter reading, set up payment details or do other key actions to take care of your account.

Different comms channels
We’re working on dynamically sending comms through different channels when one fails. For example, if your email address bounces and we need to send you important information about your account, we’d want to text you instead. At the moment it’s manual and inefficient. This will increase our delivery rate of important messages.

We’ll to make emails more personalised so you get even more useful information about your account. This is a way down the backlog because there are hundreds of comms, they’re mostly already in a good state, and they proportionately account for a much lower percentage of our comms compared to the statement and reminder emails.


God help us all.


God help us all.

Nowt wrong with Python. What language would you prefer?

Fifteen people to add a bunch of if statements to an email generator. Truly cutting edge. What a time to be alive.

All of that is the very definition of technical debt and point 5 on the spiral. There’s no excuse for any of that being missing from day 1, it’s all just the basics of what’s necessary to operate. Lets just hope that all the rebuilding and refactoring to resolve early short cuts doesn’t take so long as to get to point 7.

The appearance of Bulb at the moment is that they are some way down the spiral. The lack of soild honest information about SMETS 2 points that way. In fact I’m seeing signs of : “Gradually customers experience the zombification of your product.”

1 Like

Nowt wrong with Python. What language would you prefer?

There is plenty wrong with it being used at the backend. This is typical front end ‘everything is web’ attitude towards development - not yours, bulb. Using tools that were not designed for the job, but adopted because of front end familiarity.

There is plenty wrong with it being used at the backend. This is typical front end 'everything is web' attitude towards development - not yours, bulb. Using tools that were not designed for the job, but adopted because of front end familiarity.

Really? I think the opposite. Python is fine for backend work. It’s the people who force Python to be something it’s not, by the use of “web frameworks” to force it into a front end role, that are doing it wrong. Proper front end designed-for-web development languages don’t need “frameworks” to make them work.

Python? In my day I used Algol, Fortran, Pascal, C, and assembler.

Python? In my day I used Algol, Fortran, Pascal, C, and assembler.

Pascal, Forth and C

Python is for Kodi TV box development, and it’s not even good for that!

Enough! Just wish Bulb would get whatever to do whatever - correctly.