Tag Archives: software

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

Among the many valid responses to the Quora question of why software development task estimations are often off by a factor of 2–3, Michael Wolfe, CEO of Pipewise, describes exactly why this is without once mentioning ‘software’ or ‘project’.

Instead, Wolfe eloquently provides undoubtedly the best analogy I’ve ever heard for explaining the difficulty in providing estimates for software projects: a couple of friends planning a coastal hike from San Francisco to Los Angeles and starting their journey.

Their friends are waiting in LA, phone calls have already been made pushing the date back…

Man, this is slow going! Sand, water, stairs, creeks, angry sea lions! We are walking at most 2 miles per hour, half as fast as we wanted. We can either start walking 20 hours per day, or we can push our friends out another week. OK, let’s split the difference: we’ll walk 12 hours per day and push our friends out til the following weekend. We call them and delay dinner until the following Sunday. They are a little peeved but say OK, we’ll see you then. […]

We get up the next morning, bandage up our feet and get going. We turn a corner. Shit! What’s this?

Goddamn map doesn’t show this shit!. We have to walk 3 miles inland, around some fenced-off, federally-protected land, get lost twice, then make it back to the coast around noon. Most of the day gone for one mile of progress. OK, we are *not* calling our friends to push back again. We walk until midnight to try to catch up and get back on schedule.

Of course, this isn’t exactly a new analogy: it’s applying the ideas behind Benoît Mandelbrot’s paper, How Long Is the Coast of Britain?, published back in 1967, to software estimation. Still, it works perfectly.

If you like Wolfe’s writing 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)

Software project metrics are not as important as we have been led to believe, and the field of software engineering has evolved to such a state as to almost be almost… over.

This is according to the eminent software engineer Tom DeMarco who, looking back at his 1986 book on the subject, Controlling Software Projects: Management, Measurement, and Estimates, now believes that our focus on control and metrics is wrong, and we need to completely reverse how we create and manage software, if possible (pdf).

The book’s most quoted line is its first sentence: “You can’t control what you can’t measure.” This line contains a real truth, but I’ve become increasingly uncomfortable with my use of it. Implicit in the quote (and indeed in the book’s title) is that control is an important aspect, maybe the most important, of any software project. But it isn’t. Many projects have proceeded without much control but managed to produce wonderful products such as GoogleEarth or Wikipedia.

To understand control’s real role, you need to distinguish between two drastically different kinds of projects:

  • Project A will eventually cost about a million dollars and produce value of around $1.1 million.
  • Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value? […]

For the past 40 years […] we’ve tortured ourselves over our inability to finish a software project on time and on budget. […] This never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

via Coding Horror

Selling Software on a Shoestring

From the early days of development through to the release and refinement of the final product (and further), Patrick McKenzie has been chronicling his journey as a one-man Micro ISV (Micro Independent Software Vendor).

McKenzie has recently compiled a fantastic list of his best posts and this acts as a list of practical advice for small companies on topics such as SEO, marketing and adjusting to the self-employed lifestyle.

Making Applications Viral, Without Spam

Virality isn’t an indispensable feature of all successful applications, but for those where it can be hugely beneficial there are four core principles that help the virality of an application, says Daniel Tanner:

  • Invitation should be a core process, that is essential to using the application – this will maximise the chances that your users do invite new users.
  • Keep pulling people back in, rather than letting them forget you after the initial invitation, and make this “reminder” process also be central to the use of the application.
  • Be useful even to the lone user, because that lone user is the source of all your other users.
  • Remove artificial invitation limits, to recognise the reality that most invitations come from a few very active users, and help those users spread the word.

Tenner also notes–in passing–the concept of the viral loop. Andrew Chen’s take on the loop is the best I’ve read on the topic.

Overcoming Network Effects

A network effect is “the effect that one user of a good or service has on the value of that product to other people”. When there is a positive network effect we say that the good or service in question increases in usefulness the more users there are, like the telephone or online social networks.

Of course, being in a business or sector that relies on positive network externalities brings with it one inherent problem: getting to the sociodynamic critical mass. Chris Dixon looks at six strategies for overcoming strong network effects; the so-called “chicken and egg” problems.

  • Signal long-term commitment to platform success and competitive pricing: Microsoft’s $500m promotion of the xbox platform.
  • Use backwards and sideways compatibility to benefit from existing complements: Microsoft with DOS and Windows versions, Apple with Bootcamp.
  • Exploit irregular network topologies: (Early) Facebook and JDate for social networking and dating respectively.
  • Influence the firms that produce vital complements: Sony and Philips influencing Polygram for their CDs.
  • Provide standalone value for the base product: Recording of television on VCRs.
  • Integrate vertically into critical complements when supply is not certain: Nintendo’s games consoles with games funded by Microsoft and Sony.

via Ben Casnocha