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.
Cowboy programmers really hate that.
“Common sense is not so common.” — Voltaire
Oh christ if I get one more node.js developer claim that node is multi threaded...
http://michaelsmith.id.au
C'mon. Threads -- I concur wholeheartedly. But closures? Granted, you have to wrap your head around them, but then they are a docile workhorse.
As for threads... don't unless you have to. You add the benefits of concurrence and common address space and multiply their curses.
I'd like to second that #2 problem you mentioned. Easily the most annoying problem in programming I face is functional requirements not being fully specced out before the project begins and discovering well into it that I have to redo a month's worth of work when the requirements exceed the demands of how the code was originally written. In most cases, time is usually given for these changes, but sometime's it's not... and man, are those times infuriating.
File under 'M' for 'Manic ranting'
And it's not that hard. Some people make it hard because they're incompetent. The golden rule of multithreading is: your multithreading set-up has to be very simple. Don't optimize (and for the love of god, unless you really understand cache coherence, don't use atomics), aim for clarity, use mutex locks for shared data, and if you have to use several, make sure you acquire them in the same order. 99.9% of the problems disappear if you follow this simple advice.
What do women want?
But that's the domain of pop music, TV sitcoms and movie rom-coms, and stand up comedy.
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."
3 : It has to be ready 2 weeks ago so we'll forward that untested alpha version to our high risk clients who will sue the fuck out of us if anything is not right. 4: Oh can you make a feature that does X for client A. I'll be here for another hour. 5: assumes input from external program is correct by glancing over the xml of 1 example record. 6: we will make that split between a development version and a stable version when all the features on the list are done. (read in 4 years) We want the new features out as quickly as possible. etc....
1 who's my customer
2 What does he or she actually want.
What you mention are not programming problems.
I am a programmer and I deal with these two issues way more than any problems with multi-threading and NP-completeness. Multi-threading isn't that hard if you have some experience and a good library. NP-Completeness is more of a math problem than a programming problem. For programming, there is no optimal way to do NP-complete, so you just use a heuristic for a "good enough" solution.
Dates, including time zones and daylight savings time. Constant source of bugs.
How about?:
4. Race conditions
Often very hard to spot using static analysis and not guaranteed to show up during testing.
The bane of embedded and command-control systems.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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
Doesn't matter, this is stuff they should have learned in school. Even in high school if they decided to skip college. Even if they go to college I think they just don't bother learning. A computer to many developers is just a magical black box. If the math comes out wrong they switch from float to doubles. If they math is still wrong they complain about the computer (seriously I had professional physicists try to tell me that the VAX was broken because the numbers were coming out wrong). A lot of developers don't even understand integers to be honest, like 2's complement, overflow, fixed point, etc.
Or, even better, put them in the type. This is one thing that makes std::chrono hard to use incorrectly.
Yes, this. the threading comment struck me more as indicative of an amateur in the area than any real flag of a problem area.
if you understand threading, you can work just fine within it, do appropriate things, don't do inappropriate things. You also have to understand the problem you're trying to solve, but again, that comes down to your skills - not any inherent "Dragon-ness" of threading.
I thread the heck out of my software. Works great. Cross-platform, too. Relatively easy stuff - image processing - and really hard stuff, real time signal processing where all manner of stuff is happening concurrently that depends in one way or another on the other stuff that's happening concurrently. I'm not talking about some thread off doing network management, either.
For me, it's strictly a matter of not going in there casually and carelessly. The appropriate planning and thinking - IOW, design first, then write software - pays off every time.
Of course, if you treat threading casually (as with many other things), it immediately becomes a footgun. Well, that's why Darwin gave us multiple feet, sonny. :)
But the whole point is we're supposed to be good at this. You have to pay your dues to get there. Programming Javascript on a web site isn't going to build the required skillsets.
I've fallen off your lawn, and I can't get up.
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
NP-Completeness becomes a programming problem when the people who do the programming cannot spot a NP-problem and then spend countless hours to beat it.
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.
One of the biggest, most vexing problems in computer science is newbies who equate basic programming to the hardest problems of the field.
OK, I realize this is arcane. Let me give an equivalent situation in, let's say, agriculture.
Farmer: "OK, young intern, today we'll learn how to water plants!"
Intern: "Waaaaah! This is as hard as the manipulation of space-time with thought alone!"
Farmer: "...Grab a goddamned watering can, moron."
Reminds me of my last job.
Boss: this isn't what I wanted, did you read the spec?
Me: you gave me a ticket that had 3 sentences in it. That's not a spec.
Boss: that is too a spec. Go back and read it.
Me: this leaves a ton open to interpretation. This isn't a spec. You need to clarify this with a lot more detail.
Boss: come on, you knew what I meant.
And that's partially why I quit.
So you didn't ask your boss what he actually wanted before you started coding? You didn't ask for clarification for each ambiguity you discovered during coding? You just shat something out at random?
Socialism: a lie told by totalitarians and believed by fools.
I agree. These problems are something my architect brother spoke about. His way to deal with it was to listen to what the customer asked for and then come back with three options for them.
The first is give them EXACTLY what they asked for. If they wanted a staircase to nowhere and a conversation pit in the garage then that's what they'd get. The second option is to offer them what he thinks they really wanted. Some people just don't know what they want but with experience my brother could get an idea of what people liked and needed. The third option is he'd give them what he wanted to make. He'd take their input but then come up with something he'd find interesting or would like to see experimented with. He said few people would take his first option.
I've also seen this in healthcare. People complain about how hospitals and their staff do things among other complaints on how they are treated. I can trace many of these complaints to a single cause, they are not the customer. The insurance company is paying the bills and so they are the real customer, and many of those in healthcare know this. This then creates a problem because the patients will not complain to the insurance company because they don't realize that their "customer" is not the hospital, but the insurance company. This is why I fear government healthcare, it adds another layer in this chain with one of them being the people that brought us the DMV and the poor customer experience we've all come to know from it.
That's not exactly where I intended to go with this but it is where I happened to end up. As a "customer" of government healthcare through the VA I can tell you that is not where you want to be. I will say that VA care has improved but it only took people dying of negligence and suicides for a enough US Senators to notice and care enough to act.
I am armed because I am free. I am free because I am armed.
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.