Tag Archives: programming

Why Software Development Estimation is Hard: Sea Lions, and Coastal Paths

Among the many val­id responses to the Quora ques­tion of why soft­ware devel­op­ment task estim­a­tions are often off by a factor of 2–3, Michael Wolfe, CEO of Pipe­wise, describes exactly why this is without once men­tion­ing ‘soft­ware’ or ‘pro­ject’.

Instead, Wolfe elo­quently provides undoubtedly the best ana­logy I’ve ever heard for explain­ing the dif­fi­culty in provid­ing estim­ates for soft­ware pro­jects: a couple of friends plan­ning a coastal hike from San Fran­cisco to Los Angeles and start­ing their jour­ney.

Their friends are wait­ing in LA, phone calls have already been made push­ing the date back…

Man, this is slow going! Sand, water, stairs, creeks, angry sea lions! We are walk­ing at most 2 miles per hour, half as fast as we wanted. We can either start walk­ing 20 hours per day, or we can push our friends out anoth­er week. OK, let’s split the dif­fer­ence: we’ll walk 12 hours per day and push our friends out til the fol­low­ing week­end. We call them and delay din­ner until the fol­low­ing Sunday. They are a little peeved but say OK, we’ll see you then. […]

We get up the next morn­ing, band­age up our feet and get going. We turn a corner. Shit! What’s this?

God­damn map does­n’t show this shit!. We have to walk 3 miles inland, around some fenced-off, fed­er­ally-pro­tec­ted land, get lost twice, then make it back to the coast around noon. Most of the day gone for one mile of pro­gress. OK, we are *not* call­ing our friends to push back again. We walk until mid­night to try to catch up and get back on sched­ule.

Of course, this isn’t exactly a new ana­logy: it’s apply­ing the ideas behind Benoît Man­del­brot’s paper, How Long Is the Coast of Bri­tain?, pub­lished back in 1967, to soft­ware estim­a­tion. Still, it works per­fectly.

If you like Wolfe’s writ­ing style and want to read more, he runs a blog called Dear Founder.

Update: And of course, there’s always O.P.C.

Art in 140 Characters

Is it pos­sible to encode and com­press an image to such a degree that the raw data can fit in a single Twit­ter mes­sage (140 char­ac­ters) that, when decoded again, is still recog­nis­able? The answer to the ques­tions is a resound­ing Yes, as con­firmed by a cod­ing chal­lenge inspired by Mario Klinge­man­n’s attempt to com­press and encode the Mona Lisa down to 140 char­ac­ters.

Klinge­man­n’s attempt, dubbed the Mon­aT­weeta II, is def­in­itely an image recog­nis­able as the Mona Lisa, but it must be said that some of the entries to the main cod­ing chal­lenge are truly breath­tak­ing.

The win­ning tweet (with a char­ac­ter to spare):


via @spolsky

Software Project Metrics and Control: They Don’t Matter (Sometimes)

Soft­ware pro­ject met­rics are not as import­ant as we have been led to believe, and the field of soft­ware engin­eer­ing has evolved to such a state as to almost be almost… over.

This is accord­ing to the emin­ent soft­ware engin­eer Tom DeMarco who, look­ing back at his 1986 book on the sub­ject, Con­trolling Soft­ware Pro­jects: Man­age­ment, Meas­ure­ment, and Estim­ates, now believes that our focus on con­trol and met­rics is wrong, and we need to com­pletely reverse how we cre­ate and man­age soft­ware, if pos­sible (pdf).

The book’s most quoted line is its first sen­tence: “You can­’t con­trol what you can­’t meas­ure.” This line con­tains a real truth, but I’ve become increas­ingly uncom­fort­able with my use of it. Impli­cit in the quote (and indeed in the book’s title) is that con­trol is an import­ant aspect, maybe the most import­ant, of any soft­ware pro­ject. But it isn’t. Many pro­jects have pro­ceeded without much con­trol but man­aged to pro­duce won­der­ful products such as GoogleEarth or Wiki­pe­dia.

To under­stand con­trol’s real role, you need to dis­tin­guish between two drastic­ally dif­fer­ent kinds of pro­jects:

  • Pro­ject A will even­tu­ally cost about a mil­lion dol­lars and pro­duce value of around $1.1 mil­lion.
  • Pro­ject B will even­tu­ally cost about a mil­lion dol­lars and pro­duce value of more than $50 mil­lion.

What’s imme­di­ately appar­ent is that con­trol is really import­ant for Pro­ject A but almost not at all import­ant for Pro­ject B. This leads us to the odd con­clu­sion that strict con­trol is some­thing that mat­ters a lot on rel­at­ively use­less pro­jects and much less on use­ful pro­jects. It sug­gests that the more you focus on con­trol, the more likely you’re work­ing on a pro­ject that’s striv­ing to deliv­er some­thing of rel­at­ively minor value.

To my mind, the ques­tion that’s much more import­ant than how to con­trol a soft­ware pro­ject is, why on earth are we doing so many pro­jects that deliv­er such mar­gin­al value? […]

For the past 40 years […] we’ve tor­tured ourselves over our inab­il­ity to fin­ish a soft­ware pro­ject on time and on budget. […] This nev­er should have been the supreme goal. The more import­ant goal is trans­form­a­tion, cre­at­ing soft­ware that changes the world or that trans­forms a com­pany or how it does busi­ness.

via Cod­ing Hor­ror

Summarising Joel on Software

Now that Joel Spol­sky has ‘retired’ from blog­ging at Joel on Soft­ware (in the format the site has been known for, at least), Jan Willem Boer is read­ing the entire back-cata­logue of entries and con­dens­ing the know­ledge with­in each essay into a single sen­tence (or two).

The res­ult is a stun­ning list of tips on run­ning a small busi­ness, pro­gram­ming best prac­tices, pro­ductiv­ity tips, tech­nic­al hir­ing prac­tices and entre­pren­eur­ship.

The series:

Why We Should Trust Driving Computers

In light of recent sug­ges­tions of tech­nic­al faults and the ensu­ing recall of a num­ber of mod­els from Toyota’s line, Robert Wright looks at why we should not worry about driv­ing mod­ern cars.

The reas­ons: the increased risks are neg­li­gible, the sys­tems that fail undoubtedly save more lives than not, this is the nature of car ‘test­ing’.

Our cars are, increas­ingly, soft­ware-driv­en — that is, they’re doing more and more of the driv­ing.

And soft­ware, as the people at Microsoft or Apple can tell you, is full of sur­prises. It’s pretty much impossible to anti­cip­ate all the bugs in a com­plex com­puter pro­gram. Hence the reli­ance on beta test­ing. […]

Now, “beta test­ing” sounds creepy when the pro­cess by which test­ers uncov­er bugs can involve death. But there are two reas­ons not to start bemoan­ing the brave new world we’re enter­ing.

First, even back before cars were soft­ware-driv­en, beta test­ing was com­mon. Any car is a sys­tem too com­plex for design­ers to fully anti­cip­ate the upshot for life and limb. Hence dec­ades of non-micro­chip-related safety recalls.

Second, the fact that a fea­ture of a car can be fatal isn’t neces­sar­ily a per­suas­ive objec­tion to it. […]

Sim­il­arly, those soft­ware fea­tures that are sure to have unanti­cip­ated bugs, includ­ing fatal ones, have upsides. Elec­tron­ic sta­bil­ity con­trol keeps cars from flip­ping over, and elec­tron­ic throttle con­trol improves mileage.