Causes of Poor Code Quality

07:05 Resume-Driven Development

Developers sometimes will pick a technology that isn’t appropriate for the task at hand and then try to hammer it into something useful. Developers tend to do this as they are looking at other job opportunities as well, leaving a mess behind and no one who understands it. Those in this headspace also tend not to document things appropriately as well, since that doesn’t do anything for their resume. Bleeding edge technology also tends to change rapidly, which may mean that anyone coming in has to learn the old way of doing it well enough to port it to the new way.

“Now there is some hacky … stuff … in my code.”

Regular code reviews are the best way to fix this. You have to catch them in the act. Make sure that coding standards are well-established and that any decision to bring in new technology is vetted by the technical team.

12:30 Expert Beginners

Developers get comfortable and tend to stay that way until something shakes up their world. Frequently, this means that they will resist newer technology, even if it does make sense. This resistance may cause them to copy existing code and modify it to suit, rather than abstracting things cleanly. They also have a tendency to use far more code than required to accomplish a task, as languages and platforms tend to evolve towards terseness over time. They also tend to coast in other ways and develop problems around their work ethic in some cases. This is a double-whammy when they are fired.

“It’s crazy to not be training some on your own time.”

Code reviews are a good way to do this. Developers who haven’t rested on their laurels should be teaching the expert beginners better ways of doing stuff. If your organization doesn’t have some practices around training developers, then that needs to be encouraged. While we think it’s crazy not to be training some on your own time, lots of people fail to do this. It’s reasonable for management to find ways to have on-the-clock training so that developers don’t get a stale set of skills.

18:25 Overwhelmed Developers

Sometimes management puts too much stuff on one or more developers on the team. This is insidious, because the options are burnout/overwork and cutting corners. Eventually people cut corners just so that they can have a normal life. The cut corners eventually show back up, but it can be months or years later. The developer may not even be there by then, or their contribution to the problem may be forgotten.

“They have so much going on that it’s do it the fastest possible way.”

Management needs to have a realistic idea of what developers are working on. In many organizations, it’s surprising how often this isn’t true. For instance, developers may be working on a couple of large projects, but also find themselves fixing bugs, mentoring junior developers, and going to lots of meetings. The time adds up and eventually, especially if the organization isn’t very smart about how they assess developer work, the overloaded developer will cut corners to keep their head above water. You fix this by fostering good communication between management and the developers regarding both workload and priorities. Nothing helps this if the company has unrealistic expectations and refuses to hire more help, however.

25:40 Sales-Driven Management

“Somebody’s getting their personal thing over everybody else.”

Some companies have a business model that requires them to constantly be getting more sales, just to keep the lights on. This typically means that development improvements are put on the back burner, just to get a sale. This can also mean that salespeople sell things that don’t exist yet, and development has to bail them out. This tends to result in a lot of friction between developers and sales, along with burnout of the development staff. In this sort of environment, you’ll often be encouraged to cut corners, so that a sale can happen, while not being allowed to go back and fix deep structural issues. When looking good next quarter is more important than being around in ten years, you won’t be around in ten years, more than likely.

This is a business model and cashflow problem, so developers are seldom in a position to do much. However, you can often help by either participating in the sales process in some way, or by building frameworks to make common tasks easier. This is a really rough spot to find yourself in, frankly.

29:55 Chihauhua Managers

There is probably a better term for this, but this is a good way to describe management that can’t make up their mind. This often happens when the manager reports to multiple people. This results in rapid changes in timelines, scope, and priorities. The codebase tends to end up full of short term hacks as a result, because the developers can’t make large changes. In this sort of environment, an unusually high percentage of the code is best described as Panic-Driven-Development.

“An unusually high percentage of the code is best described as panic driven development.”

This is a management issue, which generally speaking means that you can’t fix it. However, you can make it a lot less painful with a disciplined source control strategy. Branch per feature can really help a lot here. At the end of the day though, you can’t really fix bad management and you are probably better off leaving and letting the market do it.

34:10 Overly Involved Tech Managers

“They don’t understand the whole stateless thing or security.”

This occurs when you get a manager who was a developer a long time ago. They often have opinions that don’t quite match reality. You’ll see this a lot with people that developed desktop applications in the early 2000s and earlier when they pontificate about how web applications “should” work. These sort of managers often try to override the way that most developers in a language actually use the language. This can be especially amusing when you show them how the “this” keyword works in javascript and they realize that the language itself doesn’t work like they thought. It’s even more fun when they used it regularly for years. However, it’s very unhelpful, as they force you to do things in a way the platform hardly supports, and then criticize you when everything takes longer than it did back in their day.

You have to be able to show results. Even with the crappy and ignorant way that they are trying to force you to work. If you show outsized results, your opinion will get more attention than others. With that done, start fixing things quietly under the hood. Don’t ask permission for small refactorings that make the system work better. Try to take some time to show them how things actually work now. A lot of stuff has probably happened since the last time the person coded, and they don’t even know enough to be wrong in many cases.

42:15 Budget Cuts

Budget cuts can really damage a software project in a hurry. This often means fewer developers on the project, and frequently no provision is made for knowledge transfer. They may not even be employed there afterwards. This can also result in shortcuts being taken by the remaining developers, as productivity expectations often don’t change when the team shrinks. Budget cuts also tend to hit training budgets and budgets for purchasing software component licenses, servers, and the like. People tend to try to work around these problems in the best way they can, but this often results in very nasty code trying to hack things into working.

“What they value is not the same as what a developer values.”

This is very challenging to fix. You probably aren’t in a position to be able to do much about your company’s budget. However, when you do go to management, you need to show them how an idea you are suggesting actually impacts the budget. If you focus on doing the above, you are more likely to get buy-in and more likely to get moved up to a position that helps you have influence over the budget. You may also want to start looking for work elsewhere. A lot of budget situations don’t get better.

45:50 Sudden Team Growth

“This is the opposite of budget cuts basically.”

Sometimes a company will suddenly start being radically more profitable, obtain funding, or cut expenses. If they do, they often are tempted to hire quickly. While the quick hiring can often be an advantage over time, in the early phases of employment, it’s hard to make sure they are doing things up to standards. This can lead to a proliferation of coding styles in a project, along with a situation that is perfect for NOT having regular code reviews. The newer developers will also have a lot of pressure put on them as far as their productivity, so they are incentivized to cut corners.

Try to convince management to slow down the rate of hiring. Keep the new developers sandboxed into a small portion of the application, to limit the churn in the entire codebase. Show them samples of what is expected and take time out for code reviews to make sure everyone is sticking to standards. This assumes you have standards.

50:50 Insufficient Training

Sometimes a company will completely lack a training budget. Not only does this mean lots of expert beginners, but it means good developers leave. Good developers leaving often results in chunks of the codebase that aren’t well understood. And when less skilled developers have to fix it, they often break it. Really bad developers will stick around, while mid-quality developers may get desperate and start doing resume-driven development.

You can’t really fix this without a training budget. You should advocate for that. In the meantime, you can try to drag the rest of the team’s skill level upward. You’ll learn a lot, and you might help the situation. Another option is to leave.