'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

Serious he missed the 2 biggest problems I've had

[NotSoHeavyD3]

1 who's my customer 2 What does he or she actually want.

node

[MichaelSmith]

Oh christ if I get one more node.js developer claim that node is multi threaded...

Re:node

[Assmasher]

How about people throwing 16-core AWS instances at Reddis? ;)

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:2 more I've seen

[LinuxIsGarbage]

You should have modified the code to take those fractions of cents, and deposit them in your account.

Re:2 more I've seen

[ATMAvatar]

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.

Re:2 more I've seen

[Darinbob]

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.

Re:2 more I've seen

[lgw]

Freaking slashcode:

The problem is, people will write if (x * 3 < 1) ... then be mystified when it fails. My favorite is all the if (x < 0) ... bugs, failing to realize that negative zero is less than zero. Great fun.

Then there are the NaN-related bugs, which are the sort of math errors most people overlook - like dividing X and Y by N, which accidentally is 0, then later comparing them and discovering that they're equal.

Re: 2 more I've seen

[Mike Sheen]

Also Superman III, which was a decade or more earlier. I don't recommend watching Superman III, however... but Office Space should be mandatory viewing.

Re:2 more I've seen

[lenski]

Scaled floating point, unless you're working with an IBM Z series (does Power8 have decimal float?).

Every modern processor has fast floating point; a double can store and express 53 significant bits, so express the floats in pennies. Or if not in USA, the smallest denomination in the money system you use. Server class machines probably do long doubles.

("Every" includes all Raspberry Pi models, the Odroids, Banana PIs, Orange Pis, etc.; essentially every X86 since 1991, Every Power since about 2003 and all ARM since Cortex-A.) I haven't kept up with MIPS. Even the microcontroller world has single-precision floating point hardware in wide deployment: We use Kinetis parts (ST's parts have Cortex-M4F too), so easy 32-bit ints and floats is the order of the day. A reasonably structured interrupt service function (no assembly required, BTW) executes to completion in 1 microsec... It has truly changed the nature of our deeply embedded work.

The result: Use a commonly available toolkit competently.

Closures?

[Anonymous Coward]

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.

Re:Closures?

[K. S. Kyosuke]

Not only that; closures are not a problem but actually the ultimate solution to the actual problem of name scoping. Lots of approaches were tried before closures remained as the only sane idea.

Re:Closures?

[lgw]

C'mon. Threads -- I concur wholeheartedly

I've never understood why programmers have problems with threads. Almost everything is one of two models:
* Solve the problem as a series of queues with worker thread pools. Really hard to mess that up.
* Entire request-to-response workflow in a thread for each request. You have to be a bit careful about locking around shared objects, but usually the answer is avoiding shared objects.

If you can't get multiple threads on one machine right, how are you going to work on distributed systems?

Re:Closures?

[hey!]

I think the problem is the paradigm shift from object oriented to functional. I learned to program in Scheme many, many years ago (early 80s), although I never used it professionally. When javascript came along, people looked at the bizarre object system and thought "This is dumbed down Java." I looked at it and thought, "This is kind of like Scheme."

Buffers

[Harold Halloway]

Buffers seems to cause a lot problems, particular when they overflow. As a non-programmer (well, a very long time ago programmer) I've never grasped why preventing overflows seems to be so difficult.

Re:Buffers

[MichaelSmith]

Saw this in C:

some_func(char *data) {
        char *buffer;
        buffer = malloc(200);
        memcpy(buffer, data, 2000);
        send_buffer(buffer);
        free(buffer);
}

Occasionally it would cause a crash.

Re:Buffers

[Cassini2]

Microsoft wrote a bunch of code, that in hindsight was a really really bad idea. I'm not really sure that the problems were all Microsoft's fault - they probably didn't invent them. They are Microsoft's fault in that they embedded the concepts into the operating system and then widely popularized them.

The big gotchas all have to do with limitations of C, and the twists used to optimize Microsoft's programming for the 8086 architecture. I'm thinking of:

char string[MAX_PATH];
What can possibly go wrong? Especially before MAX_PATH was invented.

