Tag Archives: programming

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.

Art in 140 Characters

Is it possible to encode and compress an image to such a degree that the raw data can fit in a single Twitter message (140 characters) that, when decoded again, is still recognisable? The answer to the questions is a resounding Yes, as confirmed by a coding challenge inspired by Mario Klingemann’s attempt to compress and encode the Mona Lisa down to 140 characters.

Klingemann’s attempt, dubbed the MonaTweeta II, is definitely an image recognisable as the Mona Lisa, but it must be said that some of the entries to the main coding challenge are truly breathtaking.

The winning tweet (with a character to spare):

咏璘驞凄脒鵚据蛥鸂拗朐朖辿韩瀦魷歪痫栘璯緍脲蕜抱揎頻蓼債鑡嗞靊寞柮嚛嚵籥聚隤慛絖銓馿渫櫰矍昀鰛掾撄粂敽牙稉擎蔍螎葙峬覧絀蹔抆惫冧笻哜搀澐芯譶辍澮垝黟偞媄童竽梀韠镰猳閺狌而羶喙伆杇婣唆鐤諽鷍鴞駫搶毤埙誖萜愿旖鞰萗勹鈱哳垬濅鬒秀瞛洆认気狋異闥籴珵仾氙熜謋繴茴晋髭杍嚖熥勳縿餅珝爸擸萿

via @spolsky

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

Summarising Joel on Software

Now that Joel Spolsky has ‘retired’ from blogging at Joel on Software (in the format the site has been known for, at least), Jan Willem Boer is reading the entire back-catalogue of entries and condensing the knowledge within each essay into a single sentence (or two).

The result is a stunning list of tips on running a small business, programming best practices, productivity tips, technical hiring practices and entrepreneurship.

The series:

Why We Should Trust Driving Computers

In light of recent suggestions of technical faults and the ensuing recall of a number of models from Toyota’s line, Robert Wright looks at why we should not worry about driving modern cars.

The reasons: the increased risks are negligible, the systems that fail undoubtedly save more lives than not, this is the nature of car ‘testing’.

Our cars are, increasingly, software-driven — that is, they’re doing more and more of the driving.

And software, as the people at Microsoft or Apple can tell you, is full of surprises. It’s pretty much impossible to anticipate all the bugs in a complex computer program. Hence the reliance on beta testing. […]

Now, “beta testing” sounds creepy when the process by which testers uncover bugs can involve death. But there are two reasons not to start bemoaning the brave new world we’re entering.

First, even back before cars were software-driven, beta testing was common. Any car is a system too complex for designers to fully anticipate the upshot for life and limb. Hence decades of non-microchip-related safety recalls.

Second, the fact that a feature of a car can be fatal isn’t necessarily a persuasive objection to it. […]

Similarly, those software features that are sure to have unanticipated bugs, including fatal ones, have upsides. Electronic stability control keeps cars from flipping over, and electronic throttle control improves mileage.