Top Five Developer Mistakes of the Week

Real developers are tough and can take criticism in the same way that Superman can take punches. On the flip side, developers can be quick to throw criticisms as well. This week a number of interesting factors were brought to my attention about goofy developer things. The bottom line is simply; there are things developers should do and should not do. If you don't do some basic things, then you are like Superman in a room full of kryptonite. The punches might start to hurt.

I've decided to list the top five mistakes that were brought to my attention this week. I'd be curious to see if you agree that these are issues, or with their rankings. Without further delay, going from five to one, the top five mistakes of the week are:

Fifth: Launching a product based on an arbitrary deadline regardless of whether it is ready.

Nearly every developer has deadlines for products to be completed and released. After all, without deadlines, nothing gets done. What happens, however, as you get close to a deadline and things aren't done? A good developer will make sure the product is at an acceptable level or force the deadline to change. After all, the pain of missing the deadline can often be less than the pain of putting out a bad product. Just ask the folks at Aston Tate and some of the other companies that put out buggy products -- just before they went out of business.

Fourth: Not testing adequately

In general, developers don't like to test. Regardless, when a buggy product is created, it is the developers that take the blame -- and rightly so. Not testing, or doing a quick, random run through, is inexcusable for developers. It is inexcusable because it increases the risk of something being wrong. While it is painful to create test plans and to actually walk through them, the payout is almost always worth the time. There is a reason that Test Driven Development (TDD) is taken seriously by many developers.

Third: Designing user interfaces yourself

In general, developers don't make good designers. This week I looked at red dialog boxes with an information request for the user. Red is a warning color, not one to get a user to click on something for positive informational purpose. I also saw a form created that had black, blue, red, purple, and several other colors on various elements. There were three different colored edges to boxes on the page. It made for a disjointed interface. There was even a pop-up dialog box to indicate a file was saved. The pop-up wasn't the issue, it was the huge word "warning" in the title that didn't make sense. I never knew confirming a file save was something to warn the user about. I always thought it was positive! I could do another blog post on the Top 5 dumb design things done this week!

Second: Blaming the user for things that are wrong, or dropping features because you weren't told not to drop them.

Having a specification or plan to know what a project should accomplish is a key factor to increasing the potential for success. Of course, if you don't have a specification and something doesn't get done, then who do you blame? The user? Of course, it is their fault if they didn't give you the specifics of what they want. Of course, blaming the users could cost you future projects...

Of course, another issue that came up this week involved a product revision. If you do have a specification for changes to a project, then you are avoiding the first half of this point. Of course, equally bad to blaming the user for things that go wrong is choosing to drop features from an application because they aren't listed in the specification. While I believe it is obvious that you shouldn't assume that you can drop features that are not specifically listed in a specification, the same is not true of all developers. After all, if the user didn't say to leave something alone, then it wasn't important enough to keep.... Besides, if you drop it and the user gets upset, just blame them for not being clear about keeping the feature!

First: Don't talk to your users

It might seem crazy, but the sure way to failure --and my top pick for worst mistakes of the week -- is to avoid talking to your users. When something in a project is unclear, it should be obvious that you should communicate with your client to get clarity. Having said that, there are developers who try to figure out issues on their own, or they ask other developers and DBAs on the project. If you want to increase your success, then talk to your users. Most of them don't bite!

# # #

More...