malloc() new() and friends
For any non-trivial program, it's almost impossible to get correct. They only really work for something like a C compiler which will allocate a variable amount of memory, do a task, and then end. If you miss a few free() calls along the way - they will be cleaned up when the compiler terminates.

GlobalAlloc(), LocalAlloc() and friends
Just in case you couldn't make it work with malloc, try the operating system version of the call. Using OS calls really opened the window to some famous bugs - OpenSSH comes to mind.

Multi-threading in C
For any non-trivial problem - it doesn't work. Firstly, for any non-simple piece of code, it is tough to do correctly. Secondly, for a trivial piece of code, like a save operation, you need to somehow make the memory being stored immutable for the duration of the save. For most save operations, this defeats the purpose, as the first thing the user wants to do after save is to change the document. Thirdly, if you really need multi-threading, there is a good chance some of your users need parallel-processing across machines. Multi-threaded code and parallel-processing code are not the same things at all.

Embedding code in data.
Firstly, the x86 architecture encouraged this, by not having proper page protections. Secondly, it completely opens the system up to malicious code. ActiveX, JPEG libraries, font libraries, everywhere Microsoft had an API that embedded code in data, it was all exploited.

Re:Buffers

[AmiMoJo]

Buffer overflows are often the result of not checking the data that is going into the buffer carefully enough, or at all. The spec says the string is max 80 characters, so someone sends 80 characters and some exploit code which runs over the end of the buffer.

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

[mark-t]

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.

Four hard problems in programming:

[rastos1]

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

Re:Four hard problems in programming:

[mbone]

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

Or, as old Fortran programmers would put it, insisting that the first item in a list have an index of 0.

Re:Four hard problems in programming:

[AmiMoJo]

The best but if advice I've ever had for variable naming is to put the units in the name. If you are handling values in millimetres, use a _mm suffix. For area use _mm2. For graphics use _px for pixels etc.

I've seen so many programmers get hopelessly confused because they can't remember what units they have when doing maths or trying to render data on screen. On some systems pointers can use byte or word addressing too.

Re:Four hard problems in programming:

[vtcodger]

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.

Re:Four hard problems in programming:

[Xrikcus]

Or, even better, put them in the type. This is one thing that makes std::chrono hard to use incorrectly.

Re:Four hard problems in programming:

[Plus1Entropy]

Agreed that race conditions can be very tricky to spot. But there is one case I've run into a couple of times...

If you're trying to debug something and you start putting in some print statements or breakpoints, and suddenly the bug goes away... It's probably a race condition, which was inadvertently "fixed" by you slowing down the execution with your breakpoints, etc. I like to think of it as the CS equivalent of the Observer Effect.

Re:Four hard problems in programming:

[Sique]

Off-by-one errors are not solved by having the first item in a list indexed by 1. You still have the mathematical feature that all natural numbers have an ordinality and a cardinality. If you insist, that the ordinality of a number equals the cardinality, you have to start with 0 as the first index.

(For people not much into set theory: The cardinality is the answer to "how many elements are in a given set?", and the ordinality answers "how many predecessors does the number have?")

Re:Four hard problems in programming:

[serviscope_minor]

The best but if advice I've ever had for variable naming is to put the units in the name. If you are handling values in millimetres, use a _mm suffix. For area use _mm2. For graphics use _px for pixels etc.

That works and has generally been my go-to method.

An interesting alternative is where the units are part of the type, and I've been getting to the C++ std::chrono library which makes heavy use of it. It's actually rather nice. It models durations and time points as separate concepts, but not only that, it models durations as a type family. So, you can do this:

auto delay = 10ms;
auto next_timeout = system_clock::now() + delay;

which is guaranteed to be correct and not lose precision no matter if you port it to a system with a different system clock tick rate. The thing is the underlying units actually don't matter. At the time you want something more concrete, e.g. the timeout for a select() call, you can convert to a specific time base (e.g miliseconds) and get the number of ticks.

Multithreading is a solved problem

[melted]

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.

Re:Multithreading is a solved problem

[K. S. Kyosuke]

