Top Five Developer Mistakes of the Week

[brad jones]

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...

[penagate]

Good post, Brad.

I like your comments about design. When people think of 'design' too often they think only of the graphical and aesthetic aspects of it. In fact when it comes to user interfaces most design work boils down to simply following conventions and standards. All good developers should be able to follow basic design conventions — such using appropriate colours and symbols.

[Nightwalker83]

I agree with points 1 and 3! It is always a good idea to get feedback when you are working on a program, website, etc so you know if you are on the right track depending on what the client needs/wants.

Also, with point 3 I have tried designing interfaces for websites I have coded and they never turn out the way I had pictured them to look. Maybe I am just really bad to the visual design part of things.

[techgnome]

#3 - As a general statement, I agree... that's how we ended up with the menu bar for so many years. How ever, occasionally, you do find a developer who is pretty good with UI design. Generally these are ones who understand the business, understands how the users will use the system, and has some sense of creativity.

#4 - That's where I like to call shennanegans. Yes, the developer SHOULD do some kind of rudimentry functional unit testing. If I pump 2 into a function called Square, I expect to get 4... if I get 6, clearly I fell asleep at the wheel. HOWEVER, even once the developer is done, there really should be some kind of QA Testing and (if possible) User Acceptance Testing (UAT). When it comes to testing, the more the merrier. Personally I think it's a cop out to blame the user for sole testing the code. Besides, even with all of the rigourous testing that could be done... there's one variable that you simply cannot test for. The "Human Factor." In the last 3 months, I have seen some truly creative users out there... stuff that us developers never would have dreamed they would try. And it broke the system. Does that mean we failed in our testing? Nope, rather the system worked as designed. Was the design flawed? That's debatable - it might have been avoidable with #1... but with hundreds of deployable locations.... and no two locations are going to use it exactly the same.... I'm not sure that would have been possible. End users are a creative lot. Maybe we need to add a #6 - Underestimating users. I know I've been quilty of this. It should be recognizable. It usually follows along the lines of "Nah, users wouldn't do that? Why would they want to?"

-tg

[Shaggy Hiker]

I like number one the best. On the other hand, I don't deal with deadlines all that much, or at least not hard ones.

As for the UI design, the points made are not universal. I have some truly gaudy interfaces, but I also have programs that tend to be used outside. For that, you often need very high contrast. For one program, the entire screen flashed red a few times when something happened, but the program was going to be used in an environment of full sun and loud noise. Audible cues were unreliable, messageboxes were unreliable, and the message HAD to get through as work changed as a result of it, and it happened several times an hour.

An interface isn't bad because it is gaudy, it is bad because it is not suited to the task.

[NeedSomeAnswers]

Personally i would say that most of these points could just as easily be put down as Project/Product manager mistakes than developer mistakes.

They are mistakes in the development process, but in many cases a developer will not be responsible for the decisions made over those points, unless they work for a small company and the developer is also the project manager !

For instance at my place of work i have no control of the testing process, we are fortunate enough to have a decent testing team, but even if we did not then there is not much i could do to change how we test it is a management decision.

... and developers certainly don't have control of deadlines anywhere i have worked !!!