Geeks With Blogs

Dev.Hell Harrowing the tech business like it's 1999



Hell is other people, and Dev.Hell is no exception.

While I feel secure in saying that most of the unnecessary strife faced by development comes from immature practices and corporate short-sightedness, there are plenty of problems that come from those of us who live down in the code; demons or damned souls both.

Let's start with what developers are not:

Developers are not lazy. Devs love technology, they love code, they love working... because working is playing. When devs become discontent it is not the fault of their tools or their work; its almost always the fault of the environment in which they are toiling... and the personalities they are toiling amongst.

While there is some truth to stereotypes, I think the the iconic sniggering, antisocial nerd is a bit of a myth. There are some, it's true, but the vast minority, and becoming smaller with every new generation of developers (ok, it seems like each successive generation since mine has been smaller than the last, but you take my point). Yes, there are some crazies, but by and large the people I work with are well adjusted, socialized, smart and quite able to function in normal society. Ethnically diverse and very heavily male skewed (a topic for another blog), but basically normal.

The problem is, 'normal' doesn't mean very much. Assholes, lickspittles, heroes and scapegoats are part of the 'normal' spectrum of personality types. The problem is that managing development is difficult enough without having to manage typical human failings.

Herewith, I present the Seven.Deadly.Sins

1. SLOTH
The causes of 90% of development woe are well known. They teach us how to avoid them in every Comp. Sci course, everywhere in the world. There are thousands of books elucidating them with statistics and strategies.... but they persist to this day.

Engineers know that software needs to be designed and documented and tested. They may see themselves as coders, but coding by itself is a vain effort. We need to work smart, not hard: throwing massive amounts of code at a problem until it's been solved is a sucker's game. That is the difference between programming and engineering.

Programming's just logic and syntax. Any old script kiddie can program.

It's just laziness that our industry does not learn from its mistakes. We all know this and it's time we damn well grew up and started acting like it. But why don't we?

Many reasons, I think. Sometimes it comes from management who don't like to see developers do anything other than write code. Some developers don't like drawing pictures. Some don't like sitting in meetings and negotiating a design amongst peers. Sometimes leadership of a team is weak and the architect or lead just doesn't have the authority to impose a design on recalcitrant developers. Some developers are trying to horde knowledge --'job security code'.

Some guys are afraid they'll get the design wrong, and therefore avoid doing it: if you can draw a picture of a system, you can draw a picture of why the system is wrong. If there are no documents then you can't possibly point to a source of failure, right? This is spineless and stupid. It's a hundred times easier to reengineer a flawed design than it is to try to debug unstructured code. Expect designs to evolve, but it's important to pick a design and stick with it until that design has been proven incorrect-- otherwise you end up with neverending refactors that don't advance the system. That's when rewriting from scratch becomes attractive to developers... but never to management.

Catch phrase: "Design document? Well, I just used Microsoft's Document/View model."

2. WRATH
We've all been there. Too many people get involved but nobody has authority. There are committees, layers of management, pictures, minutes, theories, negotiations. Inaccurate analogies or metaphors  are postulated and thrown out in endless succession ("It's like an ant hill", "it's a desktop with a steering wheel", "It's an 8th dimensional quantum construct.") Eventually somebody decides that it's too hard or too expensive. Or a senior manager decides (correctly) that enough time has been wasted, bans all further design meetings and mandates that implementation begin immediately, and by the way, they've cut the schedule and there are no QA resources available.

Then individual developers get angry and decide they're going to design the hell out of it anyway.... only without supervision or planning. Frustrated developers try to compensate for bigger, system-wide design problems by overdesigning less important and reusable parts of the code. The indexing, caching, paging, owner-draw combo box that's been templatized so that it can mimic the entire enterprise architecture on box, only its own metadata as well as MFC type information? The one where it takes five hundred lines of code and fifteen specialized functors  to insert an item? That's overdesign. 

