From @sharads tweet, I discovered JP’s blog. I would like to share a couple of snippets from his About This Blog page.
I believe that Moore’s Law and Metcalfe’s Law and Gilder’s Law have created an environment where it is finally possible to demonstrate the value of information technology in simple terms rather than by complex inferences and abstract arguments.
I believe that simplicity and convenience are important, and that we have to learn to respect human time.
I believe we need to discuss these things and find ways of getting them right. And I have a fervent hope that through this blog, I can keep the conversations going and learn from them.
I agree – we do need to discuss these things and find ways of getting them right.
I, like a lot of others in the software industry, belong to the Fred Brooks fan club. I first read The Mythical Man Month in 80s but since I was just doing my first startup, did not fully comprehend some of the problems Brooks was talking about. After 25 years in 4 startups and a couple of dozen products, I feel that many insights Fred Brooks provided in that book are still very valuable.
In this interview Brooks talks about design. A few nuggets:
Brooks: The critical thing about the design process is to identify your scarcest resource. Despite what you may think, that very often is not money. For example, in a NASA moon shot, money is abundant but lightness is scarce; every ounce of weight requires tons of material below. On the design of a beach vacation home, the limitation may be your ocean-front footage. You have to make sure your whole team understands what scarce resource you’re optimizing.
Great design does not come from great processes; it comes from great designers.
When I first wrote The Mythical Man-Month in 1975, I counseled programmers to “throw the first version away,” then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised.
Brooks refuses to predict the future of software into the next 50 years saying that:
All of my past predictions have been, shall we say, short-sighted.
This interview is a nice read and I am sure the book The Design of Design will be a great one. It is nice to see that some of the classics like The Mythical Man Month still sell a lot.
Why does this strike a chord? This frankly brutal post on myths of Project Management is much more than that:
Life is full of consensual hallucinations. A polite way of saying we’re surrounded by bullshit. If you live in a democracy, you tend to believe you have a say in what happens in your life. There’s a tendency to ignore the reality of politicians being soulless whores who are bought and paid for by vested interests. The consensual hallucination of participatory democracy is more comforting. Voting is little more than a sideshow but life’s a little easier to bear if we pretend voting can actually change anything.
I can attest to the fact that software development is not all that predictable. Well, let me restate that. Not all aspects of software development are predictable – people, problems, processes or specs. There is a complex relationship between various factors that get you something useful (or usable) at some point in time. But it is not based on what was expected or even predicted at the beginning of a project.
I am a strong adherent of theory P based on over 25 years of software development.
Theory P adherents believe that the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.
Believing in Theory P, we believe we ought to have a process for continually updating a plan that asymptotically approaches a description of reality as the project nears its conclusion.
Chris Wood has a great blog post on Software Development Metaphors.
He lists a set of software metaphors under broad categories like:
Traditional Software Development Metaphors
- Software Development as a Factory
- Software Development as Engineeing
- Software Development as Model/Architecture
- Software Development as Workflow Process
Radical Software Development Metaphors:
- Software Development as Craft
- Software Development as Game Playing
- Software Development as Composition
- Software Development as Learning/Experimentation/Invention
Chris points out that different shops have different metaphors and sometimes switching metaphors may be required.
if you want to evangelize a new software development methodology (for example, those who are trying to evangelize the use of XP in a traditional RUP organization) starting with a discussion around metaphors and basic understanding of software development might help the discussion, especially with non-technical users.
This is a good post. My current job is Teaching Software to beginners and building experimental prototypes. So my interest is more in Software as Learning/Experimentation/Invention. The radical models may be more appealing to beginners and small teams.
If you are a startup, you may start with one metaphor and will switch metaphors as you grow. It will be nice to see what metaphors most of the Web 2.0 companies use.