This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: When Best Practices aren't
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Let's start with what you already know. It doesn't matter if you're building software, a bridge, a space shuttle, or even something as seemingly trivial as a world class meal. The simple principles at the heart of producing any "job well done" are constant. They need not be a mystery to anyone who has ever performed a difficult task from inception to completion, and performed it well.
So this article attempts to have a little fun while exploring what might happen when you apply my vocation's pop project management philosophies to another type of task; bridge building. Perhaps as software developers, we can laugh at our selves a little along the way. What better way to learn?
The problem here is one of assumption - since we know the best practices in some fields of engineering (i.e., bridge building) - then we know that many of these same practices will apply to software development. The assumption is that we know how to plan. And that's a huge - and mistaken - assumption. At this point in time, software simply is not an engineering discipline. Repeat that as many times as is necessary. Software is a craft. As such, one can best compare software development to other crafts - like movie making and putting on a play. Are there 'best practices' that the entire field agrees on?
Heck no. Just as actors differ on how best to prepare for (and practice) a role, software developers differ on how best to develop software. These differences range from the high level methodology that ought to be used (Agile? Waterfall?) to the implementation style (static typing best? dynamic typing best?). People differ on the sorts of languages (imperative/declarative/functional). The point is, there's no general agreement on what 'best practices' for software development are, at any level of the job. Maybe there will be some day - but there isn't now
Which takes us to the parody. The author has decided to define 'agile bridge building', and via that example, poke fun at agile software development. The trouble is, bridge building, for the most part, is a very well understood field. The engineers in that field know what will, and what won't, work. They know what designs are feasible, and what materials are feasible. They know what kinds of trouble are possible given various trade-offs. In software, we simply cannot agree on any of those. Ask two developers, and you'll get three opinions on what is and is not best. You'll get disagreement on how best to proceed, and how best to implement - both at the theoretical and at the practical level.
It's past time for developers to admit the obvious - we don't know nearly as much about this field as we like to pretend we do.
Previous Topic
