The Reality of Bad Programmers
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.
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
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.
From http://www.humanerr.com/2008/07/04/the-reality-of-bad-programmers/
- Login or register to post comments
- 9826 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Vassil Dichev replied on Wed, 2008/07/09 - 2:57am
I don't like the dichotomy of software made either out of love or for money. And it seems to me the argument for code that works (even though hard to maintain) encourages too much cowboy coding to my taste.
First of all, even the criterium "code that works" is subjective. As you well know, there's no way to reliably and exhaustively prove a code works correctly in all possible cases. Tests help a lot, but can only prove existence of bugs, not lack of bugs. So if you need a metric on what constitutes bad code, how about a more long-term approach: if someone spends more time on debugging and fixing code that doesn't work in the future than is spent on a quick hack now, it's bad code. So I would argue that you don't write modular and decoupled code because you have plenty of time to waste now, but you do it so you don't waste tons of time later.
Roland Carlsson replied on Wed, 2008/07/09 - 5:14am
Success over time is the only messure we have. If the intended public uses the program over a couple of versions it is good code. The most important factor is to actually solve the right problem and not being techically superior according to our subjective thoughts.
So a good programmer solves the right problem that shoud be solved and not trying to fit the problem to our current religon. A good programmer solves the right problem with a tool that are useful for the problem and not the only tool he/she has in the toolbox.
Only history will tell if we are good programmers or not.
Gerd Ziegler replied on Wed, 2008/07/09 - 7:54am
Maybe theres too little tool support for thing like architecture.
I wrote a tool called ztest that allows you to write junit tests for architectures. Means it scans your application and gives you the dependency information. Then define class-sets for say sessionbeans, DTOs, DAOs, services. Then define which can use which. After that run the test against your application and you get your architecture tested. You even can reuse the architecture...
Seems to have the same effect as writing unit tests: to write the test you have to think about your architecture and the dependencies first. This alone is worth it.
Alex Kizub replied on Wed, 2008/07/09 - 8:33am
in response to: gerdziegler
So, you don't believe bad programers exist? Here is example:
... else document.write("Your Browser doesn't JavaScript");
Gerd Ziegler replied on Wed, 2008/07/09 - 8:41am
in response to: akizub
well, its true, not everyone should program.
What I mean, even good programmers can write bad programs when lost in complexity or unstructured code. Here tools can help.
Paul HOule replied on Wed, 2008/07/09 - 8:50am
"Does it work" isn't enough.
There are a few issues here: (i) software has a life cycle in the real world, (ii) requirements change, (iii) there are unstated requirements that contribute to quality.
I've worked with programmers that write code that "works", but is brittle. There are different kinds of brittleness: one of them is in how the code responds to human and machine errors. Another one is how easy it to change the code. We've all seen systems where a simple change can be made in five minutes and deployed with a modest amount of testing because the software is well partitioned. Then there are systems where to do something that seems "simple" requires a complete reworking of data structures and all of the code that manipulates them.
To take an example, a certain consulting firm developed an application that kept track of a customer through a complex set of interactions with an organization. The application worked "well enough" that the client signed off on the project, however, the app didn't work quite 100% right.
It turned out that the status and history of customers was represented in a complex and inconsistent way. Asking a question like "What was the status of person X on date Y" involved an SQL query that went on for several pages and didn't work right in eveyrsingle case.
The customer wasn't so happy with the consulting firm, so the next contract involved both adding some new features and fixing the old parts. Well, it took a lot of effort to redesign the data structures and rebuild the app to use the new data structures. It took weeks of work... And just days to add the new features.
Once this was done, the client was delighted. When the client wanted to make changes to the workflow, this could be done in 15 minutes, rather than weeks.
The firm (for a while) thought the old programmer was a good programmer. After all, he could get projects that "work" out the door quickly. However, over the next year, most of the people in the office spent weeks of time fixing the damage he did -- most of the time this work was unbillable, so the cost to both the firm and the firm's clients was large.
LeonardZheng replied on Wed, 2008/07/09 - 9:35am
in response to: akizub
"Those people *AREN’T PROGRAMMERS*"
If we consider them not programmers, there is no bad programmer.
cfagan replied on Wed, 2008/07/09 - 10:21am
CollinCusce replied on Wed, 2008/07/09 - 2:06pm
in response to: cfagan
HAH! Most valid point yet.
cfagan wins!
I responded to a lot of this on my site http://www.humanerr.com
Thanks for the feedback :-)
From: http://www.humanerr.com/2008/07/09/be-a-better-programmer-series-1-be-a-writer/
mike replied on Thu, 2008/07/10 - 9:43am
I totally agree that the rules for determining a quality developer are subjective, but 'working' is itself subjective. We almost always have implied rules that software should meet. For example, I don't think I've ever seen a requirement that says the software shouldn't erase the user's files. The whole usability issue is very subjective itself. I have used several software packages that work, but are needlessly difficult to use.
But let's apply the 'It works, so it's good' argument to something else: furniture making. It's a table. It stands up. It holds things. So it's good. What if it wobbles? What if none of the joints match really well? What if it can only hold a single glass (even though its the size of a kitchen table)? What if its been finished with finger paint versus something more durable? All of these states produce a working product, and each can be classified as 'good' with some caveats: seemless joints aren't a requirement. Stick a matchbook under one leg and it's fine. It wasn't meant to hold heavy objects. It wasn't meant to last 100 years or be placed outside or look good. But overall, if you show someone a table that wobbles, with huge gaps at the joints, can only hold a glass, and has a finish that is uneven, most people are going to say it's bad. The rules for being a good developer are subjective like many things, but I know some bad developers. Developers that repeatedly DON'T get simple things to work (every table they make is wobbly and because one leg keeps falls off, they have starte giving all their tables 5 legs so one leg is disposable). But hey! It works -- eventually. Developers that take literally months to do something that should take litterally hours. If I build a single table that isn't great, but works, and it takes me 5 years to do so (working full time), am I good furniture maker?
Lastly, I guess I don't understand the idea of saying, "they're not interested in/good at their jobs so they're not really programmers." On one hand, if they're really bad, then they're not much a developer. On the other hand, their business card says developer. They're getting paid for being a developer. They're attempting to do the job of a developer. I'd say that makes them a developer. Plus, I know some developers that are awful and yet, they have a passion for it. They just don't get it.
Being bad is not about making a few bad decisions. It's about a trend of bad decisions.
Faisal Feroz replied on Fri, 2008/07/11 - 5:15am
in response to: monotone
Being bad is not about making a few bad decisions. It's about a trend of bad decisions.
[/quote]
Mike just nailed it. He is absoloutely right, it's not just few bad decisions that make a bad developer, they just dont want to learn thats what make them bad. Apart from these I have seen much worse programmers who wrote code in a special manner that I call JOB SECURITY PROGRAMMING. No one can understand the code except the creator and they make sure that chaging a single thing can break up the whole process with comments like "Don't touch this code it's very complex" placed everywhere in the code. These are not just BAD programmers but you can term them as TOXIC pprogrammers.
Gonzalez Flores replied on Tue, 2008/07/15 - 7:33pm
I like to be a bad programmer, becuz if everything was perfect mi life and my profession ( I love coding) maybe will be so bored.
I'll do my best everyday, and everyday it's nice to have something new to learn, if other people see that i'm a bad programmer and they offer an explanation to me I would be so thankful, becuz they teach me how to be a better programmer, even if they are script kiddies or charlatans,
My metrics are:
Does it work?
Remember we are human i'm happy with that.
Don't bother of what other people says, do what U want!!!!
ciclonpy replied on Wed, 2008/07/16 - 10:55am
A software that "just works" is ok for a web site, rarely maintained or will ONLY be maintained for the creator, but if you are thinking on a large system, possibly maintained for several people or that you know there are many posibilities for it to scale, then you can "just works" just sucks. Good code comes from good informatic documentation, that comes from a well documented business process. If you don't hire a good process expert neither a good system analyst, then I guess your "Just works" criteria should do fine.
Chris Capozzoli replied on Sat, 2008/07/19 - 12:27pm
I think this article has some true points and some false points. I believe it's true that the requirements of some employers are short sighted in that a good programmer could pick up and learn any language and API quickly. On the other hand the metrics for what is good and bad code are simple. The cost of creating software is generally 30 percent of the lifetime costs of running it. If the code isn't maintainable and extendable in a quick fashion the programmer did a poor job. That's even if it works. In over 20 years of coding I've painfully seen it many times in the workplace. The following questions should be asked when evaluating code.
1) Can you read through it quickly to figure out what it does?
2) Does it have any comments anywhere?
3) Can I change this one piece of code without breaking all of it?
4) Is it structured in a way that I can add a small piece of functionality without learning even single line of code?
5) Is it object oriented and broken up into smaller pieces? It's far easier to debug code that has a bunch of smaller subroutines than one big piece of spaghetti.
CollinCusce replied on Sat, 2008/07/19 - 4:42pm
in response to: cc107837
Chris,
I think our experiences differ. I come from a RAD background where most of that does not apply. I think you're correct with larger projects that are to be used over many years and there's funding for revision. Most projects aren't like that, though.
I agree with you on larger projects which will be manacured. I'm developing on a project like that right now, and I have to say it's a different approach. However, I would also contend that most applications are not developed with longevity in mind as they're meant to be quick. A lot of these are web apps and tools which are needed yesterday and started being built today.
Either way, if I could rewrite this post, I would. There's a few points, clarifications, and flat out revisions I would make.
Zoltan Tomory replied on Fri, 2008/07/25 - 10:19am
Worth the rant. I'm an amateur and might be a bit harsher on myself. I don't have much time and between projects may have to find reminders on how to do this or that. Plenty of opportunity for my code to grow. You are right that when you are sprinting towards a deadline, style goes out the door about the time you start praying that it run by any means.
Thanks for the article