7 Deadly Sins of Software Development

Frans  blogged about Jon Skeet's which was inspired by Eric's post. Since Eric is asking others to contribute, I'm throwing in my two cents. 

#1  Not understanding the problem that you're trying to solve

Personal guilt rating: historically 7, currently 3

I've seen (and commited) this sin more than just about anything else. It typically goes like this.  You meet with the client/customer/co-worker and they tell you about the problem. As they talk, you get an idea about what they mean and how you want to do it. You promise some really impressive deadline b/c as you understand it, it's a piece of cake.  Then you show them the product and tons of things are wrong. But more than just the number of things wrong, some or all of the things that are wrong are big issues.  You got excited and started coding. And you solved some problem, but not necessarily the problem you were charged with solving.  They tell you "But it needs to do this and it does that." Then you hear a reply "That's because you didn't do X. If you go to this screen and that screen and add this value, it'll work." Then they tell you "Yah, but I don't need to do all of that to get what I want, that's going to take me forever and will make me really unproductive."  Then the developer goes back and starts bitching about how stupid customers are.

#2 Thinking everyone 'else' is stupid

Personal guilt rating: historically 4, currently 3

Don't get me wrong, there is wayyy to low unemployment in this country. There's no way many people should have their jobs. But everyone isn't stupid. All of your co-workers aren't idiots. All the users aren't dumb.  Yes, it's tempting to say "Well, they work for the government so what do you expect" but most of the time, if everyone doesn't 'get it', it's not because everyone is dumb.  This happens quite a bit with user interfaces. You make an atrocious user interface which does all sorts of cool stuff but little that users want, they hate it, say it's unintiutive, and then you go back complaining about how dumb they are and if they had  a clue, they'd love it. Sometimes this is true, but if you find yourself saying this very often, it's probably time for reflection.

#3 Emphasizing other people's shortcomings and ignoring your own.

Personal guilt rating: historically 5, currently 3

Back in grad school, I learned about something Fundamental Attribution Error and it's alive and well.  How many times have you worked with another consulting company on a project where everything they did was 'stupid'? Of course, the stuff you did wrong is just part of the process.  How many architects have you seen who overarchitect something in to the ground, then when it's built and sucks, starts talking about how it wasn't done correctly.  I'm the first to admit that there's a lot of incompetence out there, but if you are harder on other's 'incompetence' than you are on your own, you ought to do some self-reflection

#4 The Design is not the Deliverable

Personal guilt rating: historically 9, currently 3

