Hacker News Reader

Comment by dejv | Hacker News Reader

I make living off desktop app in construction industry. The app is 21 years old and is still written in Delphi 5. I still actively maintaining it and it runs fairly well on modern Windows OSes, but there were some low level problems in recent years.

We are team of two: I am sole developer and there is another person doing sales, support, training and all the rest of stuff.

View on HN

What are the low level problems you have been running into?

Three main things: - memory space for printers and sound cards changed in Vista, so when you have some constellation of printers and you change the printer in dialog whole program just crash, because it is trying to touch restricted memory or something.

- running Paradox in network is quite difficult. Whole database was written in 80s before things like tcp/ip was thought as a good thing and all the networking part was hacked inside and it shows. Because of weird architectural choices made 20+ years ago I am not able to migrate out to sane database without rewriting whole application. (250+k lines of code)

- BDE could be quite unstable in various scenarios and you spend quite a lot of time fiddling with memory space, memory size and other variables to make it work.

Can this functionality be separated out into a different process, or called from a DLL compiled using Visual Studio?

Probably not: the application has around 100 printouts (with tons of spaghetti logic behind it making it impossible to count all variations) and it will be very hard to switch to new reporting framework.

The big problem with legacy software without huge user base and limited space for growth is that it just don't make sense to invest huge amount of time and money in it.

This is funny. I saw the same pattern in Smalltalk apps: Reports being the locus of spaghetti code.

Reports are added as an afterthought. Then the resulting spaghetti code patterns are replicated cut & paste, where they then slowly melt into surrounding code in a way that makes them impossible to extricate. After some years, it then becomes obvious that reports are the primary driver of value for those clients.

Ugh, this. Have you had luck escaping that hell?

I knew enough to keep myself away from those projects.

Yeah, I tried to migrate out of that mess into other tools and it ends up as even bigger mess. Now I do have three different reporting systems in three different technologies (QuickReports in Delphi, code that generate HTML code from inside Delphi code and then XQuery based declarative code that can be customised by (/for) customer) and I ended up in even deeper hole.

Thanks for the explanation. A lot of my code is getting old (just like me), but I was lucky in that it was designed from the start to be cross platform. This ended up meaning that it was written in C and all the platform specific code was kept as separate modules.

My big problem is I have so many code paths that I can’t fully test the interactions between the different modules and functions (there are over 10^25 different possible paths). I am not sure what can be done about this given the functionality of the software is critically dependent on this flexibility. The best I have been able to come up with is testing 99.99% of the most popular paths and building in a lot of error recovery code.

>My big problem is I have so many code paths that I can’t fully test the interactions between the different modules and functions (there are over 10^25 different possible paths).

Interesting. Have you considered the pros and cons of writing a custom fuzzer for your app, and whether it may help?

I actually have written a custom fuzzer. It has been really useful in chasing out bugs caused by improper handling of corrupt files, but fuzzing won't help solve the combinatorial coverage problem.

>possible paths

But don't all those paths depend on the inputs, ultimately? Trying to understand this here. Can a fuzzer that generates lots of different inputs, not be used to exercise all those paths?

Not when you have 10^25 paths to cover and each path takes around 2 seconds.

Wow. Got it.

> (250+k lines of code)

How big is the EXE?

6 mb for typical binary, but there are around 10 different exe files compiled from this codebase, most of them overlaping and sharing big portion of functionality.

Let me know if you need help. I belong to a network of Delphi devs that can join your cause. Cheers.

Is this the only app you maintain on daily basis? How did you get this client and how did you start this software?

Hard question. I am working on this software for almost 10 years now and there were times where I was working on it fulltime, there were times I was also working on numerous other apps and businesses, and also two years when I basically quit the tech industry to focus on wine making, but keep working on this app for couple of hours a week just because I don't want to let my business partner down.

Currently I am also doing some freelancing (iOS apps) and run my other tiny software company.

Starting this partnership is actually funny story: one day I seen an ad which says "Looking for programmer" and there was no other information or text, no company info nothing. At that time I was product manager with big team reporting to me and I feel quite unhappy, missing my days as a programmer, waking up at 5 am to do some coding for fun. I seen it as a sign, so I just replied, quit my job and the rest is history.

Great serendipitous story.

Reply on news.ycombinator.com