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.
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.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
As far as I know, there are four hard problems in programming:
1. caching
2. naming (i.e. how do I name that variable/method/class)
3. off-by-one errors
Haha, you should be more Agile! It's not Agile to find out what your customers need first. Just throw a bunch of shit at the wall, make it flatter, and dump it into production to let your customers do your testing and chip away at the things they complain about.
They'll definitely give you useful feedback and not switch to another software product instead. If there's one thing that's always been true about customers, it's that they're fiercely loyal to their software vendors.
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
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.
I wish I had a good sig, but all the good ones are copyrighted
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.
Dammit, 30 seconds after posting that I realized it was even better as... I got .99999999 problems, and a float ain't one......
HA! I just wasted some of your bandwidth with a frivolous sig!
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.