5 Excuses Bad Programmers Make
October 16th, 2009
It’s a common problem, there’s a young kid on your team who thinks he is a great architect. He wants to replace the simplest include with a new whizbang inherited menu system or add 3 layers of abstraction to the database access layer, or replace the beautifully crafted error reporting system with exceptions. When quizzing this “architect” he has a reason for every possible change, these are those classic excuses and reason.
- Security. “This will stop any possible security breaches in the future,” he says. Little does he realise that including one extra file into your system isn’t a security risk and probably never will be.
- Performance. “We will do this and this and this, and then cache it all in memory. It will be faster than the existing system,” he says. Sure this might be faster, but the difference between 5ms execution and 8ms execution is irrelevant. Chances of him actually having done the profiling and being able to improve the performance gains are minimal.
- Future proofing. “This will put us in a great position to make changes in the future.” Which changes? You know those unspecified, unrealised and unkown changes that we may or may make sometime in the future.
- Outdated. “There’s a new better way to do that exact thing.” There is a new way to do it, there is a new way to do anything and everything, but is it better? Is it worth holding the project back a week to modernise the codebase? Probably not.
- That’s ugly. “But this code is ugly”, he pleads. Is a 3 line hack better or worse than a leaky abstraction?
I’m sure you know of more, what are they?
Update: This comes across as very bitter. Perhaps “bad programmer” isn’t the right word. Try “inexperienced”. Working on systems, refactoring them and improving them is obviously our job as programmers, yet sometimes you need to take a step back and think. The first design or system we think of is very rarely the right one, it doesn’t matter how much experience you have.
Rem said:
I think it is the responsibility of the senior programmer to share their beliefs with the new member of the team in the most helpful way. Giving way and understanding each other’s wishes might stomp on each other’s egos, but it will allow better collaboration in the long run. Be sure to compliment and respect the inexperienced programmer’s ideas before offering a better, maybe related alternative to his plan. Every programmer, old and new, needs to feel that he can contribute his own part for the team!
schnalle said:
i’ll just say that my boss in company i’m currently working for has the same opinion as you (even though he doesn’t admit it directly to not let people think he’d be: “great idea, but we just don’t have the time to do that it at the moment, we’ll do it later when we got time”. of course, there is never enough time).
this leads to his flagship product being …
* embarassing if the customer saw the code. if i was working for one of our customers and looked at the code i’d strongly advise my boss to not hire this company again.
* code nobody wants to work with. my company has severe problems attracting (competent) coders that stay longer than 6 months.
* buggy and insecure. we never changed our winning code. just added new functionality. removing uglyness, bringing it up to date, future proofing it, securing it? that’d probably introduce bugs, costs time and thus money, right? heavens, everytime i look at the code, my eyes start to bleed.
see, my boss is proud of his baby, and he knows every wrinkle of it. and it works simply works! yes, there may be sql injection problems. cross site scripting. no error reporting. it’s may be slow in certain circumstances. but we can deliver a project in mere days!
really, superb advise. but you forget that maybe, sometimes the new, inexperienced programmers really know something useful the old ones don’t.
like OOP, VCS, bugtracking, refactoring, TDD, MVC, …
Adam Neal said:
Nice list
… also check out this list too:
http://www.i5bala.com/2006/07/10-common-words-uttered-by-programmers.html#planetearth
Jach said:
I’m not even sure if “inexperienced” is the right word. “Job inexperienced” seems better, because you can get programmers who know their stuff but haven’t had a long-term job developing software. “Fresh from academia without a big job experience ” seems even more correct.
In general, great code is produced when academic practices and business-world tried-and-true methods come together in harmony. Academia isn’t useless, but an important lesson the senior programmer should drive in is this: you’re not working on a piece of code due in a week that, depending on if you finish it or not, will only result in some points lost in a class. You’re working on a piece of code due in a week that, if you don’t finish it, will cause you being fired and the company to suffer financially. (Okay maybe not always so harsh but nevertheless.) I think it’s best to say those excuses are valid when you have all the time in the world to work on the software with no real pressure, but that’s not this case. After the product is shipped, then you can start working on optimization and making it pretty.
The only problem with this is highlighted by schnalle’s comment, when your system really is just a giant hack and there can be no refactoring to fix it, only rewriting completely (which of course there’s never time for in a quick-paced business).
jneira said:
I think in others 5 five excuses from faith driven developers o bad programmers
(in the sense of programmers with a long a mediocrity career):
1.- Only trustworthy people can access this server
2.- Never more than two or three users will use the app
3.- Our business requirements changes occasionally
4.- Yes it’s old..i dont know wtf how works but it does!
5.- ugly? i didnt write it, someone copy it from somewhere in internet sometime ago