Posts Tagged ‘software development’

Software development metaphors

December 2, 2008

Jeff at Coding Horror gives a pointer to a summary of metaphors:

oftware: do you write it like a book, grow it like a plant, accrete it like a pearl, or construct it like a building? As Steve McConnell notes in Code Complete 2, there’s no shortage of software development metaphors:

A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it’s an art (1998). Watts Humphrey says it’s a process (1989). P. J. Plauger and Kent Beck say it’s like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it’s a game (2002). Eric Raymond says it’s like a bazaar (2000). Andy Hunt and Dave Thomas say it’s like gardening. Paul Heckel says it’s like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it’s like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?

I think we’re leaving one metaphor on the table which more accurately reflects the way software is built in the real world: flail around randomly and pray you succeed by force of pure dumb luck. Sometimes it even works. Not very often, but just enough to confuse people who should know better into thinking they’re smart, when what they really were is lucky.

The answer, of course, is whichever metaphor helps you and your team get to the end of the project. Personally, I see them as more of a battle cry, a way for a team to communicate a shared vision and a set of values. They’re heavy on imagery and metaphor, and light on specific, concrete advice.

Take a look!

Medical anthropology and programming as art

January 8, 2008

A couple of interesting posts I noticed:

  1. John Hawks points to an article in New England Journal of Medicine that describes the documentation of the health access needs of the wheelchair bound, and thinks that it is a great example of medical anthropology:

    She doesn’t call it medical anthropology, but it is a nice example of the use of new ethnographic methods (in this case, video observation) to document social interactions.

  2. Joel Spolsky has some suggestions to improve software education — a programme intensive Bachelors programme in software development:

    Such a program would consist of a practical studio requirement developing significant works of software on teams with very experienced teachers, with a sprinkling of liberal arts classes for balance. It would be a huge magnet to the talented high school kids who love programming, but can’t get excited about proving theorums.

    When I said BFA, Bachelor of Fine Arts, I meant it: software development is an art, and the existing Computer Science education, where you’re expected to learn a few things about NP completeness and Quicksort is singularly inadequate to training students how to develop software.

    Imagine instead an undergraduate curriculum that consists of 1/3 liberal arts, and 2/3 software development work. The teachers are experienced software developers from industry. The studio operates like a software company. You might be able to major in Game Development and work on a significant game title, for example, and that’s how you spend most of your time, just like a film student spends a lot of time actually making films and the dance students spend most of their time dancing.

Take a look!

What is evidence based scheduling?

October 26, 2007

Joel Spolsky has a must-read essay on what is known as Evidence Based Scheduling:

Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.

I know I am not in the software business; however, if I can come up with more reliable estimates for the codes that I develop, why not?

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

Spolsky’s essay is also full of useful pointers based on his experience with using EBS. Take a look!