Having support from your team is important
This might appear like an odd heading for my first point, however, I have to mention just how valuable it has been that we have a product owner, service manager, chief publishing officer and so on who all appreciate the problems that technical debt causes. We’ve been given the time and freedom to get on with finding out what problems Florence currently has and how we’d go about fixing them. I’ve seen stories of how bad codebases can become when technical debt is never prioritised by anyone other than the developer. Well, that definitely is not the case in our team (high fives all round).
Clear application state is vital
This finding (along with others) may seem obvious, but the fact is that the application state wasn’t being managed well and this caused us issues chasing down bugs on many occasions. The original implementation stores some state in global variables, which couldn’t be observed for changes or stopped from being changed. Whilst other state for components are held in the webpage (or the DOM). The latter had caused us some real problems with state getting lost and mangled on really slow machines.
We’ve done spikes into implementing Redux, which is a fantastically simple library that makes it easy to stop state being mutated and allows you to observe state changes. It’s a clear winner to help fix our problems with state and we’re starting to build it into Florence at the moment.
The beta took a toll on Florence
Florence had to evolve very quickly to keep up with the regularly changing beta website. This meant that what it needed to be able to do as a minimum viable product grew constantly. This meant that the code wasn’t necessarily in the kind of condition you’d want it to be in. It also meant that by the time we’d learnt a lot about what we wanted Florence to do it was already being used to do daily publishing. It’s difficult to say we could’ve approached it much differently, but nevertheless it impacted how Florence was built.
Clever people have solved a lot of our problems already
Spikes are useful
We’ve done a lot of spikes comparing different technologies, solutions and approaches. This might not be the right approach for all teams, but we found it helpful to be able to spend a bit of time exploring something without having to commit to it. Each spike would spark a lot of conversation and usually left us with a fairly clear answer to the questions we’d set out with.
It’s worth mentioning that we’ve learnt huge amounts about the limitations of the current build with the regular maintenance and updates we do for Florence. We also have great opportunities to explore new ideas or technology in our 10% time, when we spend one day a sprint working on something not necessarily related to our day-to-day tasks, like Google or BBC do. However, much of this knowledge has still ended up being applied when we’ve got round to doing the spikes.
Never fail, always learn
This is one of our Digital Publishing principles, so it’s good to see that it’s echoed in our daily work. At times we’ve invested quite a bit of effort going in a particular direction, and in some cases we’ve ended up deciding that it’s not the right way to go. We’ve learnt something new, so there’s no point persisting with something just because that’s the decision we made to begin with.
Write code that’s easy to delete
We’ve found that the way Florence has been written means it’s hard to pick out a bit of functionality and then try to rewrite it. There are lots of large components that are closely tied to each other, making it difficult to rewrite one without rewriting the other. For this reason we’d done a few spikes to attempt rewriting the most complex part of our application from scratch. After a few spikes we’d come away with an important realisation: we will never get it perfect and we’ll continue needing to refactor code, but we can make refactoring much easier for ourselves. If we build small components that are as loosely tied as possible, then we can more easily delete and refactor small bits of functionality without it becoming a mammoth task.
Other people have written about this too, so I suggest reading this blog post by programmingisterrible to further delve into this topic if you’re interested.
Building our own application was the right decision