New software, and the cobbler’s children
This post takes a look at how we eventually scrapped our outdated intranet software, and made life better for everyone by building a new custom system.
The software that helps run the business
When I started at Freshleaf 13 years ago we had an intranet. It was built by one of our developers at the time, and it provided a home for some of our project and client data, and later, our timesheets. It was a tool we all used daily that was at least reasonably attuned to our workflow. And the beauty of it was that if we needed it to work differently or do more, we could just build that in.
But time went by, and the system got old. And the developers got less and less willing to work on it. It became clear that it was fragile, and editing the code was error prone. It was – let’s put it kindly – “of its time”. And so we ended up in that frustrating situation of having bad software. Doubly frustrating because here I am, sitting in the midst of a team of developers, managing the business and the projects on archaic software. It’s a classic example of Cobbler’s Children Syndrome.
It's referred to as Cobbler's Children Syndrome after the proverbial children of shoemakers who don't have shoes. Today, it manifests as tech companies that slack on their own tech, marketing and branding agencies that neglect their own marketing, and magazine editors who no longer write.
Enter intranet v2.
As usual, it wasn’t me moaning, hinting or pleading that motivated the genesis of v2. No, it was someone who found a new toy, and wanted a playground in which to play with it. One of the team wanted to get more familiar with Angular, and “rebuilding the intranet” was suggested as a suitable sandbox in which to try out the platform. Angular, for those unfamiliar with the intricacies of web development, is a development platform – a framework with libraries and tools intended to make building stuff more easy, more scalable, and all round more betterer.
A prototype was developed, and an API. But the itch to experiment had been scratched, and the journey from prototype to beta release is a long one. And then more time went by. I’m not saying that progress was glacial, but there was always so much client work to do that finding time for internal projects just didn’t happen, and the cobbler’s children were still distinctly unshod.
The beta release!
However, towards the end of 2019 things began to look up. There seemed to be an opportunity in the shape of some available time, and a fresh desire to see this thing finished. In December 2019 we achieved our first goal: parity with the existing intranet. Spending time building something you’ve already got – even if you’re building it better, isn’t the most motivating of tasks. But we needed the new system to be comparable to the old before we could really call it a release candidate.
Releasing the beta was exciting. We discussed how the testing would be handled, but in the end the key question was: would all our processes run just as smoothly using the new system as they did with the old? So, the only real way to tell was to adopt the new system and try.
Of course, data integrity was a key concern. We had intentionally built v2 to run off the same database as v1, at least initially. V1 was amended to be read-only, and v2 became the active version. We then trialled v2 for an entire cycle – for us, a five week period, based on monthly billing. We already had big plans for all the things we wanted v2 to do and to be, but it was baby steps while we made sure that the foundations were sound.
Relinquishing backwards compatibility
A couple of months later, it was time to take off the training wheels. The system tested out solidly, and the handful of minor problems that were encountered had been patched. But some of the new features we wanted going forwards depended heavily on re-organising the system’s concept of projects – and that required us to break backwards compatibility. Once we did that, rolling back would be – not impossible exactly – but fraught with issues.
The intranet is where we handle day to day critical processes such as timesheets and billing. It has ALL the data. Walking away from the known good (well, sufficient, anyway) v1 and moving forward with a new data structure and no real option to roll back was… yes, scary is probably the right word.
But the only way is forwards.
So we began work on restructuring how projects worked – starting with some very cautious moving and testing of data in a simple proof of concept. It all seemed to hang together as expected, so after much careful testing, in January we released changes that broke BC, finally and completely leaving v1 behind. Long live v2!
A new roadmap
Now we were finally free to begin planning all those new features that we’d wanted for so long. Better, more efficient processes. Integrations with other systems. Increasing the remit of the intranet to manage more elements of the business, because it can now do so effectively and completely to our specification.
We’re still limited by the time we can put into it – it’s an internal project and still has to play second fiddle to client work. But the new setup is infinitely easier to develop new features into. And the pleasure of defining the features around our workflows is surprising. I have joked that I need to get out more, but I’m genuinely excited by the roadmap.
Even the challenges are interesting. For example, it’s easy to define the way something should work based on the way it has always worked. But how much of “how it always worked” was controlled or influenced by the systems we had at the time? With a blank sheet of paper, you can re-imagine the whole process; but its surprisingly difficult to let go of preconception based on historical processes.
Then there’s the challenge of ‘what next?’. There are so many improvements and new features that we have planned, that prioritising and selecting just one to work on can be tricky; although it’s a nice problem to have. We’ve adopted a process of sprints, with features broken down into phases, to allow deployment little and often – iterative improvement. Each feature gets an MVP (minimum viable product) release, followed by further releases to enhance its functionality. Which also means that we can re-prioritise often if needed, pausing one feature after the MVP release, and putting the building blocks in place for other features that are needed.
Conclusion
There were times when I didn’t think we were going to get there with v2. There are always so many other priorities pulling on our time, and it needed a certain amount of belief and commitment to get it across the line. But the time spent is already paying off, slowly, in time saved, efficiency and error reduction. And also just in things being better. Life is too short for bad software.