Tag Archives: software

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.

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

Selling Software on a Shoestring

From the early days of devel­op­ment through to the release and refine­ment of the final product (and fur­ther), Patrick McK­en­zie has been chron­ic­ling his jour­ney as a one-man Micro ISV (Micro Inde­pend­ent Soft­ware Vendor).

McK­en­zie has recently com­piled a fant­ast­ic list of his best posts and this acts as a list of prac­tic­al advice for small com­pan­ies on top­ics such as SEO, mar­ket­ing and adjust­ing to the self-employed life­style.

Making Applications Viral, Without Spam

Vir­al­ity isn’t an indis­pens­able fea­ture of all suc­cess­ful applic­a­tions, but for those where it can be hugely bene­fi­cial there are four core prin­ciples that help the vir­al­ity of an applic­a­tion, says Daniel Tan­ner:

  • Invit­a­tion should be a core pro­cess, that is essen­tial to using the applic­a­tion – this will max­im­ise the chances that your users do invite new users.
  • Keep pulling people back in, rather than let­ting them for­get you after the ini­tial invit­a­tion, and make this “remind­er” pro­cess also be cent­ral to the use of the applic­a­tion.
  • Be use­ful even to the lone user, because that lone user is the source of all your oth­er users.
  • Remove arti­fi­cial invit­a­tion lim­its, to recog­nise the real­ity that most invit­a­tions come from a few very act­ive users, and help those users spread the word.

Ten­ner also notes–in passing–the concept of the vir­al loop. Andrew Chen’s take on the loop is the best I’ve read on the top­ic.

Overcoming Network Effects

A net­work effect is “the effect that one user of a good or ser­vice has on the value of that product to oth­er people”. When there is a pos­it­ive net­work effect we say that the good or ser­vice in ques­tion increases in use­ful­ness the more users there are, like the tele­phone or online social net­works.

Of course, being in a busi­ness or sec­tor that relies on pos­it­ive net­work extern­al­it­ies brings with it one inher­ent prob­lem: get­ting to the socio­dy­nam­ic crit­ic­al mass. Chris Dix­on looks at six strategies for over­com­ing strong net­work effects; the so-called “chick­en and egg” prob­lems.

  • Sig­nal long-term com­mit­ment to plat­form suc­cess and com­pet­it­ive pri­cing: Microsoft’s $500m pro­mo­tion of the xbox plat­form.
  • Use back­wards and side­ways com­pat­ib­il­ity to bene­fit from exist­ing com­ple­ments: Microsoft with DOS and Win­dows ver­sions, Apple with Boot­camp.
  • Exploit irreg­u­lar net­work topo­lo­gies: (Early) Face­book and JDate for social net­work­ing and dat­ing respect­ively.
  • Influ­ence the firms that pro­duce vital com­ple­ments: Sony and Philips influ­en­cing Poly­gram for their CDs.
  • Provide stan­dalone value for the base product: Record­ing of tele­vi­sion on VCRs.
  • Integ­rate ver­tic­ally into crit­ic­al com­ple­ments when sup­ply is not cer­tain: Nin­ten­do’s games con­soles with games fun­ded by Microsoft and Sony.

via Ben Cas­nocha