Well, if you're a sales person or a business analyst it might be. But if you're a developer, remember what clients are paying you for. "I have a 10,000 page Word document with correct UML notation for everything ...."  And you turned a 6 month project into a two year project. After 6 months, you're ready to deliver it but it's not 'perfect'.  So you think "well, everything else is so right, I just need to make these few last changes." That thinking process goes into an endless loop and you lose sight of the fact that, they are paying you for the project, not the documentation (unless of course you're getting paid exclusively for documentation).  The code is what matters. The same thing happens with unit tests. How many times have you seen unit tests that show all green lights yet the code is still buggy? You look into it and you realize that the unit tests may be 'perfect' but they don't test the actual code.  In many cases, the same people that do this seem to be very much against Debug Assertions in their actual code.  Why?  Assertions run in production code and they should compliment unit tests.  They should both be used.  But just like design, it's easy to thing that ___________ is the deliverable - and in the end, it's not.  Granted, perfect documentation and perfect unit tests correlate highly to great software,  but it's not necessarily the case. Rather, a perfect document and a crappy (or expensive / late ) project isn't what the customers wanted.

#5 Making too many assumptions

Personal guilt rating: historically 6, currently 3

How many times have you seen this:  A program is deployed and works perfect on developer's machines.  It goes to a client machine and the setup fails.  The developer goes over to fix it and gets it installed. They user runs it and it breaks again. "Oh, you need to have a C:\Whatever\Documents directory before it will run."  Then they add it and something else breaks. This goes on and on and on. Each time it's probably because of some hard coded assumption that the developer didn't want. Developers make assumptions about how code will be used that the world doesn't know about and shouldn't need to know about. Not using configuration for instance is a common problem.  Hard coding stuff that shouldn't be.  Or, "Oh, well you passed in a null and it can't accept a null." So you reply "Then why isn't it documented and why doens't it throw an argument exception or something?"  You hear "Well, what's the difference if it throws an argument exception or a null reference exception, either way it's an exception."

#6 Thinking you know everything

Personal guilt rating: historically 6, currently 4

You aren't going to learn Remoting in a day. You might be able to make something respond, but you aren't going to learn remoting in a day. You aren't going to learn OOD in a week. You aren't going to learn ADO.NET in a day. As a matter of fact, you aren't going to learn most things without some effort. And just because you made it work doesnt' mean you know it.  Yes, I can copy code from Code Project too - that doesn't mean I know it.  Too many times I've heard people say they 'know' something just b/c they made one project work. One time, I did a presentation on Speech Server emphasizing how easy it is to get some of the things working. One of the participants went home, created a grammar, and decided he knew Speech Server. He went to his boss and pitched the idea that they could Speech Enable their whole order processing system.  Three weeks later the guy emailed me offering me obscene amounts of money to come in and bail him out. Creating a grammar to recoginze a list of names is not hard. I want everyone to use Speech Server. But doing a simple recognition doens't mean you know it.  Creating a Remoting server doesn't mean you know remoting.

As a matter of fact, I'd go so far as to say this... If you can't code the guts of the class without using an external reference, you don't 'know' it. Sure, we all need to look things up and there's nothing wrong with it. But if you can't open a database connection and fire a command without looking up how to do it, you don't know ADO.NET. If you need help writing a call to the database that doesn't use SqlHelper, you don't know ADO.NET.  If you only use code you've copied or other developer's have written, you don't know it.  Knowing it means you understand it, you can explain it, you can troubleshoot it and you don't make a bunch of false assumptions about what's causing a problem.  I'm NOT criticizing looking things up, but before you say you "Know" something, you ought to know it. And you ought to have spent some time learning why it works the way it does and how it works.  If you can answer any question in the world as long as you have MSN Search, it doesn't make you an expert at anything other than searching for other people's answers.  Again, I'm not criticizing this, but if you claim to know something, you ought to be one of the people who's answers you find in MSN Search.

Database normalization is one of my favorites. Everyone 'knows' normalization.  Yet if you ask them about design, many people sure seem to not really know it. optionsScalper has one of the best examples of this that I've come across. He's a genius for many reasons, this is just one of them. Don't claim you 'know' Relational database theory if you don't know the difference between ANY of the normal forms. Don't claim you know database theory if you don't know a single normal form.

What about UML?  How many people 'know' UML?  Then ask them to create a sequence diagram. "Uhh, I don't really know those, I know object modelling."  Ok, draw a Foo that implements bar and inherits from Foobar.  "Uhh, i don't know that." Then you don't know UML. 

Web Services? If you don't know about the proxy class and what purpose it serves, don't tell me you know web services. Yes, I can create one too with the designer - that doesn't mean you 'know' web services. 

Remoting?  Better be able to tell me why you can't remote a SqlConnection object.  Michael says it best though...

I could go on, but you get the idea.

#7 Resting on your laurels

Personal guilt rating: historically 3, currently 7

What have you done LATELY? You might have been the man at C. You might have been the best VB2 coder on earth. That doesn't mean you automatically know more than someone in .NET. Just because someone is younger than you doesn't mean they know less or that they are wrong.  Just b/c you're a MCAD, MVP , MSCE or whatever, doesn't mean your automatically right.  In my case, I've been writing books for most of 2006 and have gotten behind on LINQ for example. I've gotten behind on a few 2.0 topics. I go over to the ADO.NET newsgroup and remember when I could answer just about any question asked. I can still answer a bunch, but not every one.  I got rusty.  Who I was two years ago means squat now. And until I bust my butt getting caught up, I have to accept that. If you don't buy a lot of books, read a lot of technology articles, USE new features, you're going to get behind. This is a fast game and a lot of folks that were big shots in 2001 are nothing now.  Nothing is more sad than seeing someone that can't deal with the fact that they feel from glory. They are bitter. They belittle others. They are condescending and defensive.  That's what happens in some cases.  The same can happen to anyone and if you don't work really hard to do something about it, you can rest assured that it will. People that keep up with the game for a long period of time turn into your Wintellectuals , your Bill Vaughn's and the like - but they didn't get their by resting on their laurels.  they got there by hard work over a long period of time. And if you want to be 'the man', you're going to have to do the same. 

--------

Let me also point out that I think each of these are Sins precisely b/c I've been guilty of them and realize I was wrong.  I probably sound a little sanctimonious at times, but that's only b/c I was as guilty as anyone in many cases and have seen the light. I'm still not totally innocent but I try to keep an eye out for it b/c I know, these can hurt you more than you know.( Just like former smokers are the most ardent anti-smoking zealots, that's pretty much how I'd characterize myself.  One of the main reasons I wrote this up is so that I can keep looking at it and remind myself of how dangerous these can be. )  And by the time you realize you're guilty of them, damage has already started taking place.  I encourage everyone else to add their own list and link back to Eric's original post.   Trackback to this or shoot me an email and I'll publish your list too.