One day a developer started at a company and on his first day, while setting up his development environment, pulled out a memory stick. It contained all the old code he had written at previous companies, so he could write code more quickly, he proudly proclaimed.
Aside from the fact that it’s illegal and unethical, it’s also stupid.
Code that is not being actively maintained and refactored degenerates quickly. So instead of his output improving and learning new and better ways of doing things, it actually is getting worse over time.
Short-cut thinking sabotages software projects.
More and more developers are content to write bad code and build crappy software products. We’d like to blame it on the managers and the companies that push us to produce more on shorter schedules.
“I’d love to do automated testing or TDD, but they just don’t give us time to do that.”
Automated testing and TDD are part of coding, not a separate activity. When you deliver a software product, or even just a snippet of code, you’re putting your signature on it that it works. Automated testing and TDD are not optional to the company, they are optional for you.
If you are truly confident that you are shipping quality code without them, then maybe they’re not needed. But don’t push the decision off to the (usually non-technical) manager. He may not explicitly give you time to do “automated testing” but he sure as hell expects the thing to work properly.
“I know this is a hack, but they said we just need to get it working right now, and we can come back to it later.”
If this is the mentality at your company, how many times do you actually get downtime to go refactor and improve your code? Rushing and hacking and crunch-time just begets more rushing and hacking and crunch-time. The more you rush, and skip good design and quality practices, the worse your code will be. You’ll introduce more bugs and more unnecessary complexity. That will delay your schedule even more, resulting in … more crunch-time.
It’s a vicious cycle that we as developers are not only complicit in, but actually cause by producing poor quality code.
“This code isn’t very important so it doesn’t need to have a good design”
What would happen if this code doesn’t work correctly? If the answer is “not much”, they you should probably go work on something else. If the answer is “a whole lot” (it probably is) then do it right.
Writing bad code is viral.
- If you write bad code on certain parts of the codebase, it will become a habit and it’ll start to bleed over into all of your coding.
- It’s the broken window syndrome: if some parts of the code are written poorly, there is less impetus to write better code in the other parts.
- Your code base is the primary training manual for new developers on your team. If they’re learning from crappy code, that’s how they will write code too.
- Letting bad programmers onto your team can actually have a negative productivity impact. More diligent team members will spend time fixing their crappy code, and other programmers will fall into the crappy code slump alongside them.
If the code is important enough to be written, then it’s important enough to be written correctly.
How has the bad code virus spread in your software team? Have you been infected? Got any natural remedies to suggest?
Great post. Thank you. Most of my work is done for a website, on which we release updates often (we aim for weekly). My approach has been, reluctantly and sparingly, to “hack it” just to hit a release date, then create a “fix it ticket” in our bug/task tracking system. Now I know you say “but you’ll just have to go back and re-do it”. While that may be true – sometimes even the dirty hack buys you the time to both hit a deadline and do it right.
For example, a recent hack was that we needed to release an update. The update contained a series of images in a rotator. Each image needed text, rotator-control buttons (prev, next) and call to action buttons layered on top of the background image. Ideally, these would all be separate layers and controlled switched out via jquery. I didn’t have time, so my hack was just some image maps and jquery to show/hide. It allowed us to hit the deadline and get the new call to action buttons up, and bought me a little extra time to go back and do it right. I’ll have spend minimal extra time on the image-map hack, but getting that up there fast (even as a hack) could prove beneficial. Point being, whenever you do reluctantly decide it’s best to hack – create a fix-it ticket immediately.
Yes, Testing is a part of coding. If you couldn’t test it using tools, that means no one can guarantee that the code will work, unless it is really basic like a simple ‘Hello World’.
Automated testing should become an integral part of coding. Agreed.
In Spain, at least the five-six companies I’ve known, the virus is called “stupid project management”.
From the project managers’ point of view, things like “testing” of “code quality” are a waste of time. The only important thing is how much money you can get from the customers, with the less effort. Nevermind if they don’t want to come back again.
Anyway, you, as a customer, may find no alternatives…
Sad but true.
Yeah you sound just like my (non-technical really, but HE thinks he’s so technical) manager. Bump you. I’ve seen people fired, because they were doing a proper job of TDD-ing and properly re-factoring their code, simply because they took twice as long (in the short run) then some bump ass who copy pasted code from all over. But it’s exactly like that ok, it’s not like everyone everywhere lets developers do what ever they want, no pressure, and so its the developers fault if they took the wrong/lazy/crappy approach. Au contraire mon-frere, I can’t remember how any times I took one of those wise ass manger/sales guys whatever, opened yahoo and google search pages, and told then look: you want me to do something like this (yahoo) thinking that’s the way to go, lotsa features , and I’m telling you what most people want is something done properlly, which does the job well and fast (and show the Google page). Still most of them don’t get it, still the best devs are considered those that code the fastest.
So kindly shut the hell up.
Bad code is viral, but bad design is where a lot of bad code comes from.
The first example comes from another web page where there was a discussion about validating parameters, in this case where one class was the only one calling a method, and there were only two valid values, A and B. It was about a year old when I saw it.
There was a lot of discussion on how it was a good (v.s.) bad idea to validate. But the first thing which struck me is the method is in the wrong place – if it is only being called from on class, with few exceptions, the classes maybe should be merged or the method moved. The second is that if there are only 2 valid inputs, it should be a bool so it could NOT have an invalid value. In context, it was not doing an ASSERT().
But here is the problem. Assume you leave it and C is passed in. What do you do? Return a default value? How do you know what would be right? Consider: int div(inta,b){if(b)return a/b;else ???}. Usually the ??? would work if 0 or MAXINT is returned, but you can’t know unless you see what the caller is doing. Throw an exception? Are you really going to test all your exceptions, and try/catch blocks? Now the calling class has to handle the exceptions AND THAT NEEDS TO BE TESTED.
Another nightmarish example (which is part of the sales presentation for a popular automated code checker) has a password that causes a segfault if NULL is passed in. Their solution is to return. I don’t know about you, but I would prefer critical security code to crash instead of possibly letting any invalid value be considered as a good password.
“Patch the crash” is evil. A is the public function, and is passed in a pointer, so check it for null, if B and C are local and are passed an unaltered (const) version of what was passed into A, checking for null again and again only clutters the code. When I read the code I’m trying to resolve a multi-lemma: why the param is const, why it is multiply checked in the local (static) funcions, and why nothing can possibly change it. Sometimes there are other arbitrary rules like 100 lines maximum, so a 300 line perfectly clear program becomes 500 lines across 5 functions with the redundant checks because the code quality metric program shuts up when you create this atrocity.
Good code reads like an elegant mathematical proof. It has an aesthetic quality – beauty. But some proofs are short, some are very long, but each step follows clearly and logically. You can no more use arbitrary metrics than you can judge great music with automation.
When the design in wrong, no amount of refactoring that does not change the design will make up for it. Compensating for a mismatched interface ought not be done – the interface should NEVER be able to pass something invalid or to get into an invalid state.
The hidden premise of the post, that coders know or can discover the purpose of the code they are writing, is mistaken. As a programmer, you can’t really test code if you don’t know where it will be deployed or what it is expected to do, yet this is information programmers usually don’t have.
In one very common scenario, programmer #1 is assigned to add feature A, and at the same time, programmer #2 is assigned to add feature B. Neither programmer is told of the existence of the other feature, or the other programmer. When the two features are added, and they don’t work together, which programmer is responsible? The obvious answer is that this is a management failure. The argument that managers are incompetent and therefore can’t be held responsible for anything goes against all theories of management.
done good job