As a software engineer at Bulb, I’m sharing some of the things I learned about building a new product when your deadline is tight.
Lesson 1: Take time to plan
In the era of Agile software development, it's tempting to spend less time planning and more time building features. This is a mistake – project planning is still critical. It highlights things that have the potential to slow you down once the project has started. Francesca, our project manager, planned and managed the project. Here's what I learned from her:
Know your product
Francesca’s in-depth knowledge of the Warm Home Discount scheme meant she had a clear vision of what we needed to build and could answer questions quickly. At the beginning of the project, even before any software engineers were involved, she spent time getting familiar with the Warm Home Discount regulations and talking to Ofgem, the energy regulator, and BEIS, the ministry for Business, Energy and Industrial Strategy.
Build a timeline
We had a detailed timeline and knew the features we wanted to deliver each week. We used an online tool called Roadmap Planner Macro that we could integrate with our internal knowledge base, Confluence. Francesca made sure it was up to date every week. We met every Monday to check we were on track and if not, discuss the delays and plan around them.
Break down the work into small features
The smaller your features are, the faster you can build them and release them to your users. Francesca spent time breaking down and documenting all of the features at the beginning of the project.
For each feature she created a task list ('epics' and 'stories') in Jira, the tool we use for planning and tracking development. Each task included a description, acceptance criteria, links to technical documentation, and links to design. Everything a software engineer needs to get started.
Lesson 2: Engineer your system
Investing time at the beginning of the project to engineer your system and create a clear picture of what you're building is critical. We did a good job overall and got most of it right. However, as the lead, I made a few mistakes I could have avoided if I’d spent more time planning and engineering. Here’s what I learned:
Keep it simple
If the application is simple, its architecture should be simple. If not, it's likely to be over-engineered. Regularly taking a step back and thinking about the purpose of the project helps avoid this problem.
I love the ‘rubber duck technique’: explain what you’re planning to a rubber duck – or a colleague who knows nothing about the project – and you’ll spot the unnecessary complexity.
Explore your external dependencies early on
External dependencies are risky because you have limited control over them. The earlier you start using them, the more time you have to fix any problems.
In this project we had just one major dependency – an API serving us data – and thought we knew where all the weaknesses were. But we came across a couple of limitations in the final weeks of the project. This could have been avoided if I’d started using the API earlier on.
Go deep into the details
I spent time documenting the overall architecture, but complexity often hides in the details. In this project, I assumed every member would take the same route through the application, so each journey could be handled in the same way. This wasn’t true. I could’ve avoided this mistake by seeing it from different perspectives: imagine using your system, what happens exactly? How do you log in? What API calls are made? How does the data flow? How is the data mutated? How does the system recover?
Lesson 3: Be more than just a coder
As a software engineer your role is more than writing clean code to satisfy acceptance criteria. Here are the key responsibilities I think were critical to the success of our project:
You need to be engaged and question the work your team is taking on: why are you building this feature? What value is it going to add? Where should it come in your list of priorities?
I had a great relationship with our product owner, Francesca, so I felt comfortable challenging her ideas and playing devil's advocate. Questions like this aren’t always easy to answer, but they help the team focus on delivering the right things, at the right time.
Give feedback quickly
As a technical expert, it’s your responsibility to advise on the feasibility of a feature. Every feature has a price, whether that’s the estimated time to build, added complexity for your system, future maintenance or operational cost. This price should be shared with the product owner and designers, to inform the decisions you make. Having this discussion early on will save time later. It might mean that you need to abandon work you’ve already started, which can be hard, but it’s the right thing to do.
When time is short you need to prioritise and be pragmatic. This means doing things you’re not comfortable with, like going for lower test coverage than you’re used to, or taking shortcuts. So be prepared to accumulate technical debt and remember to repay it. As a software engineer, it's your role to record it and make sure it's addressed later.
For this project we created a running list of the technical debt we were building up. After delivering the first version of this project, my colleague Matt and I spent a week clearing it. This included refactoring code, improving test coverage and automating deployment. Don’t neglect or forget your tech debt. Just like financial debt, the faster you pay it back, the cheaper it is.
Putting lessons in to practice
Since writing this post, I’ve started work on a new project. This involves building a new system which talks to third party companies and APIs. It’s been a great opportunity to take what I’ve learned from the Warm Home Discount project and put that into practice. I hope some of these lessons are useful for you too.
If you liked what you’ve read, why not consider joining us? You can check out our open jobs, or reach out to us directly at email@example.com. We’d love to hear from you.