With our target audience on this blog ostensibly being companies or individuals who might need our services, I personally think real case studies of projects or clients we've had are the most useful thing we can write about.

Note: In such case studies, I do think it's better to leave out names and facts that would blow the anonymity of clients involved. First of all, we have some clients who've expressed explicitly that they don't want to be mentioned, even on an innocuous social media shoutout.

Furthermore, we really do respect just about everybody we've ever had a professional relationship with. But in discussing a case study honestly, we do want to call out some decisions that turned out in retrospect to be incorrect (as often on our part as on our clients), so we don’t want to be perceived as taking a shot at somebody or calling them out.


The Industry and Product - Factory Maintenance Software

We were contacted about taking over the code and maintenance of a factory maintenance product.

Factory Maintenance Software is a type of tool (in this case a web app) used to plan, track, and optimize the maintenance of machinery, equipment, and facilities within a factory. Its goal is to reduce downtime, extend equipment lifespan, and keep production running smoothly.

The real value of this product was for creating sensible and efficient daily, weekly and monthly maintenance routes within a large facility.


The Clients

The company that brought me on was a small little 3-4 person outfit from Chicago. They had invented this software about 10 years prior. They had about 15 companies as clients using in about 250 facilities total.

Since they were making software, a web-browser app, this would technically make them a software company

CEO - The CEO is a terrific old-school guy with a factory background who also has THE most Chicago accent of anybody I've ever met. I loved it. Also, he was a genius at creating the formulas that were the basis of the product. That said, he had no idea about software. Early on, I was talking to him with the goal of strengthening his copyrights on the product and he was wondering if I could print out the code for his lawyer. Like a sequential printout of the code that would be copyrightable. God love him.

Developer - The original developer was a flake. The dirty little secret of small firms like mine getting hired is: If we're brought in to take over a project, it's because the previous developer was either no good or a flake. I think in this case it was both. He was unresponsive, which is the cardinal sin for anybody in any business. He built the product over years on a contractual basis.

The code was ASP.net which is fine; but the code was a how-to on poor coding: undescriptive naming conventions like "variableA", arbitrary and inconsistent policies by similar actions being done in stored database procedures, or hard-coded, or formulas driven from a config file. It was barely object oriented. The code just for localization of language was some of the most bananas code I'd ever seen. In some ways, it's nice to replace somebody like that because anything we'd do would be an improvement; but it leaves a very messy sandbox to play in.

My Contact - A great guy in Nashville who'd worked with the owner previously. I really liked working with this guy. He was, de facto, the whole company. He was in sales, but he also reported bugs and also was the one helping clients with deployment.

In my position, your main contact person means almost everything about your experience. My contact knew exactly how shoddy the code was, how much it needed to be rewritten from the ground up, how sensitive or buggy the product behaved, and how much $ it would cost to do this right while he didn't control the purse strings. He's since moved on, and I'm still occasionally in touch with him. Terrific dude and a terrific employee.


Brownfield vs. Greenfield -- Redesign vs. Refactor

I don't need to go into too much of the minutiae about the code, but suffice it to say that it really needed a rewrite. My client knew this but they had real judgment calls on their hands whether it was worth doing, better to limp along with their business, try to sell, or call it quits.

It was beyond just "refactoring". Refactoring and redesign are both ways to improve software, but they differ in scope, intent, and impact. Refactoring is gentle modification - aprocess of improving existing code's internal structure without changing its external behavior. That wasn't going to get it done.

This needed to be redesigned and rebuilt. For starters, this would involve significantly re-architecting the whole system and all code components.

In short, the time was past for evolutionary improvements. It was time to start over with the code - even if we wanted it to accomplish the same functionality.

So, this became a "brownfield" vs. "greenfield" issue - which I've written about before. I was brought on to do brownfield work when everybody in our hearts and minds knew this really needed to be greenfield startover work.


Options & Ultimate Sale

Like I said, the founder and my contact both knew their options were to: 1) Limp along, 2) Throw money at a rebuilt, 3) Sell to anybody who would buy this, or 4) Cut their losses and the CEO would retire and the other two people there would be on the job market.

As it turned out, they found a buyer in a Canadian company who could use and sell something like it. It was a long process and I was heavily involved in documenting and helping them understand what they were getting, good and bad.

Though I did my best initially to help them limp along and fulfill their contracts and maintain a mostly-usable product for their customers - my best value in this process was to document and plan for what the purchasing company could do.

I helped them onboard for a period of about six months and eventually they had their programmers start over with a mix of on the shelf software and new code of their own, using the original product's functionality as their roadmap.


Lessons Learned

Everybody and I mean everybody involved with the original company knew a rebuild that they couldn't afford was the way to go.

We all knew it wasn't sustainable. Yet they did OWN and HAVE something of worth with the original product. They had several viable paying clients. So, the limp-along-til-we-can-sell plan doesn't seem like great software planning, but it was the only sensible move.

Doing the right thing for a product or deciding when to call it quits is nothing something that gets done in the abstract or in a laboratory. In the real world, sometime the right thing for everybody to do is to keep doing the wrong thing until you can find a white knight. At least that was true in this case.