Slashdot Mirror
'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?
1 who's my customer 2 What does he or she actually want.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
1 Not being careful with floats. (Those can totally bite you including using floats when you should have used an int/uint type)
Some developers, when encountering a problem, say "I know, I'll use floating-point numbers!" Now, they have 1.9999999997 problems.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Only if you think you can apply Agile and 2 week sprints to *everything*, including the "thinky parts". What that leads to is incomplete software architecture, and class / data models that do no cater well to all use cases => nasty refactoring. I found that in a lot of software projects I participated in, as well as my own projects... I am a terrible cowboy coder.
However, I've had a few projects that have been very well designed from the get-go, with a thorough design that stands up to chaning requirements. Agile is a perfectly fine approach to develop or extend that kind of software.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Closures are not a ``problem''. Ignorant or incompetent implementations of closures is the problem. ...
Just as ignorant or incompetent implementations of garbage collection and memory management is a problem.
And ignorant or incompetent use of arrays/vectors/buffers and pointer arithmetic and access permissions and
So here is an alternative list:
1. Low-skilled programmers (``script kiddies'') who write profound amounts of buggy code.
2. Low-skilled language ``designers'' who re-introduce the known bugs of the past and introduce new innovative bugs as well.
3. Low-skilled managers who reward high output over high quality, thus ensuring an on-time, under-budget hairball and bugs nest.
4. Low-skilled educators who teach ``coding'' rather than computer science, thus ensuring another generation of the above.
5. Low-skilled professional organizations who reward and encourage incompetent industry leaders to unduly influence the field.
6. Low-skilled investors who reward incompetent technology from dominant, monopolistic companies.
7. Low-skilled consumers who flock to buy flash-in-the-pan shiny stupid gimmicks but won't invest in sound technical innovation unless it's flashy.
This is why C students should never be allowed to graduate w/ a degree. They only go on to further muck up the world. Color me bitter. ;-)
P.S. That `C' above refers to grade level / professional competence, not the language (which should really be named D or D minus minus). *smirk*
Error: NSE - No Signature Error
Well, that's because Agile is not supposed to solve technical issues like architecture or data models. It's supposed to help software development efforts track changes in organizational priorities and incorporate things they learn into their plans as they learn them.
If you rely too much on any methodology it's not going to work.
I have often thought the most important quality a software developer has to have is caring about the people who will be affected by their work. If you're only interested in technology you'll find an excuse to use the latest thing. If you're a prig about methodology you'll end up going through the motions. When you care about your users you'll always find a way to not let them down.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
For a spec to be that good it's got to be written to the same precision as a computer program.
So just write the fucking code.