It’s OK if you’ve made wrong decisions in a project for the right reasons
Making decisions in a project is not always plain sailing
Right at the start of the development of the Squirrel designer, we set ourselves some very aggressive timescales to launch version 1.0. To help us achieve these timescales, the development team agreed on some foundation principles to follow. One of these principles was to use “best-in-breed” frameworks and 3rd party components where possible. This would save us writing everything from the ground up. It would allow the development effort to focus on integrating these components along with our own code giving us a win-win on two fronts:
- we wouldn’t have to invest time in re-inventing the wheel; and
- we could still build a strong and scalable product.
Problems appearing out of the woodwork
As the project entered the quality assurance and alpha testing phase, we faced some challenges with one of the main 3rd party libraries we were using for the embedded spreadsheet. Problems started to appear. Whether down to bugs in the product or our non-standard way of using the component, we were having to come up with workarounds or work closely with the vendor’s support team.
Identifying the root cause
The 3rd party component was designed to be used as an embedded spreadsheet within a website — useful for performing “Excel-like” actions and importing and exporting the spreadsheet. We needed that functionality in Squirrel, but we also wanted to connect the values in cells to our components so that the spreadsheet updated the component and vice versa.
Herein lay the problem: the 3rd party library wasn’t designed for that. Although it had some of the APIs to achieve what we wanted, the more we used it the more we were straying into uncharted territory for the framework. The knock-on effect meant support issues were being logged with the vendor and fixes were estimated to take six months. This was an issue we needed to address, especially because the spreadsheet is such an integral part of Squirrel. We needed to do something to significantly increase our response times to these spreadsheet bugs.
Problem-solving in technology projects
It was time to pause and reflect. At the start of the project, we estimated it would take approximately six months to build our own spreadsheet component. This estimate was mainly derived by the sheer volume of unknowns that we’d have to work through and solve. However, as the project progressed, our understanding of what we’d need and how it would integrate with Squirrel, evolved. In October 2019 (three months before our go-live date) the decision was made to make a u-turn and to remove the 3rd party spreadsheet and build our own.
The ideal project process versus reality
Cons of rewriting the spreadsheet
This should have been a difficult decision to make. Remember how we purposefully chose an external spreadsheet at the outset, to save ourselves time? However, when looking at the bigger picture, the decision to rewrite this part of Squirrel became a no-brainer:
- We were spending more and more time fixing bugs or finding workarounds.
- We didn’t have the level of control we wanted over the turnaround time of issues logged with the vendor.
- We were uncomfortable with not having absolute control over the support and workings of such a key component of Squirrel.
The revised estimate for writing our own spreadsheet component came in at around four weeks. We green-lighted the development immediately. We had a new round of beta testing starting imminently and we wanted to get the new spreadsheet in before that so we could put it through its paces.
The decision to build our own spreadsheet would lose us four weeks of time on fixing spreadsheet bugs. We also ran the risk of introducing new bugs with our new solution.
However…
Pros of re-writing the spreadsheet
Because we’d know the codebase inside and out, this gave us the confidence that any new bugs could be fixed quickly and efficiently. It was a worthwhile trade-off and the benefits have been seen many times since the launch, including:
- A quick turn-around for creating missing Excel formulas.
Previously this would have required us to raise a support ticket with the vendor. We’d then wait for them to prioritise the development and make a release. Only after this could we implement, test, and deploy in Squirrel. Now we can create the formula and deploy it in the next release of Squirrel.
- Significantly reducing the size of a data model.
We noticed that the size of the data models in the exported projects was excessively large for complex spreadsheets. Previously, we spent large amounts of time understanding what the framework needed in order to strip out the superfluous data. Instead, we were able to immediately rationalise the data and its structure to be more efficient. And in parallel, we changed how the data was compressed to make it more efficient.
It was so efficient we were able to turn a 28Mb spreadsheet into a 600Kb data model (a 98% reduction in size). And this only took 4 hours to code and implement!
Squirrel’s spreadsheet component
Happy customers mean happy developers
With the spreadsheet now firmly in our control, we can provide accurate estimates for how long bugs and feature requests are going to take. We can schedule when the code changes will occur, and more importantly when these changes will be released in the product. Looking back at our initial foundation principles, the decision to leverage best-in-breed frameworks was the right direction to go, at that point in time.
Squirrel still has 3rd party libraries in it but we are continually reviewing the benefits that these frameworks provide compared to the responsiveness to change we require.
Writing our own spreadsheet at the start of the project would have been the wrong decision. However, changing our minds later in the project and building our own spreadsheet was absolutely the right decision to make too. It just proves that a project u-turn in software development can reap rewards.
Want to learn more about Squirrel? Keen to start building apps from your spreadsheet? Take a look around our website to find out more.