The most important thing is that you shouldn't even be exposed to these primitives in application programming. You just shouldn't. Likewise, the collective amnesia that makes programming people forget useful concepts invented in the past such as pseudo-time doesn't help any. (I'm pretty sure someone will reinvent that one in near future, with great fanfare!)

Re:Multithreading is a solved problem

[buddyglass]

I'm not willing to chalk it up to a lack of education. Concurrency is legitimately more difficult than straightforward single-threaded code. Some developers can handle it; some can't.

Naming

[Lisandro]

Seriously, i spend more time thinking on this than anything else lately.

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

[Anonymous Coward]

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.

Everyone runs with fear from NP problems

[NFN_NLN]

> 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."

Customer: Why is this problem not scaling?
Programmer: It is NP-hard we are basically just brute forcing it.
Customer: If you can't solve this "NP-hard" problem, then I'll just find someone who will.
Programmer: Sure, let me know when that happens.

Re:Everyone runs with fear from NP problems

[bheerssen]

> 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."

> Customer: Why is this problem not scaling?
> Programmer: It is NP-hard we are basically just brute forcing it.
> Customer: If you can't solve this "NP-hard" problem, then I'll just find someone who will.
> Programmer: Sure, let me know when that happens.

Customer: GTFO&DIAF
Programmer: Well, shit.

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

[zwarte piet]

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....

Re:arrogance is tops

[ATMAvatar]

That is part of the Dunning-Kruger effect, exacerbated by the software industry's propensity to follow a Logan's Run-like purging of more experienced developers.

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

[ChrisBrooking]

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

Arbitrary truncation of data...

Re:It's probably because you suck at it

[MichaelSmith]

Wow. The script kiddies where I work are doing all their backend programming in coffescript, running in js interpreters. Every branch and loop they write creates a new callback (which they call threads) so there is no way to predict which order they run in. Half the applications are tricks to put order of execution back into a meaningful sequence and avoid race conditions.

NP is the new P

[ziggystarsky]

Modern SAT solvers are able to solve SAT problems with millions of variables in seconds. Yes, there are hard problems with some hundred variables that are too hard to solve. But as it turned out, most useful problems are easy to solve. So if you have an NP-complete problem, you should just try to put it into minisat. If it can't be solved easily, there's still time left to despair.

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

[ShanghaiBill]

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

[buddyglass]

Dates, including time zones and daylight savings time. Constant source of bugs.

Re:dates

[lgw]

Dates, including time zones and daylight savings time. Constant source of bugs.

The only safe way to deal with dates/times is to use a 64-bit int for milliseconds (UTC - always UTC). No time zone nonsense, not DST issues, safe to subtract to get a duration, easy to add a duration to, always the right answer.

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

[JaredOfEuropa]

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.

Ignorance abounds

[IHTFISP]

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*

Definitely nah

[fyngyrz]

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.

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

[Anonymous Coward]

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.

Yeah. Was:Definitely nah

[DRichardHipp]

> if you understand threading, you can work just fine within it

If you understand pointers and malloc(), you can work just fine within them too. But that hasn't stopped people from disparaging them relentlessly and trying to come up with new "safe" languages that don't have pointers and memory allocation.

Added irony: With pointer and memory allocation bugs, the problems are at least reproducible. Can't say that about threading bugs.

still cannot figure out why the Java developers thought they needed to do away with pointers and (application-controlled) memory allocation, but then turned around and encouraged the use of threads. It's kind of like saying to children: "Don't play with those scissors, you might cut yourself. Use the power saw instead!"

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

[gtall]

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.

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

[Dunbal]

It's not arbitrary it's becau

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

[Hognoxious]

Put everything in one huge massive universal class of doom. Kiss refactoring goodbye!

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

[Kjella]

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.

To be honest, it's often the programmers who hear "optimally solve it" when the requirements actually are "sufficiently solve it". For example I just suggested for a knapsack problem at work we use a simple overflow algorithm instead. It doesn't matter that we're not perfectly sizing the chunks as long as they're below the max size, it's like a 10-20% deficiency on a 50-fold improvement. Sure with infinite time and resources we might have done it perfectly, but really it's just a workaround for limitations in another imperfect system. And particularly when it comes to any human scheduling, were it often turns out that there are some unsaid requirements which means they'll look at a time table and say this won't really work anyway.

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.

Re:Yeah. Was:Definitely nah

[Fruit]

Added irony: With pointer and memory allocation bugs, the problems are at least reproducible. Can't say that about threading bugs.

Sounds like you never had to debug a use-after-free bug.

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

[Anonymous Coward]

I was taught, for a spec to be good, you could give it to two different developers and get the exact same result. Otherwise, you need to improve the spec.

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

[hey!]

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.

"closures"? Are you F'ing kidding me?

[engineerErrant]

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."

ARRRRGHH!

[TiggertheMad]

Dammit, 30 seconds after posting that I realized it was even better as... I got .99999999 problems, and a float ain't one......

Re:arrogance is tops

[Cassini2]

A related problem is that there is no way for the hiring manager to tell the difference between a very good programmer and a good programmer. All of the first year CS resumes say the candidates are skilled in C, Java, and a few more buzzwords. Every software project has a life-cycle, and the better programmers move between projects. This means all the experienced resumes show people with many projects. This makes it hard to tell the difference between a competent person that makes meaningful contributions then moves on, and a less competent person that is a good talker and drifts.

It's a real problem for the hiring manager. It essentially means that you can't pay more for better programmers. Economists even have terms for this. Product differentiation. If you can't show you are an A+ programmer as opposed to an A programmer or a C programmer, then it becomes difficult to make the case that the A+ programmer is worth four C programmers. It even becomes difficult to tell who the A+ programmers are. This tends to drive out experienced programmers into other careers.

This problem really affects software engineers. I can tell the difference between a skilled electrician and an unskilled electrician in minutes. Great architects win awards. Develop a great piece of real-time engineering on a safety-critical system - no one is ever going to see your work. Sure, you might save lots of lives with your code. But the hiring manager for your next job can't tell the difference.

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

[lgw]

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?

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

[blindseer]

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.

1&2&3&4&5&6&7&8&9&

