It’s the People Stupid!

Jeff Atwood recently posted the table of contents of “Facts and Fallacies in Software Engineering.” I’m sure it’s no coincidence that the the section on “People” is first:


The most important factor in software work is the quality of the programmers.
The best programmers are up to 28 times better than the worst programmers.
Adding people to a late project makes it later.
The working environment has a profound impact on productivity and quality.

I wish more people understood these four facts. In 24 years, I’ve watched upper management pretend these things weren’t true over and over again with disasterous results. If you’ve ever been fortunate enough to work with great people in a well-run organization and also suffered the misfortune of working with talentless people in a poorly run enterprise, you know that it’s the people stupid! You can’t make up for bad people with “good” process or methodology. The rest of the 50 item list is interesting and useful, but you could go a long way with just these first four “facts.”

I’ve often said that the best programmers are 10 times better than the worst, but I can easily believe 28 — I’ve never actually tried to measure. The sad part is that be it 10 or 28 times, you never see the best programmers making 10 times the worst — at least not in my experience.

What’s That Funny Smell — Helper and Util?!?

I’ve been coding a long time and something I’ve come to realize over the last several years is that if you can’t come up with a good name for the class you’re working on, you probably have an outstanding design issue that you aren’t aware of yet. If your class includes the phrase “helper” or “util” then you need to come up with a better name. If you can’t, you’ve got a problem or you’re not really doing OOD. I’ve encountered a lot of designs filled with “Helpers” and “Utils.” I’m even guilty of writing a few in the past. But I urge you, for the sake of fellow coders everywhere, to come up with a better name and/or better design. “Helper” and “Util” don’t really tell me anything about your class other than it’s very likely to exhibit low cohesion.

If you’re writing Helpers and Utils, I bet they’re filled with static methods too. ARG!! Static methods can’t be part of interfaces which means you’ve tightly coupled yourself to a specific class, not an interface. As a result, you can’t easily write unit tests nor can you substitute a differnet implementation without renaming classes. All ugly, very ugly!!! I implore you to stop writing static methods. Object creation is highly optimized nowadays. New X().Method() is likely to be almost as (if not as) fast as X.Method(). Not that you’d really want to use that, but I’m just trying to ease you away from the static members. You will want to inject an instance of X somewhere in your run-time object hierarchy.