Science does not promise absolute truth, nor does it consider that such a thing necessarily exists. Science does not even promise that everything in the universe is amenable to the scientific process. - Isaac Asimov
I’ve been reading a lot of articles lately outlining what defines a bad programmer. I find this to be a particularly interesting topic myself as often times I am accusing other programmers of being “bad”. Upon reflection, and after reading these articles, I must admit, this is an unfair term. The term “bad” in this context is completely subjective. By calling someone a “bad programmer,” you’re applying standards to them which aren’t universally true. It would be a fair assumption to say that we’ve all wrote “hacks” in our times, and on many occasions, those hacks were out of the necessity of the situation and not what the developer would like to do.
What I’m getting at here is that there aren’t bad programmers, there are bad programs… and even those often aren’t “bad” if they are taken into context. So what does all this talk of so-called “bad programmers” actually mean? It means we’re frustrated. It means we, as developers, strongly desire some metrics for determining “goodness” or “badness” of not only the code of others, but even our own.
Why is this still a problem? After over fifty years of code, we still cannot figure out what makes a program good?!? That would seem like a problem… on the surface. It’s not. Here’s why:
The Philosophy of Code
As programmers, we expect our code to do two things: Work or Not Work. And when it doesn’t work, we expect to be able to fix it after testing. Black and white thinking. It either works… or it doesn’t… and if it doesn’t… it should and it will.
The concept of good and bad aren’t just subjective and intangible, they’re completely non-existent in the realm of programming quality. Unless such metrics are created, and they themselves are immutable and empirically verifiable, then the best we can do is judge a program based off whether it actually does the tasks it was intended to do.
For instance, I consider myself fairly good at interface design. However, every single time I choose an interface revision that works to publish, there’s someone, bless their soul, who cannot deal with concepts such as, say, “drag and drop”. These people are a strong minority, but to them, I’m a terrible interface designer because it doesn’t work for them as they cannot understand it. This does not mean the interface is bad, it does not mean I am a bad interface designer, it does not mean I’m a bad programmer. It means that they would have done it differently.
What’s bothering me is that all these articles speaking of “bad programmers” are being extremely unfair and hypocritical. Much of the code they write, I can guarantee there would be someone out there who looks at it and says, “I would have done this better.” And that is exactly the problem; black and white thinking applied to a gray area.
The Metrics Being Applied
Does it work well?
- If no, bad code.
- If yes
- Can it be better? (subjective)
- If yes, bad code.
- If no
- Why can’t it be better? (subjective)
- (enter list of excuses here)
- Why can’t it be better? (subjective)
- Can it be better? (subjective)
The Only Metric That Matters
Does it work?
- If yes, good code.
- If no, fix it or start over.
What This Means
We want programmers to write nice code. We want modularity. We want good organization. We want the code to be decoupled. We want to avoid copy and paste. We want everything. What project has time for that? The only projects I’ve ever seen that are like this and remain like this are open sourced projects run out of love and not for money. They have no deadline. The quality is the goal as it’s the only feature that will keep users using is and, in turn, contributing. This is not a reality in the business world. In the business world, quality comes second to deliverables. Make the milestone, at all costs. And the first cost to go is code. Why? There’s actual profit to be made in doing so!
If coders were left to code. If coders coded for love. If coders didn’t have to worry about their jobs… if they did it out of love… well then of course the code would improve. They’d do everything in their power to improve their code.
All this talk about bad programmers is categorically false. There are uneducated people in programming positions, yes. There are incapable people in programming positions, sure. There are people in programming positions who cannot “hack it”, of course. But this talk of “bad programmers” aren’t defining standards for spotting these people. Those people *AREN’T PROGRAMMERS*, they’re script kiddies or charlatans. What we’re talking about are real programmers: people employed at companies, people gaining contracts, people who contribute to open source projects. That’s might haughty of these authors of these articles to tell such people that they’re bad programmers because they do not know certain things that they probably do not even specialize in or use.
What’s more is, look at what they are asking people to know? 25 years ago, knowledge of OOP would be a minor point. Now it’s a major point. Right now, knowledge of functional programming is a minor point. 20 years from now, who knows. Now, knowing about assembly languages isn’t a big deal. 20 years ago, it was a huge deal. If you can code (and by that I mean, write code that works), you are a good programmer.
In summary: does the code work? If so, it’s good as is whoever wrote it. If you need more requirements later and the program needs to be extended to make it work, consider that a separate program then apply the same metric… does it work? Talk of anything else immaterial as it’s a subjective qualitative assessment.
July 5th, 2008 at 2:23 pm
,—-
| In summary: does the code work? If so, it’s good as is whoever wrote
| it. If you need more requirements later and the program needs to be
| extended to make it work, consider that a separate program then apply
| the same metric… does it work? Talk of anything else immaterial as it’
| s a subjective qualitative assessment.
`—-
You are laboring under the mistaken impression that such questions
have consistent answers. In the general case, they do not.
In the case of this particular question it may have different answers
when posed to different interested parties. In fact, the same actor
may answer the question differently at different times or under
different circumstances.
I do not believe that this is a very good metric at all.
Of course this is blatantly an opinion on my part.
July 6th, 2008 at 2:07 am
Historical evidence shows that in any kind of job there are all kind of people spread across a continuum from really bad to really good. Since this is true for engineers, musicians, cooks and so on, then it must be true for programmers also. And I know many of good programmers, many decent programmers but many more bad. And they are not script kiddies. They work 9-5 and they earn a living by writing software. The fact that we don’t have a reliable way of measuring the quality of the work is not equivalent with having a binary scale with only good and bad values for quality. Your “does it work” metric is not correct because in software the definition of “does it work” is very complicated.
“Does it work” as in functionally does the job?
“Does it work” as in it is easy to use?
“Does it work” as in it is easy extend?
“Does it work” as in it is easy to modify?
…
July 6th, 2008 at 12:06 pm
I think you both raise some very good points.
@leed25d:
I do not think I actually ignored that point all together. In my defense, I did state that not matter what someone does, there’s always going to be someone complaining. That does not mean that the code or the coder is bad. It just means that it either bothers a small minority or it needs to be changed to accommodate the greater good. As far as that goes, there is a consistent answer: Does it work? That question is answered by the requirements of the project.
@Daniel:
Like I stated above, these questions you ask have answers… the question is whether those answers are important. I say they only are if that is what the project requires. For instance, “is it easy to extend?” As far as I’m concerned, that question is ridiculously laden with qualitative assumptions which can never be measured. Then you have the satisfaction problem which I addressed above with leed25d.
However, this does raise a good point… what does it mean to “work”? Well as far as I’m concerned, if it comes down to time and money, it means it meets exactly what the specifications say it does, and not a letter more. This burden of second guessing specifications often leads programmers to causing more problems for themselves.
Here’s a real world example: York Co., Va requested a simple search engine be built for their services which would poll someone of what their situation is and give a weighted list of solutions to departments which solve that situation. They paid a developer $500 to build this simple application. What they did not tell him is there A) needs to be a particular weight order and that has to be able to change as departments shift responsibility and B) they need to add departments at will. Now when I first found this out, I cursed his name and called him a terrible programmer for not offering those services… then I started to realize… he’s being paid $500. Would I go the extra mile for a small client like that? Hell no! Does this make him a bad programmer? I don’t think so. His code wasn’t extensible because it wasn’t meant to be. Does he do that consistently… for a $500 client… yes. I know I would for small jobs. Is that ethical? Who knows, I don’t believe ethics is really relevant to the conversation anyway.
The point is, those questions can be answered if you addend the phrase “Does it work” with “Does it work to specification.” That, I thought, was implied, but I guess not.
July 6th, 2008 at 10:25 pm
Hi Collin :)
I see your point in that situation. On the other hand you have to admit there is a full range of programmers out there. You cannot say every programmer in the world is as good as Linus Torvalds :) just because their code kind of works. Some programmer can start and end a given task alone, others can only start. In big enterprise projects the good programmers most of the time compensate for the the lack of skill of less good programmers. This is done by mentoring and by allocating to them really well defined tasks already designed.
July 6th, 2008 at 11:18 pm
@Daniel
Thanks again for visiting my little site here :-)
Yes, I see what you’re saying. But … isn’t the ability to design and finish programs the definition of a programmer? Are those other people really programmers? I don’t think so, but that’s become a linguistics issue.
July 7th, 2008 at 12:14 am
Perhaps a more important metric is “are customers paying for it?”
This is the end result of “does it work?”
July 9th, 2008 at 3:02 am
Correct then beatifull then fast, wasn’t it? That good make a good program. That said there are bad programmers even if they make (seamlessly) working programs once you add other variables
July 9th, 2008 at 4:15 am
First of all, even if it works now it will need maintenance. It _will_ have bugs. If you think it won’t then sorry, you’re a Bad Programmer. So being able to maintain the code is part of the definition of “it works”. And in fact, if it stays in a maintainable state _during_ development, you’ll be able to develop it quicker and with less bugs - getting to the “it works” stage quicker.
Even if you’re working on the 1% of projects that is written with the intention that it will never be maintained, it probably will. This is an _implicit_ requirement of every project. So “it works” is nothing without considering how well it can be maintained. Then if you actually _are_ expecting to add features…
In short: code is for human beings to read, not computers. If you don’t realize that, you _are_ a Bad Programmer. Hopefully next time York Co will hire the better programmer charges $600, but they probably don’t know the difference. If you do, then maybe you should inform them.
July 9th, 2008 at 9:11 am
[...] recently wrote a post called The Reality of Bad Programmers, I made an assessment that so long as a program is to specification and someone is buying it, [...]
July 11th, 2008 at 3:03 am
What’s your thesis here? That labeling someone a “bad programmer” is most likely unfair? That’s something I can agree with, but you’re not supporting that point very well.
You’re listing out a series of statements in stream of consciousness style without actually building an argument. You’ve got to start with some premises that people can get behind. Some of your statements seem reasonable, some seem flat out wrong, but in any case they’re not cohesive.
Take this paragraph:
“As programmers, we expect our code to do two things: Work or Not Work. And when it doesn’t work, we expect to be able to fix it after testing. Black and white thinking.”
This is a strange statement. Are you trying to show that programmers think in black & white? Of course the question “does it work or not?” is (usually) a binary proposition, but you say it as if this question is somehow indicative of a more general mental process of programmers.
“The concept of good and bad aren’t just subjective and intangible, they’re completely non-existent in the realm of programming quality. Unless such metrics are created, and they themselves are immutable and empirically verifiable, then the best we can do is judge a program based off whether it actually does the tasks it was intended to do.”
This is nonsense. There are many empirical qualities of software such as development time, maintenance time, number of bugs, nature of bugs, features present, real-world problems solved, etc. The problem is that scientific comparison is impossible since software projects are very rarely replicated. Don’t let the small subjective issues over style or incomplete information cloud your judgement. Programming is an extraordinarily creative activity where different approaches can have vastly different tradeoffs, and sometimes certain solutions are just plain bad.
“However, every single time I choose an interface revision that works to publish, there’s someone, bless their soul, who cannot deal with concepts such as, say, “drag and drop”. These people are a strong minority, but to them, I’m a terrible interface designer because it doesn’t work for them as they cannot understand it.”
This is a red herring. A huge part of design is understanding your audience. No interface can be all things to all people. If you are designing an interface for professionals and drag and drop is the most efficient way of accomplishing something then it can be widely accepted as a good interface. You can’t dumb it down to the lowest common denominator and frustrate everyone else. On the other hand, if the majority of your audience has some sort of cognitive (or physical) problem with drag and drop then you would be a bad designer not to accommodate them. It doesn’t matter what one person thinks of your skills as a UI designer. What matters is how efficient your users are with what you’ve designed compared to other potential solutions.
“What’s bothering me is that all these articles speaking of “bad programmers” are being extremely unfair and hypocritical. Much of the code they write, I can guarantee there would be someone out there who looks at it and says, “I would have done this better.” And that is exactly the problem; black and white thinking applied to a gray area.”
Just because someone thinks they could have written something better doesn’t mean they actually could have. Maybe they are missing crucial information, maybe they aren’t as good as they reckon, maybe their beef is more style than substance. For any of those reasons, it may be an unfair judgement against the code. But again, just because a lot of judgements are unfair doesn’t mean they all are.
Also, just because the terminology is black and white doesn’t mean the thinking is. I don’t put code into two boxes like that, and I suspect very few others do.
“We want programmers to write nice code. We want modularity. We want good organization. We want the code to be decoupled. We want to avoid copy and paste. We want everything. What project has time for that?”
Code doesn’t start out bad and then get better by people putting more time into. Sure we cut corners all the time, but that doesn’t mean we have to settle for bad code. The smart thing to do is cut features and keep development under control. If you resign yourself to bad code in order to get something done, you may find yourself spending more time debugging than it would have to do things properly in the beginning. Even worse, the project may fail altogether.
“What we’re talking about are real programmers: people employed at companies, people gaining contracts, people who contribute to open source projects. That’s might haughty of these authors of these articles to tell such people that they’re bad programmers because they do not know certain things that they probably do not even specialize in or use. In summary: does the code work? If so, it’s good as is whoever wrote it. If you need more requirements later and the program needs to be extended to make it work, consider that a separate program then apply the same metric… does it work? Talk of anything else immaterial as it’s a subjective qualitative assessment.”
It seems like you really have a chip on your shoulder about the fairness issue. But look, just because people make unfair judgements doesn’t mean that everything is magically equal. Certainly good programmers can produce bad code because of practical concerns. Good code can become bad over time because there are no resources to refactor. Both good and bad programmers can misjudge code based on poor understanding, pet peeves, or superficial considerations. None of that changes the fact that there are huge qualitative differences in code. These are the differences that make or break projects and companies every day. We can’t gloss over it to prevent people from making unfair judgements or to protect our feelings. We are human, we are fallible, let’s not stick our head in the sand.
August 28th, 2008 at 10:35 am
I do not agree with most all of your responses, but there is something I would like to make clear about the “chip” on my shoulder that you seem to think I have. I came into code I considered bad from a previous developer. I thereby called him a bad programmer. What I’m talking about is more of a self-analysis than a “chip on my shoulder”.