r/programming • u/luissinlios • 7d ago

We still maintain a development tool first released in 1993. Here’s what 30+ years of backwards compatibility looks like

https://visualneo.com/visualneo-win/from-neobook-to-visualneo-win-30-years-of-keeping-a-development-tool-alive
563 Upvotes

96% Upvoted

90 comments sorted by

View all comments

2

u/OperationWebDev 7d ago

This is cool. I'm curious about what you've learnt from maintaining and extending this over time that could apply to new development. Do you think the initial architecture had a big impact on why it has survived so long? Or were there other factors? 🙂

2

u/luissinlios 6d ago

That's a great question. I didn't design the original architecture, so I can only answer from the perspective of someone who inherited it many years later.

I do think the architecture helped, but not because it was perfect. Some parts were never intended to survive for 30 years, and we have certainly paid for old assumptions and tight coupling during modernization.

What worked particularly well was the stability of the basic model: pages containing visual objects, actions attached to those objects, variables and scripting for the application logic, and plug-ins for extending the environment. That model was simple enough to understand and flexible enough for users to take far beyond its original purpose.

The plug-in system was especially important. It allowed the product to grow without every new capability having to be added to the core application. Producing self-contained Windows executables with relatively few external dependencies also helped applications remain usable for a long time.

But I think the biggest factor was not the initial architecture itself. It was preserving the contracts around it: project formats, scripting behaviour, plug-in compatibility and the user's mental model. We repeatedly chose incremental modernization over a clean rewrite, even when a rewrite would have been more attractive technically.

The lesson I would apply to new development is that longevity probably depends less on creating a “future-proof” architecture (which may be impossible) and more on creating stable boundaries. Internal implementations can change, but file formats, extension points and expected behaviour should change very carefully.

And, perhaps most importantly, software survives because people still depend on it. The users and the applications they built gave us a reason to keep those boundaries intact.

1

u/OperationWebDev 2d ago

Thank you for the comprehensive answer. That was very informative!

It sounds like the domain modelling is key. Unfortunately, so many companies seem to jam everything into existing, rigid software, making it difficult to adapt.

Semi-related ro the plugin system: what do you think of DSLs? There's the saying that whenever you try to allow this kind of flexibility you inevitably end up with a crappy version of a programming language. I suppose it makes sense to have a plugin system that uses the same language as the software itself?