I wrote a suite of classes once--under instruction from the team lead--that had no functional purpose, they were just there to prevent other developers from using a different suite of classes incorrectly. That's right: he mandated that we were to use this unnecessary extra turd-class that I was to write, rather than learning to program the system correctly. I remember the exchange vividly. "Must I really?" I asked. "Yes, absolutely,"  came the reply. "Oh." "Any questions?" "Uh, yeah. Can I use templates?" "Of course." So I went and added a wholly unnecessary template parameter. I guess I have a weird sense of humor.

Catch phrase: "Every idiom used in that function is a well known design pattern!"

3. PRIDE
You know this guy. He knows he's the best there ever was and he has the code to prove it. Yeah? You think you can read my code? You're not smart enough to understand my code. I'm so smart that nobody else can follow my reasoning.

This is often the guy who's read Design Patterns cover to cover, and it shows... because he uses all of them. All the time. All at once. That's not good coding practice, that's diarrhoea.

These are often the coders that managers and non-team-members look at with awe. "He's a genius," they whisper. "I know he's hard to get along with, but he is such an amazing coder."

Wrong on all counts.

4. GLUTTONY
There are developers out there who want a bit of everything. They want to use every design pattern, every language, every tool and 3rd party control without need or discipline.  They have to play with every toy and they can find some reason to justify it... but the ultimate reason is that they want to put it on their resume.

Code reuse is great, but you can't have your cake and eat it, too: you can't use everything third party. Every integration point is a weak point, every new language or library has a learning curve for current or future developers.

Catch Phrase: "We need to redo this with a more modern language."

5. GREED
More commonly a management failing than one that occurs on the floor, but there is still plenty of this going around. Developers who are greedy for undeserved credit. Developers who want their irrelevant hobby-horse project to have the limelight... or worse, devs who expect everybody to drop what they're doing and help out with their irrelevant side projects.

Catch phrase: "If you'd read the whitepaper I'm writing you would understand."

6. LUST
We all want recognition, we all want success. We all want to be able to say "I wrote that, I worked for those guys, I DID THAT." Well, guess what? You have to pick your goals. I once had a small project that I wanted to build out into a big fat distributed enterprise app--just to prove that I could do it. Solo. Boy, was I angry when I was told that the current product was fine for the scale of deployments our customers used and that the company needed me to work on a different product.

I lost a consulting gig for doing this same thing, too: somebody asked me to look at his system and tell him what it would take to get it to market. He wanted to hear how quickly I could take over and finish the code he had, and instead I talked up plans that were much bigger than his ambitions or his budget. Boo hoo hoo.

Catch phrase: "Yes, but with only two more years and ten million additional dollars, you could have so much more!"

7. ENVY
This a one can be pretty subtle among developers. Everyone wants to think they're the best, but the truth is that there's always something new to learn. I've worked with a guy who, when praised, replied to me "I know you think everything I write is bullshit."

I worked with another guy who insisted that his code was perfect and would deny that any bugs or misbehaviour in the apoplication could possibly be his fault without even looking at the problem. In fact, he would go so far as to walk around the office blaming other developers for his mistakes without taking even a moment to investigate the issues. But there's no point denying culpability unless you have the means to hack the version control repository...

When confronted with evidence his code wouldn't work properly, this developer replied "You can't use it like that, it's been specially optimized." Which is fine, but the code was documented as being a generic solution, the 'special optimizations' failed to yield any benefit to performance or code reuse, and the contexts in which it could be safely used were NOT documented (because in fact there were none). This developer also went so far as 'specially optimize' some of my library code so that it no longer worked in the context I had written it for. When shown code that did not suffer the deficiencies of his specially optimized code, he told me that it was badly designed.

Catch Phrase: "This code is perfect."

There you have it. All of the most common developer failings that I have encountered, wrapped up in a cliched--but well understood--metaphor. I'll leave you with this:

Good developers learn from each other. The ask questions. They accept their mistakes. They provide evidence to back up their claims or refute argument. They do not yell, lie, connive, or boast. They do not present their college grades as evidence that their solution is superior to a competing solution.

Thank you and good night.

-- JF

Posted on Monday, July 23, 2007 1:38 PM | Back to top


Comments on this post: Bad.Dev: Seven.Deadly.Sins

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Jason Franks | Powered by: GeeksWithBlogs.net