Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. "That's pretty good!" says his boss, "you're a fast worker!" and pays him a kopeck.
The next day Shlemiel only gets 150 yards done. "Well, that's not nearly as good as yesterday, but you're still a fast worker. 150 yards is respectable," and pays him a kopeck.
The next day Shlemiel paints 30 yards of the road. "Only 30!" shouts his boss. "That's unacceptable! On the first day you did ten times that much work! What's going on?" "I can't help it," says Shlemiel. "Every day I get farther and farther away from the paint can!" -- Shlemiel the painter algorithm
Ran across this great
interview of Joel Spolsky from Salon back in 2004. The dude has some great things to say...
In reference to the various software development methodologies:
There's certainly a lot of faux methodologies, what I often call "big-M" methodologies, extreme programming being a very popular one right now. And even when they're reflecting good ideas or best practices, the real goal of the methodologies is to sell books, not to actually solve anybody's problem. And selling the books is actually just a way to sell consulting engagements that the people who write those books do at high cost; that's their career -- giving speeches to people working for very boring companies on how to do software better.
In reference to creating software that will automatically translate a user's desire into code:
The fundamental problem that you're trying to solve here is that humans think of things in vague, mushy terms. In order to visualize something, they don't have to actually visualize every part of it. Whereas the programmer, in order to actually implement that thing, to create it, needs to have every part specified.
(continued...)
So your brain doesn't actually work the way a computer works. Your brain doesn't assume that there's all this input coming in and then process it. Instead, it just has a variety of senses available to it, and it picks the ones it wants to answer whatever questions it has right now. So you ask questions, and your eye goes and finds out the information it needs. So you're used to thinking that you have the big picture , and you don't.
(continued some more...)
And so what a programmer is doing when they translate a quote unquote spec into quote unquote code, although it seems like a translation process, what they're actually doing is filling in lots and lots of details. And as programmers are wont to do, they're trying to take something, the vague thing that the humans want, and make it very, very specific, which is the kind of thing the computer wants. That's not really a translation; it's more of an interpretation. It's a very hard thing to do.
Read Joel's
Back to Basics post for more interesting tidbits on
Shlemiel the painter algorithm, Pascal strings, and my favorite...XML performance issues. I've developed and supported EDI transaction processing for over 9 years and witnessed first hand the problems Joel discusses with XML. Great stuff!
Happy New Year!
MT
