All opinions expressed in in these episodes are personal and do not reflect the opinions of the organizations for which our guests work.
We tend to talk about IT in analogies. Words like API, Microservice, Monolith, and Data Contract aren’t widely understood, so we use familiar examples to help us communicate.
Some of these analogies are dangerous, however. One mindset is particularly insidious: Software development as a factory. In this mindset, there’s a series of steps to design and “ship” code—which then rolls out the factory door, hopefully never to be seen.
A far better, and more realistic, analogy is farming. Left untended, any software system starts to decay. Sometimes it just gets slower as more people use it. Other times, the software outlasts its anticipated lifespan, and things go wrong.
For example, did you know that Microsoft Excel can only use dates later than January 1, 1900? If you want to calculate the age of someone born before that time, you need to write some Visual Basic code, in order to ensure spreadsheets are backwards compatible with earlier versions. Software is full of compromises that made sense at the time it was created.
As a farmer, you’re constantly watering and weeding. As a manager of software, you’re constantly refactoring and updating, and removing bugs. We need to think more like farmers and less like factories. After all, just as an untended farm turns to overgrowth, so an untended software becomes a legacy.
That word—legacy—is fraught with problems. Thanks to our partners at Code for Canada, I had a chance to sit down with Sean Boots, Amanda Clarke, Gordon Ross, and Afua Bruce to talk about legacy modernization. It’s a theme for this year’s FWD50 conference, because building shiny new things often requires connecting them to rusty old ones—or clearing out the old things entirely.
In the FWDThinking episode we recorded, we touched on a number of vital topics:
- Why legislation and technology need to be much closer together, so we pass laws that can be implemented in tech—and understand what tech we need to create to enact the policies we want.
- The challenges of getting several departments to use a common platform (such as a web form, a sign-in process, a translation tool, or a notification system) rather than building their own.
- How to break a monolithic system into components that can be upgraded, changed, and re-used independently of one another, so we can innovate in parallel.
- The complicated relationship between private-sector “capture” and open-source toolsets.
- How we decide what government should build, and what it should stay out of, on the digital frontier.