Software design, Technology

Plan for legacy systems

The other day I was looking at some old Elm code, refamiliarising myself with one of the key language concepts (Signals) and found an article to help me. One part in particular caught my eye:

To truly add a level of responsive interactivity to our application, we need to understand Signals, Mailboxes, and Addresses. These are concepts which at first glance sound super complicated, but when you get used to the concepts, they start to make a lot of sense (and, if you’re anything like me, you start to question why you would ever do things in another way).

I’m not entirely sure why you would ever do things in another way, but it turns out we do. That article was written to explain Elm 0.16. We’re now up to Elm 0.19 and the concepts of Signals, Mailboxes and Addresses have been consigned to the bin. What seemed intuitive once is now historical. Elm 0.19 does things differently and seems at least as simple as 0.16.

We often talk about technical debt, which I usually think of as shortcuts taken for expediency which need to be addressed before their consequences become too costly. But even perfectly good ideas become out of date and expensive. Designs and systems which were once considered ideal are now awkward, cumbersome and expensive to manage.

Legacy systems aren’t legacy because they were inherently bad, but because the world moved on. We need to recognise this when we plan our time, organisational structures and resourcing, otherwise we can find ourselves with unexpected costly overheads.

Advertisements

Discussion

2 thoughts on “Plan for legacy systems

  1. +1 the gap between today’s state of the art and that of an existing system is a really interesting space to try and understand / make explicit. I do wonder how best the supporting design knowledge can be captured and kept with the system – for example, what would happen if there were no elm 0.16 docs available online any more? It gets worse when these systems depend on public libraries / dependencies that disappear *gulp*

    Posted by Gus Power | 5 December 2018, 10:40 am
  2. You’re right – there are legacy designs and patterns, as well as legacy systems. When I was working with people transitioning from COBOL to Java and Javascript they complained that the modern technologies had far too many tools and techniques to master. COBOL was a single system which handled everything that was (then considered) essential. But Javascript alone required required a whole string of individual tools that needed to be understood, configured and wired up. (Gulp was indeed one of them.) And then once into the software there were competing design patterns and techniques that might or might not be used. That kind of thing will arguably age worse than COBOL.

    Posted by Nik | 5 December 2018, 11:05 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Advertisements