Saturday, April 13, 2013

The Bad Code Problem - The Smooth-talking Garbage Guy


I think there is a major, fundamental problem in the software development industry. And it's a difficult, tricky problem to solve. That problem is managers hiring developers that write truly poor code, not knowing it, and letting them run amok, and even letting them guide other developers and teams.

The root of the issue is management not knowing the true quality of the programmers they hire. It's all too easy for a smooth-talking developer (that actually writes garbage code, hence smooth-talking garbage guy) to make himself look like the right answer in front of a manager that can't refute anything he says. It's especially more problematic when not examining a developer's code before a manager hires the developer. And even worse if a manager looks at the code and doesn't truly know if it's good code.

The problem is further compounded when misled manager guy (MMG) touts his developer to others within the organization. And to make matters even worse, the root of all evil in a company, the BOYM (bend over yes men) who are afraid to do or say anything about it.

Developers (and somewhat decent developers) can sometimes be awed by this STGG. I think I know why now. His systems are complex balls of mud, yet he can explain things in a way that can seem to make sense. Only through seeing through the bullshit, and going back to the basics of simple, clean, and elegant code, can you truly appreciate STGG for what he has built: an ugly system because he doesn't know how to do otherwise.

Good systems, regardless of architecture, have code that is simple, clean, and elegant. Period. A system with an awesome architecture, backed by terrible code, is a terrible system.

Bringing in a new developer, or architect, that knows how to do things better than the way things are currently being done, won't change things. At least not anytime soon. The system is the system, and the folks left to deal with it are constrained by it. In time, these new resources will look bad because they'll be associated with the current crop of problems. This is exasperating, especially if STGG has moved on/up to other departments.

How is this fixed? In enlightened companies this isn't even a problem. Software development is valued as a first-class citizen, and top-notch developers tend to run things. In unenlightened companies, it's almost impossible. The only thing I can think of is to hire an outside firm to do an objective analysis of the system. This can be expensive (although much, much less expensive than the hidden cost of not doing it at all), and since the system "works," nothing is usually done.

How do we stop this from happening?

No comments: