The Old Joel on Software Forum: Part 4 (of 5) - Real programming challenge is identifying the prob

Real programming challenge is identifying the prob

I think the real challeng of programming (today) is properly identifying the problem.

The next biggest challeng is properly specifying a solution. OFTEN, the spec gets the blame for a poor product, but it's because someone didn't properly identify the problem.

1. Define the problem.
2. Consider options
3. Specify possible solution
4. Test solution against #1.
5. Create program.

#1,2, and 4 often get skipped. #3 gets the blame.

How many times have YOU worked on a program where you thought "what PROBLEM are we really solving here?"

Just a thought.

Opinions? (Talk amongst yourselves)

Mr. Analogy
Sunday, April 18, 2004

Yep. Part of the reason is that identifying "the problem" is tricky. People identify something that looks like a problem but is just a symptom, or a false trail; or they ask someone (the proverbial 'expert' or 'consultant') to tell them what the problem is -- and that person/group may not be able to properly identify the problem (or, may purposefully mis-identify the problem). Then you have the people who aren't really trying to solve a problem at all, but want to build up their powerbase or set themselves up for a promotion or get back at the dirty rotten so-and-so who wrongly got credit for something.

In my own experience, identifying problems is most successful when done after identifying the goal. I can look around and see all kinds of "problems". But if they aren't relevant to the goal, it's a waste of time for me to solve them.

Should be working
Monday, April 19, 2004

Yes, I agree with both. Usually what I find is that the problem is incorrectly defined to begin with and usually is created *after* a solution has been acquired.

example: We bought Oracle. We must've had a reason for spending $2M on licensing, $1M on retraining/new hires, and $10M on migration. Our previous DBMS { must have been slow | didn’t have feature XYZ | $dubious_reason_here }.

Also, most practitioners these days only know tools and how to mechanically apply them – they lack the ability to accurately define problems, and, of course, are driven by fad-oriented development.

example: We should use XML to information for our embedded product because everyone else is doing it.

MR
Monday, April 19, 2004

Also practitioners lack either the ability (management pressure to approve XYZ or they know nothing about the domain), desire (they don’t care either way which is approved), or education (they do not know how to make evaluations) to accurately and objectively evaluate products.

MR
Monday, April 19, 2004