[I'm New Around Here]

The title of this message is originally "1&2&3&4&5&6&7&8&9&0&1&2&3&4&5&6&7&8&9&0&1&2&3&4&5&".

I can't type another character into the title box.

It all shows when I hit Preview, but I won't know if it makes it until I hit Submit.

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

[Dog-Cow]

I've worked with lots of people like that boss. If you try and get more detail, you're chided for not working quickly enough, or for bothering them. My policy is always to give such people what they ask for. If they can't or won't learn, that's not my problem. Their spouse/parents/pet can change them. It's not my job.

dumb stuff

[Spazmania]

Ooh, dragons.

1. Multithreading. In some languages (e.g. Java) multithreading is no worse than any kind of parallel processing. Can you be a buffoon and fail? Yes you can. But you can do that in a single-threaded program too.

In other languages (e.g. C) the chance of errors impacting some completely random data structure are so high that it's frankly important to stay away from anything that would confuse the control flow, such as multithreading.

2. Closures. Okay, you're talking about Javascript here. javascript is a hideous language which should not be used to the maximum extent practical. Why complain about closers when all of javascript is bad mojo?

3. Too big data. Also known as lazy-ass programmers who don't want to be bothered to deal with the possibility that their program may be called upon to process a large data set. Solutions for processing large data sets explicitly on the disk (not with virtual memory) are well understood. You just have to choose to use them.

4. NP-complete. There's no particular dragon there... the elephant in the room is those programmers too ignorant or clueless to bother computing the big-oh running time of their algorithms, so they write software that appears to "lock up" as soon as anyone gives it a useful data set to process.

5. Security. Correct security implements defense in depth. Break one level so what? Even patched slowly, it's patched before enough layers can be broken to grant access.

Programmers make two classes of stupid mistake:
a. They assume they don't need defense in depth because they've written secure software.
b. They carelessly implement functionality that cuts through all layers of security. Like single-sign on.

6. Encryption. The odds of a long-surviving conspiracy to hide mathematical breakthroughs which bypass encryption are essentially zero. You can relax on that score. You can also expect one-time-pad encryption to remain unbreakable regardless of mathematical improvements. Because no analysis of extremely long strings of random bits is meaningful.

You have to be pretty bone-headed to mess up security in this day and age. Yes, many many programmers are bone-headed. But that's not encryption's fault.

7. Identity management. The only thing which makes this hard is its constant misuse. No authentication is perfect, so correct programming makes authenticated actions reversible instead. The more critical the action, the more critical it be reversible.

8. Measuring hardness. Now we're in to mumbo-jumbo territory. A simple big-oh evaluation will tell you whether your algorithm is usable. Trying to figure out whether it will be easier or harder to solve one problem or another, neither of which have a known useful algorithm? Silliness! Problems like that are solved when someone finally has the key insight. Inspiration is not a product of work, it's a product of the creative mind.

9. The authors can't measure. They claimed 7 but listed 8 things.

Code on code violence

[Anonymous Coward]

They missed the most vexing problem of all. Hiring a skilled and talented old timer programmer to come solve the problems that fresh faced recruit coders created. Then offering the same rate as they paid the fresh faced recruits, not being able to grasp that the ability to solve, often under tightest of all deadlines, messes left by inexperienced programmers. In some cases less! I have personally had the extreme joy to explain to a physicist that the code he wrote, while it would solve his problem, was written in a manner that the solution was of order O n squared. While the problem could be solved in an manner that mathematically provided the same solution but was order O n. The physicist then said he wanted to test both solutions. His was actually faster on a data set of 100 items. (Lots of fixed constant cost was involved, my solution had more precalculation setup, so for small sets of data, my overhead was more) He proclaimed himself the winner deriding my science. I asked (already knowing) what the normal sample size was they analyzed? What, 100,000 samples? Sure let's use one of those... 20 minutes later mine was finished, I cleverly asked to run first since I lost the prior test. He ran his. It took a while. The next morning his finished. The results were the same. Save the physicist was a mixture of miffed and conciliatory. Very brilliant physicist. Not so great at mathematics. I've even encountered programs implemented in a manner to be non-deterministic when a deterministic solution existed. Vexing is working with some programmer that thinks they know everything. Which really annoys the ones that do.

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

[arglebargle_xiv]

It's not truncated, he used strcpy() and it's overflowed into the next memory block, along with the nop sled and 0day exploit.

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

[Cederic]

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.

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

[carlos92]

Agile is meant to help you learn about the problem domain. If you already know everything about the problem, there's no need for Agile. If somebody else already knows everything about the problem and you can hire him/her, the do it - no need for Agile. If nobody knows everything about the problem because it's a new problem that no one else has worked on yet or a new approach to a known problem, then you definitely need Agile or something similar to help you produce something that works at the same time that you are learning about the problem.

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

[carlos92]

I currently work in a project where:
- there are no schedules or estimates,
- everyone seems to believe that tickets with a three-word title and an empty description fit the definition of "spec", and
- answering questions with just "yes" or "no" sometimes takes weeks, even if the ticket is urgent and not answering the question blocks further work on the ticket, and
- the codebase shows attempts at following every programming technique, concept, trend or fad from the last 10 years.

Fortunately, it's not as bad as it sounds because all the current BAs, developers and DBAs are making a great effort to improve things, but it's still bad.

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

[xtsigs]

This is often compounded by:

1. Customer changes as the project goes along and the importance gets kicked up the chain in customer's hierarchy, or, the VP loses interest and kicks the project down the chain wherein the project is suddenly confronted with reality.
2. Once a demo/prototype is running, the customer says, "That's great, but it has to do x as well."

Both problems are we called the Moving Target problem which can be solved by spending a lot of time up front specifying the scope and specifics. Too often this portion is done badly by salespeople trying to close the deal and move on to their next victim. Deadlines are established with too vague an understanding of what the target is, and project managers are left with an impossible task which they solve by compromising in the aforementioned areas--especially in hiring sub-par coders just to meet a deadline.

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

[bondsbw]

Write the code, but for the love, make it readable. Make it so readable to the point that you can show an implemented business rule to the guy who will be using it, and he should be able to make out what's going on even with no programming experience. (Not lower level database access, UI code, etc.)