In 30 years of writing code, I've been asked to do one thing more than anything else. That is - to go into an already running project, half way to two thirds done ... and "help out", or or "assist".
As a general rule this is a euphemism for "OMG, the projects in trouble and we need someone to fix it!" Me - being that someone.
I typically find completely disorganised code bases, no testing, cut-n-pasted code everywhere, Zombies, memory leaks, God classes, hacks, miss-used APIs, no CI, and a bunch of developers from several camps. Learners who are out of their depth, mid level coders following a number of bad practices, senior developers beaten down by an out of control project, and the odd developer who simply could not be bothered anymore.
There are lots of reason why these projects have ended up in this state. Like any aircraft crash there is rarely one single reason. But there are always a lot of excuses, ... loooots of excuses.
One that I always comes out when I start asked questions about the code is - "Of course that's what should be done, but we didn't have time!"
It's like the most over used excuse of all time. There is another old saying - "If I had a dime for every time ...". Never more true here. But the real question is - is it true? does hacking (not in the good way) really produce results?
Personally I think there are a number of things that occur. It goes something like this: The digital agencies go in first. The type that promise amazing apps done in a matter of weeks, less if you believe the hype. Now setting aside the truely aweful code their mediocre programmers (and I hestiate to give them that much cred) produce, the real problem is that they give the clients a false picture of just what it takes to produce a app. So by the time the client finally figures out they are not worth the money and throws them out, he now has the firm belief that amazing apps can be produced in a metter of weeks and updating them with new features in less time than that.
So in comes the second development team. Usually from a more reputable software company. Their problem is that they have now inherited an poor quality codebase and unrealistic time frames. They attempt to instigate some sense, CIs, testing, and some elements of good design. In other words, exactly what they have been hired for.
But the clients - not being developers, not really understanding the complexities of their needs or software design, and not really understanding why developers would want to write code that does nothing but test other code - nod politely and keep asking when can they see Results!
The developers, by nature alway want to help, so they resort to hacking code, in pretty much the same way as the original programmers did. And we are back in the same old cycle with the code just getting more complicted and buggy.
So when I finally turn up and ask the question - "Why don't you stop writing crap and start sorting out the mess?", and I get the answer - "Because we don't have the time."
Actually I think they do.
My experience over many such projects has been that the code bases almost always suffer from the same meladies:
- Class bloat - large classes populated with lots of flags, counters, indexes and other sorts of state variables. Most of which are often redundant. Lots of complex and unnecessary code.
- Unnecessary 3rd party APIs, classes and code that is no longer being used. Yet is being kept in the code base.
- God classes - the SRP is something I constantly find missing, especially in iOS code.
- Cut-n-paste - code which is cut and pasted from one class to the next. Usually accompanied by ...
- A complete lack of OO design - no class abstraction, class structures, layers, service design, interfaces, facades. Often a symptom of a "Paint by numbers" developer.
The problem with all of this is that fixing bugs or coding new features becomes very time consuming because you have to wade through so much to do anything. This imparts a constant drag on the developement team which only gets worse as time goes on. Something that should take no longer than an hour or two to do can take days because it has to be repeated all over the place or debugging it is complicated by the complexities of the code.
So the developers don't have the time because everything they do takes so long.
Lets get this out of the way - Yes, sorting out the code will take time too. Nothing is free. Over time, as stuff gets refactored, re-written and cleaned up, some tasks will take longer than the quick hacks. But what follows is the payoff.
After a while things start to speed up. The code becomes clean, features become easier and quicker to implement, involving far less code, bugs become rarer, and whats more, developers start to enjoy their work.
To get to this place though, developers have to stop making excuses and start doing the work. This is perhaps the biggest hurdle I come across. Convincing them, often by showing them the results, that it's worth it. And as frustrating as that can be, in the end it's worth the effort. I only wish I could find quicker ways to get people to stop and think.