May 6, 2005
I was chatting on the phone with a friend of mine a few days ago, and he described a project he recently inherited. It was the work of a half-dozen different developers, who each built their parts of the project in a completely different way with little to no communication between any of them. The code tells the story: you'll find the rank amateur; the pattern-a-holic; the global variable guy.
It's a shame that software developers can't get the kind of basic guidance or training they need to prevent these easily avoided disasters. That's why The Daily WTF is more depressing than funny to me – we see the same classic mistakes day after day. That's the norm! Steve McConnell, in Rapid Development, elaborates:
When I was in seventh grade, my art teacher stressed that any student who followed his instructions would get at least a B; no artistic talent required. He was a 220 pound ex-Marine, and considering he drove that advice home at least once a week, I was amazed at how many 98-pound seventh graders didn't follow his instructions and didn't get at least a B. Judging from their work, it wasn't because they were tormented by glorious, conflicting artistic visions, either. They just felt like doing something different.
As an adult, I often see software projects that fail merely because the developers and managers who work on them don't follow the instructions – the software-development fundamentals described in this chapter. It's true that you can develop software without mastering the fundamentals – sometimes even rapidly. But judging from most people's results, if you don't master the fundamentals first, you'll lack the project control needed to develop rapidly. You won't even know whether you're succeeding or failing until late in the project.
Indeed, simply knowing the fundamentals is a critical differentiator between hobby programmers and so-called professional programmers. And it's not even that complicated. Steve likens it to following the instructions on the paint can:
Suppose you're starting a painting project, and you read the following instructions on the paint can:
- Prepare the surface: strip it down to the wood or metal; sand it smooth; remove residue with a solvent.
- Prime the surface using an appropriate primer.
- After the surface is completely dry (at least 6 hours), apply one thin coat. The air temperature must be between 55 and 80 degrees Fahrenheit. Let dry for 2 hours.
- Apply a second thin coat and let dry for 24 hours before using.
What happens if you don't follow the instructions? If you're painting a doghouse on a hot Tuesday night after work, you might only have 2 hours to do the job, and Fido needs a place to sleep that night. You don't have time to follow the instructions. You might decide that you can skip steps 1 through 3 and apply a thick coat rather than a thin one in step 4. If the weather's right and Fido's house is made of wood and isn't too dirty, your approach will probably work fine.
Over the next few months the paint might crack from being too thick or it might flake off from the metal surfaces of the nails where you didn't prime them, and you might have to repaint it again next year, but it really doesn't matter.
What if, instead of a doghouse, you're painting a Boeing 747? In that case, you had better follow the instructions to the letter. If you don't strip off the previous coat, you'll incur significant fuel efficiency and safety penalties: a coat of paint on a 747 weighs 400 to 800 pounds. If you don't prepare the surface adequately, wind and rain attacking the paint at 600 miles per hour will take their toll much quicker than a gentle wind and rain will on Fido's doghouse.
What if you're painting something between a doghouse and a 747, say a house? In that case, the penalty for doing a bad job is less severe than for a 747, but a lot more severe than for a doghouse. You don't want to have to repaint a whole house every 2 years, and therefore you hold the results to a higher standard than you do with a doghouse.
Most of the software projects that have schedule problems are house-sized projects or larger, and those projects are the primary concern of this book. On such projects, the development fundmentals save time. Far from being as rigid as the steps on a paint can, if you know enough about them, they also provide all the flexibility anyone ever needs. Ignore the instructions if you wish, but do so at your peril.
I'm sorry you got stuck with the doghouse, Josh. Here's hoping we can educate the next batch of developers so the next guy after you has better luck.
Posted by Jeff Atwood
The problem with software is that you build a doghouse and someone else sticks it on their 747. It could even be over-engineered for the intended purpose, but someone can always find an unintended use where it will truly suck.
You know while you're working on fixing code like this you have to chuckle every once in a while or you'll start crying lol. It's amazing how many truly bad developers there are that still have jobs. Developers out there who don't bother to read the "directions" e.g. "doing their homework first". I'm not talking about dataset vs custom objects, just the CS 101 kind of work. Imagine a plumber who builds leaky pipes and customers keep calling him back year after year for more work. Wouldn't happen but it does in the sofware world.
Please note though I didn't mention inexperienced - we were all their once and we're all inexperienced at some level. I was working on some visual studio integration last night and I was feeling very humbled!
But in the industry's continual (and mostly ineffectual) effort to clean itself up with hundreds of versions of directions on how to build an application we still need to keep a couple morons around so I can stay employed :)
Being honest here...how does a bad programmer know they're writing bad code. It's like a person with no fashion sense. Do they know or care...they just know they have clothes on so it should be acceptable. Same with programming...it worked...so it should be good.
I know I write my share of bad code. Sure, I write it off as crunched development time sometimes...but I try my best to not rush things. You have a certain set of base rules and a template you generally work from to help guide you along.
Do I have fashion sense? I'm not sure until someone else evaluates my code. Most of the code I write, I end up maintaining. Others that have had to maintain it have not mentioned to me that it was difficult to understand or "poorly coded"...so I think I'm safe.
Where do you learn to write good code? I read Jeff's blog. :P Read others that I *believe* are smarter than me and know their stuff (Scott Mitchell, etc.). Follow Microsoft's Best Practices. I just don't know...but you do the best you can with what you have...you and your knowledge. Does anyone you know really have *professional* training to be a developer?
I think you hit the nail on the head when you said you "know" when you right bad code but obviously the term "bad code" is very subjective to say the least. What I feel is bad code to me might be perfectly exceptable to other developers. It's hard to draw the line between inexcusable bad code and plain old inexperience. Often times it's a combination of the two whether you're just starting or have 10 years in the field. You can't be an expert at everything and everyone is going to make mistakes.
But when you're talking about a bad developer in my mind they have certain traits that almost always lead to bad code:
1) don't do their homework. You know these developers, they don't read any books, or read about best practices, or visit Jeff's blog :) , They just plain don't practices their skills and their just there to collect their pay and do minimal work as possible (ok minimal work isn't always a bad thing lol :) )
2) Don't learn from their mistakes nor work to improve themselves. These are the people who run into the same glass door day in and day out and can't figure out why their nose is always sore.
3) No passion. seriously this is a big one for me. I hate working with other developers who don't LOVE what they do. Whether your a developer or a plumber if you love what you do you're going to be better at it.
I'm sure there are quite a few more I could list out but I guess the point is a bad developer will consistently produce bad code. I know that sounds really obvious but seriously think about the jobs you've had and think about that coworker that everyone has that has been at the company for years yet produces consistently bad code but nobody calls him a "bad developer".
So all in all you're always going to see bad code for whatever reason it may be but it's the bad developers that frustrate the hell out of me. As much as it makes my life harder I can probably deal with the rank amateur and the pattern-a-holic guys but the global guy is the one who gets under my skin because he knows there is a better way but he's too lazy to do it or doesn't care to find a better way to do it.
In short do your homework and have a passion for what you do and you'll always be payed well and respected for your work :)
I am often put in the following situation:
Someone comes to me with dried paint roughly in the shape of a doghouse, they want me to fill in the doghouse underneath, but they want me to change the color of the paint, and, to be perfectly honest, what they really want is a 5 bedroom house for their family and they figure that since the doghouse is roughly the same shape as a person-house it should be easy to just make the doghouse-paint bigger right?
I'd LOVE to be able to just follow instructions for once.
Very interesting blog to say the least, interior painting can be a pain if you don't approach it properly. Following the instructions on the can can really mess thing up, check out my blog for some real instructions at http://nielsenpaintingcontractor.com/interior-painting-lesson-1/. I'm still a little confused on how programming and interior painting relate.