Consulting: Working on greenfield projects and cleaning up messes

Sometimes when you work as a consultant you get to work on fun, new “greenfield” projects.

Other times, you get called in to clean up a mess.

One day in late-May, roughly 15 years ago, I started a six-figure consulting deal because some applications were a mess. They were failing intermittently, and the company had let one or more developers go.

The 1st Problem

The first problem I ran into was that nobody that was left was sure what code was running in production. Rather than use a repository like Git, the developer had multiple copies of code laying around. From the timestamps you could see what the latest code was, but you couldn’t be sure that’s what was in production.

Fortunately the code was written in Java, so I got my hands on the JAR files that were in production. I then ran some diffs on the different copies of source code we found to find some of the biggest changes. Then I extracted the desired class files from those JAR files — the ones that were showing the biggest differences. Then I decompiled those, did some comparisons, and eventually felt comfortable that I knew what codebase was currently in production.

The 2nd Problem

After that, I dug through the code and found that whoever wrote the code didn’t know what to do about exceptions. There were a lot of try/catch/finally blocks with nothing in the catch and finally areas, not even a //TODO comment.

So a lot of my “high-paid consultant” job involved walking around and asking the right people, “When this error happens, how should I handle this in the code?”

A lot of times all you could do was retry a few times and then send out an alert, but everyone agreed that was better than silently failing, because I could capture all the information about what I was trying to do and what the failure was. So my clients got very specific emails and/or Nagios alerts that they could act on.

IMHO, a nice thing about Functional Error Handling is that it’s such a formal thought process that I don’t think anyone would dream of not handling failures. When you’re writing a function you’ll recognize that (a) you have a try/catch/finally situation, so (b) your function will return Option/Try/Either/ZIO, and then (c) you would naturally do the legwork to handle the appropriate success/error values.

None of what I described took too long to deal with, but I thought it was funny that I would never have gotten this gig — which started a new, long-term relationship with this client — if the previous programmer had known what to do about those exceptions.

And unfortunately the client had to pay me to fix the old code before they could even consider starting a new project. I’ve been watching the Maine Cabin Masters lately, and it reminds me of them having to do “demo day/week” before they can start new development.