'Here Be Dragons': The Seven Most Vexing Problems In Programming (infoworld.com)

InfoWorld has identified "seven of the gnarliest corners of the programming world," which Slashdot reader snydeq describes as "worthy of large markers reading, 'Here be dragons.'" Some examples:

• Multithreading. "It sounded like a good idea," according to the article, but it just leads to a myriad of thread-managing tools, and "When they don't work, it's pure chaos. The data doesn't make sense. The columns don't add up. Money disappears from accounts with a poof. It's all bits in memory. And good luck trying to pin down any of it..."
• NP-complete problems. "Everyone runs with fear from these problems because they're the perfect example of one of the biggest bogeymen in Silicon Valley: algorithms that won't scale."

The other dangerous corners include closures, security, encryption, and identity management, as well as that moment "when the machine runs out of RAM." What else needs to be on a definitive list of the most dangerous "gotchas" in professional programming?

Comments

2 more I've seen

[NotSoHeavyD3]

1 Not being careful with floats. (Those can totally bite you including using floats when you should have used an int/uint type)

2 Developers who decide to reinvent the wheel because "They know best". (Just dealing with code where somebody decided I don't want to use the built in stuff, I'm going to do my own date time stuff which constantly has issue. Makes you pull your hair out.)

Re:Serious he missed the 2 biggest problems I've h

[geoskd]

Easily the most annoying problem in programming I face is functional requirements not being fully specced out before the project begins

This is one of the most fundamentally misunderstood problems in software design. Probably because it is not really a software problem at all, but a business problem, and the solutions require intelligent business decisions which seem to be beyond everyone.

The solution to the specification problem is not more detailed design specs. The reason is simple. The people writing the detailed spec are not the people using the software, and they are not the people writing the software, so they are in no way competent at providing communications between the two. All of the successful software designs that I have seen are the result of competent programmers becoming involved in the completion of a task that software automation would apply very well to. Those people then subsequently write the software applying their first-hand knowledge of how the software will be used, and what the users needs are.

If you want your software to be very well designed, sit the programmers down to perform the job of the people who will use the software. They need to become proficient at this job, so a 1 week training course aint going to cut it. You need them to spend at least a month doing the job.

If you have the software developers do this, you will get exceptional results without the need for any kind of specification, or other real involvement, because the programmers are naturally very good at optimizing processes, otherwise they wouldn't be good at programming at all. The client gets the features they need, want, and didn't even know they could have. The software design itself is cleaner and faster because the developers have a fully fleshed out idea of what the software needs to do, and can design to meet the need instead of designing to meet a spec that may or may not remotely resemble what is feasible , practical, or correct.