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.