I’ve been a professional software engineer for close to ten years. Based on my experience, I recently attempted to enumerate the ten worst engineering “traps” most developers seem (for whatever reason) prone to fall into. Here’s the list I came up with. It should be noted that wherever two of these come into conflict, the item close to the top of the list wins.The Ten Worst Engineering Pitfalls
1. The solution is more problematic than the problem it was created to solve.
2. Basing the design on your own motives rather than on users’ needs.
3. Neglecting to handle all possible failure cases gracefully.
4. Failing to protect users’ privacy.
5. Expecting that users will (or should have to) read anything.
6. Expecting that users will (or should have to) possess technical knowledge or jargon.
7. Expecting that users will (or should have to) configure something before using it.
8. Challenging or attempting to guess the user’s intent.
9. Not knowing when to re-architect (either doing it pointlessly, or avoiding it when needed).
10. Failing to make the implementation as maintainable and understandable as possible.
though it’d been a much more enjoyable read if there were some elaboration on each item.
but there’s something missing here… isn’t the software supposed to provide a solution or tool based on some usage model? How is that usage model derived, especially when there are several types of users (think of a word processor)? And if there are features for advanced or specialized users, how do users find out about them?
As for taking care of “all possible failure modes”, that can be a very long list.
Oxymoron.
This reads more like a customer support engineer. Are you really a software engineer that architects and codes software?
depending if you want to make money by selling the software or use the software internally to make money.
You forgot:
11. Expecting that UML will solve everything
11. changing to java/xml half way through the project, as a pr exercise.
12. letting the developers/management come up with the product ideas instead of marketing.
13. outsourcing to india to save $50k (but end up wasting $50k+ fixing problems).
Bad algorithms hidden by good hardware.
Give me a break! It would seem that he expects developers to have the Godlike ability to produce software with Godlike functionality.
It’s not too much to expect the users to have to use their brain in order to use your software! No way will you be able to test all possible failure modes. That assumes that you know what all possible failure modes are.
The only real elaboration you need is how much current operating systems are hard to configure, have awkward abstractions, lack basic security measures, have terrible documentation, often have no documentation, break binary compatibility between relatively minor upgrades, and a lot of other stuff. I have to admit that only in the last months have operating systems started to suck less in any significant way (e.g., Solaris 10 is a big improvement but still has room to improve).
Godlike functionality isn’t needed.
what is needed is more time spent on making the basic functions of the program work, instead of spending time adding new functions when old functions don’t even work the way they are supposed to.
or just plain moron…
ps: is it so freaking hard to have a “reply” link for each post?
Reading sites like OSNews, slashdot and worst of all ACM Queue I feel like every other programming/engineering article I read sounds like someone wrote up a coder’s version of the farmer’s almanac and just riped a page of aphorisms out. I mean jesus you can’t go 3 links on the web without hearing people reveal the wonders of code maintainability as if they just thought of it. The other pratfalls are only slightly less common.
Even worse despite being accepted as the one true programming faith many of these ‘errors’ aren’t always bad. For instance if you are writing open source software you are writing the code because you might use it and you enjoy writing it and thus it is right and proper in many cases (not if you are part of a project that has other objectives) to design what you want to build. Even in other circumstances it isn’t unreasonable that what the engineers wants to make should play a role in what is created.
Assumptions about configurations and manuals are equally defeasible. Sometimes it is best to force a user to configure at the begining rather than allowing him to continue with default settings which might be harmful. There are even cases where it is good to design software to *force* the user to read a manual. Consider pgp and other encryption software that is worse than nothing if people don’t understand the need to keep private keys secret or how to do that.
Ultimately theses aphorisms are mostly useless, and perhaps worse than useless when they garner unthinking obedience, because what we really want is people to write good software/design a good system but this can’t be captured in any simple manner. The problem is that design (of code or other things) is ultimately a process requiring judgement, understanding and intelligent analysis. This can’t be taught by rote and thus these lists serve little point.
One thing to consider is that the computer industry is still like the car industry in the early 20th centry. We still carry around our own mechanics (system administrators, staff programmers), go through dozens of failed designs before getting a decent one, etc. In another 50 years, perhaps then, collectively, people will have learned something, just like we take for granted modern engines in cars (pretty reliable, predictable, well understood, etc.).
One thing that is emerging is the notion of a computing utility, where one day no one has their own system administrator. It’d be sort of like the power company, where you call and they send a tech out if needed. Otherwise, it pretty much works 24/7. That’s still a ways off, but it seems to be on the horizon.
Okay I guess, but a bit subjective.
3. A lot easier said than done! Rule of development #5: Users will inevitably try something you didn’t think of (as those old Sierra games used to say).
4. Not an engineering failure – that’s a policy failure and typically nothing to do with your programming, unless your database gets h4x0r3d in which case it’s really another problem entirely.
5 & 6. Depends. If it’s a technical app: Yes. Users pretty much have to possess some level of technical knowledge to use, say, a CAD app.
Otherwise these are all fairly true admittedly, but generally slightly less technical problems rear their ugly heads; like “product is badly promoted”…
In my experience, the most serious single trap that many developers fall into is:
Thinks technical and forget it is about solving business problem for end users whose primary focus is getting works done with minimal effort.
That’s why I like Mac more than XP, and Linux is not for common Joe.
I’m sorry father, for I’ve sinned. 🙂 I promise that I’ll try to improve. Simplicity (KISS) will be my goal from now on. 🙂
Come on now.. nobody tries to write code that’s ‘more problematic than the problem it was created to solve’. That’s such a throwaway phrase. Why not instead offer constructive advice?
For instance, instead of the fairly useless comment: “4. Failing to protect users’ privacy”, why not describe some common ways that user privacy gets forgotten about and how to stop that happening in the future?
A lot of these are along the lines of ‘don’t assume your users know anything or that they want anything other than what they asked for’. That’s a much more useful tip than #8 for instance. You have a lot of experience, please share it with us lowly students (and others) in a more presentable way!
12.5 Allowing Marketing to do the design
A lot of these are along the lines of ‘don’t assume your users know anything or that they want anything other than what they asked for’.
The problem is that a lot of users don’t know what they want, change their minds, or once you implemented their ideas they decide that the way you proposed to do things in the beginning actually was better.
If you have been carefull in formulating your contract, this results in a lot more money for you, but then there is the problem of making them realize that THEY made the mistake. I learned that it is really important to formulate everything in writing and have really clear specifications and contracts.
Alternatively you could say that many developers have fallen into the trap of making software “just work” then and not being able to maintain it down the line because they didn’t do it properly in the first place.
Note that the article never said it was “about solving business problem for end users”, you could apply the sentiment to a developer doing it for kicks. Admittedly some of the points imply the intended user is somewhat dim, but they weren’t the strongest points of the article.
Comments about Linux not being for common joe have been beaten to death in many another thread, so I’ll leave it alone 🙂
Take a lot at “The Pragmatic Programmer” for example…
There are a lot more important, costly, risky and crucial topics.
Know when its better not to code!
– If you can’t test it properly then you can’t build it.
– Don’t believe the hype/FUD spread about the latest tool(eg The Last One http://c2.com/cgi/wiki?TheLastOne)
– Don’t be afraid to tell the Customer NO as long as you can back up what you are saying by real facts and $$$$ impacts to their requests.
I know the first one is obvious but once you get bitten a few times, it becomes one of the first things to consider in a project.
Designing with management instead of the staff who will use the completed product!
Which is:
“We know the last system was basically a disaster, and we know it now works fine and has finally had all the bugs ironed out of it, but we’re going to re-write the new one from scratch in this uber-cool new technology where we can write everything in a few lines of code.”
It happens all the time, and kills the most well intentioned and well planned projects totally right from the start. It also kills entire companies as well.
where’s the beef?
ps: is it so freaking hard to have a “reply” link for each post?
Yes it is!
It is moronic and leads straight to Slashdot like crappiness in discussions.
Read this for an elaboration:
http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.ht…
= = = = = = = = = = = =
Sort Version:
Q. OK, but can’t you at least have branching? If someone gets off on a tangent, that should be its own branch which you can follow or go back to the main branch.
A. Branching is very logical to a programmer’s mind but it doesn’t correspond to the way conversations take place in the real world. Branched discussions are disjointed to follow and distracting. You know what I find distracting? When I’m trying to do something on my bank’s web site and the site is so slow I can’t remember what I’m doing from one click to the next. That reminds me of a joke. Three old ladies talking. Lady 1: “I’m so forgetful the other day I was on the steps to my apartment with a bag, and I couldn’t remember if I was taking out the trash or going upstairs with the groceries.” Lady 2: “I’m so forgetful I was in my car in the driveway and I couldn’t remember if I was coming home or going to shul.” Lady 3: “Thank God, I still have my memory, clear as a bell, knock on wood. (knock knock knock). Come in, door’s open!” Branching makes discussions get off track, and reading a thread that is branched is discombobulating and unnatural. Better to force people to start a new topic if they want to get off topic. Which reminds me…
Ugh, there’s really no silver bullet technique out there for solving software problems, especially user interfaces. There’s gotta be ugly glue code somewheres. Writing command line programs to perform a task is generally fairly easy, strapping a user interface on the front is something that chews lots more time, especially in coding and design. Making a nice user interface with multi level undo and lots of cross checking, well, it’s a pain and ends up being even more code to test & maintain.
I figure the easiest thing to do is to examine what the users do with the software, or at least try to guess what they might do and make it so they can minimally get *something* to run and happen with the least amount of effort by what’s presented right in front of their faces. Then of course allow them to discover how to access more complex settings and features.
Software developers might be bad testers, I’m not sure. What I find so frustrating about most user apps, especially technical ones, is that they are confusing to sit in front of the first time, throwing tons of tool buttons and jargon at you.
One type of app that makes me want to go postal are ones that throw wizard after wizard at you when started instead of presenting their primary interface right away. Actually come to think of it, I find wizards to be pretty frustrating…
I don’t see the point of criticizing articles or lists like this as being worthless. I can think of quite a few apps that could be improved just by trying to avoid the pitfalls of this short list a bit better.
Software development is a very compliacted process, so trying to summarize some common principles like this makes sense.
Ok, you can rarely if ever make perfect software, but at least you should try to serve your customers as well as possible. In that process lists like this can be helpful.
Anonymous:
WHO CARES !!!
Yeah, I agree, that attitude is the Worst Engineering Pitfall of them all… 😉
Come on now.. nobody tries to write code that’s ‘more problematic than the problem it was created to solve’. That’s such a throwaway phrase. Why not instead offer constructive advice?
You have obviously never worked with my dumbass coworker who’s solutions are often more convoluted, brain-dead, and moronic than the problem they’re trying to solve. This tends to happen when you have a “copy-paste” code-monkey around… gee, that’s exactly what he is…
the worst thing is when you aren’t able to refuse client’s requests. The are so many situations in developer’s life when you should say “go f…k yourself”.
10 user acceptance testing
20 if users not satisfied goto 10
30 release to production
40 prepare next release
50 goto 10
60 it must be a problem with the OS my code is perfect
quite basic really, although it may benefit from SMP optimisations so that some processes can run in parallel.
I think this is more valid than some people believe. As you build several projects in a similar domain, you get to know what works and what doesn’t from a user’s prospective. Having dealt with multiple use case scenarios along with feedback and comments from other user groups, the techies can actually posess more business process knowledge than the business users. I think its a fact business users don’t take advantage of enough.
2. Basing the design on your own motives rather than on users’ needs.
Using the old program as the “spec” for the new one.
Nasty!
Also I would say that you don’t really have to tell a customer “no” – a better way is to provide different options at various price levels – the more troublesome the feature/whatever the higher the cost (either in time or $$$ or both). From my experience customers prefer choosing from a variety of options rather than only one – it gives them a sense of control and it makes you as the developer look more professional/knowledgeable.
I have been writing software for 30+ years. The biggest problems arise when trying to follow a requirement document too closely. You get caught out as soon as the detailed requirement changes, or when you want to offer the product to a second customer.
So you have to step back and think, what is the neatest way of meeting not just this requirement but any reasonably related requirement. Of course you have to meet the requirement or you don’t get paid, but there are ways and ways of meeting requirements.
Re point 3, graceful error handling: the first requirement is to trap the errors, with sanity checks throughout the software in addition to front end UI checks. This way you pick up your bugs sooner.
Who cares about what Joel says; it is annoying that a reply link can simply put in the “RE: <subject>”.
I am not talking about karma, modding, threads, etc – just some freaking usability.
ps: I really don’t care so no need for a huge discussion buried in this already absurb post.
the post replies in http://www.sensibleelection.com avoid the slashdot issue while providing a very clear visual for branching discussions.
Yes, fantastic point. Requirements are just one “perspective” on the software product: there are many others, notably the technical architecture. If you haven’t, I reecommend looking at contemporary software architecture practice and IEEE standards, where software is seen really an agreement between stakeholders, and those stakeholders include requirements, architects, maintainers, technical direction, etc.
If the user is paying for the software. The user’s feature list will be implemented. Say no and say goodbye to future business from that user.
The freesoftware model rules out the $$$ incentive. This is why RTFM is sufficient for questions or support requests. Companies that setup support contracts for their OS will RTFM for you and instruct you on what to do to solve your problem–because you paid them.
To those who say “NO” you have never worked in the software industry, or in an engineering discipline as a developer–maybe as a manager.
No is not needed. You simply tell the user or $$$ funder, this is the current project schedule with estimated delivery date. You then write another project schedule to show the extra time needed to add in the newly requested features. You let the user decide since they have to pay you.
If it’s a fixed pre-paid contract, then this isn’t even a problem since adding more features after the agreement has been signed, violates the contract and a new contract must be drawn up entirely.
Saying No indicates that you are unwilling / unable to meet the user’s need. If you are unwilling or unable to meet a user’s need with software then why did you take the job in the first place? Try hiring qualified developers or outsourcing the portions of the project that you can not complete on your own.
Managers, salespersons and engineers do not know the meaning of the word NO and should never accept it as a final answer—there is always a way, involving more staff, time, or funding to solve a user’s needs (if they are willing to pay for it.)
It helps A LOT to have a bullet list of features with their time to develop, test and package along with their associated costs. This will answer more questions than people realize, yet it is rarely done.
I’m an electrical engineer who has designed much firmware.
One thing that is emerging is the notion of a computing utility, where one day no one has their own system administrator. It’d be sort of like the power company, where you call and they send a tech out if needed.
Yes.
Just what the industry needs.
Some truly original, innovative thinking.
A brand new direction.
Real wave of the future stuff.
…
Now look up Multics.
Damn industry is stuck in some kind of perpetual loop.
“Now look up Multics.”
The difference, now, is complete modern desktops like GNOME through broadband from managed servers, with cell-phone-like payment plans (by month or hour, e.g.). You wouldn’t buy a PC, you’d just have a monitor, a keyboard, a local printer, etc., and a phone number to call for customer support.
Of course, there are the typical privacy issues, but then those exist for every other service industry, too. Banks and hospitals tend to be really good about protecting privacy. All users would have to do is not be stupid and put illegal porn in their account (there’s offshore hosting for those weirdos).
It isn’t for everyone, but it would be perfect for people who just want an Internet connection, office-suite apps, basic games, all with no system administration (plug in and turn on). You would trade flexibility for reliability and ease of use.
software “engineers” are NOT real engineers. all engineers can be held responsible upon the failur of their design or product! not software engineers though.
applying the same law to the so called software engineers will result in 90% of them having to continue their activities from jail;)
“computer scientist” is a better term.
If you actually go out and talk to the users (or the sponsors), then it’s not “Expecting” anymore.
If you’re users expect that they’ll need training, jargon, or configuration, it’s OK. For high-end software (like Oracle) big, complicated pieces of software (ERP, management tools), or verticals, well, training and jargon is a given. The problem (as a developer) is using the correct jargon.
It’s better to set the expectations beforehand than to have the user be surprised.
“Computer Scientist” sounds far too ivory-towerish to me…
Most of the folks I know who do actual production software design, software development, and software production support work are called “programmer/analysts” or some variation thereof.
Writing software is an art or a craft, not a science.
The software might be designed for use by scientists, but coding is not science. Science is where you discover things about the real world by observation and experiment.
The craftsman who makes scientific instruments is not a scientist either.
How about “software writers”?
Sounds like you mean ‘programming’ pitfalls. Apparently you wouldn’t know ‘engineering’ if it bit you. A handful do apply to engineering, but most is programming.
One advice I would give is to put yourself in other people’s shoes. Programming is in its infancy and we just have to live thru it. Opensource is very important for getting us thru this period faster. I’m not talking about cut and paste but about taking some ideas and merging it with yours to develop better software. I had an opportunity to do this and I feel that’s how we are suppose to learn and progress. You know who I think about the most and why I bother to look up opensource? My endusers. What purpose is to write code if it isn’t useful? None what so ever.
http://www.sce.carleton.ca/faculty/ajila/4106-5006/Prospect%20E…
Sure this article is 10 years old, but I think much of it is still relevant today. Some of the points the author makes showing the lack maturity of “software engineering” as a true engineering discipline have changed for the better over the past few years (with communication of knowledge via patterns, wiki, online communities etc…), but I think much of the article is still valid.