Hacker News new | past | comments | ask | show | jobs | submit login

The firm where I currently work has a rather huge Delphi legacy software. You'd be surprised how much is still being "extracted" out of if. The more modern (and better built, but I'm biased, as I'm part of the team developing it) web app, which is meant to replace the Delphi one, has not had the same success. It's picking up momentum though...



If it's better built then why hasn't had the same success? What are your metrics for "better"?

What does "more modern" mean exactly? I don't see that there's much value in pursuing design or implementation purity if the software isn't getting the same end user take-up.


The Delphi app has been continuously "enriched" with features and special cases, based on direct feature requests for each client that requested one. This has lead to the case where there are several thousands switches which need to work together, in every combination possible. They don't always work, by the way. The new app has selected the more relevant use cases and could be better structured and implemented. Modern means primarily a cleaned up UI, but also the dynamic way of customizing the GUI (defined per JSON and capable of on the fly changes for individual users or groups of users, instead of hard-code and compiled or yet another flag stored in the DB).

The clients are usually pleased with the web app but the project managers are a bit hesitant, due to the different installation process. The Delphi app has been sold/installed for well over 10-15 years and people are used to copying .exe files on a server. Copying files and .dll-s and tinkering with IIS seams to be less appealing...

The need to go "online" has been the driving factor for the web app.


It smells like the web app still has that new car smell. I'd guess that the web app will go through the same process of enrichment. The web app will get the special cases and direct feature requests and will eventually arrive at a similar state as the old application for similar reasons, just in a different implementation.


Spot on! This is not really something that the (our) developers can control. We're already seeing this. My point was that we could use the information gathered from the prior implementation and take better can and design the new app with a higher degree of flexibility, so that, when those special cases occur, we could, for example, change a configuration file, instead of the actual code.


My guess.. we're talking years of investment in a (presumably monolithic) "huge" Delphi system.

Either spend even more years adding the needed features while fighting the upscale hill.. (especially when introducing bigdata)

..or develop an alternative made out of simpler beasts: clean separation to avoid hydra scenario's. It takes time to beat that, but i see reasons to go away from a huge monolithic beast.


I don't remember hearing that the behemoth will be extended with large(-ish) new modules. It will receive several features though. The truth is that they can't just throw it out the window, especially with global scale clients still using it.


Assuming you're no longer in Germany, say hi to Vanessa and Tommy from me.


Sorry? I think you're confusing me with someone else :) FYI, still in Germany and don't know any Vanessa or Tommy.


Sorry, i just happened to hear the exact same story at an event recently. :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: