What do you think?
Rate this book
What I've Learned From Failure
http://leanpub.com/shippingsoftware
A compendium of Reginald "Raganwald" Braithwaite's internet ramblings both old and newly composed for the book, "What I've Learned From Failure" collects his very best "non-technical" essays on the subject of shipping software. As more essays are added to the book, you will receive free updates at no extra charge!
A compendium of Reginald "Raganwald" Braithwaite's internet ramblings both old and newly composed for the book, "What I've Learned From Failure" collects his very best "non-technical" essays on the subject of shipping software. As more essays are added to the book, you will receive free updates at no extra charge!
ebook
19 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
March 25, 2012
What with mowing lawns, staining a deck, and driving a lot between home and Auckland, I've had a lot of time lately to think about software development. It's a bloody weird business, and it's hard to think of many other endeavours where the results are so variable. New Zealand's Inland Revenue Department have to upgrade their computer system, it could cost them a billion dollars, and nobody knows if it'll work or not. Chances are it won't, as government has an almost perfect record in failed large computer projects. Braithwaite (whom I can only think of as his online handle, @raganwald) has a pretty good handle on what has to happen if it is to succeed.
His thin book has only 55 or so pages, but it contains a lot of truth about software development. At least, a lot that feels true based on my experience. And that's a point he makes clearly in one section: software development is probabilistic, not deterministic. If it were deterministic, the tradition "design it then build it, and you can have lots of mediocre minds working in parallel so long as really smart people do the design for them first" model would work. And it doesn't. Time and time again it fails
Braithwaite also talks about the danger signs of failure, the kinds of things that if you don't have them then your project is probably going to fail. For example, intimate knowledge of who is working on what: I can tell you, whenever the details of a project have slipped from my grasp, the project has started to drift into trouble. I make no apologies for now insisting on knowing exactly who, what, where, when, and why. There’s a big difference between being asked to explain your work in detail and being told how to do your job.
He's a fan of agile, in as much as he's a fan of the things that agile gives you. Stakeholders treasure good dates. Stakeholders despise bad dates and the people who make flawed promises. That would have been me, more than once. Every time, the lesson has been clear. Don’t get the dates wrong. I’ll confess: I don’t really think Scrum is an order of magnitude more effective than anything else at producing beautiful, world-changing software. It may be worse. But it does produce software every month, month after month.
It's in this list of preconditions for success that we find what will probably doom any billion-dollar Hail Mary IRD software project: control. He tells the story of ham and eggs, where chicken was involved but the pig was committed. Getting away from weak teams, another source of failure is the omnipresent threat of “chickens.” A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team. Even a single chicken can take a project out. Chickens are a special case of “external dependencies.” Special, because they are often politically entrenched. Danged if that doesn't describe government to a t.
So, sorry IRD: in just 55 pages I've found the words for why I think you're doomed. If you want to talk about how to fix it, leave a message on my phone and I'll call you back when I'm done with this lawn ....
His thin book has only 55 or so pages, but it contains a lot of truth about software development. At least, a lot that feels true based on my experience. And that's a point he makes clearly in one section: software development is probabilistic, not deterministic. If it were deterministic, the tradition "design it then build it, and you can have lots of mediocre minds working in parallel so long as really smart people do the design for them first" model would work. And it doesn't. Time and time again it fails
Braithwaite also talks about the danger signs of failure, the kinds of things that if you don't have them then your project is probably going to fail. For example, intimate knowledge of who is working on what: I can tell you, whenever the details of a project have slipped from my grasp, the project has started to drift into trouble. I make no apologies for now insisting on knowing exactly who, what, where, when, and why. There’s a big difference between being asked to explain your work in detail and being told how to do your job.
He's a fan of agile, in as much as he's a fan of the things that agile gives you. Stakeholders treasure good dates. Stakeholders despise bad dates and the people who make flawed promises. That would have been me, more than once. Every time, the lesson has been clear. Don’t get the dates wrong. I’ll confess: I don’t really think Scrum is an order of magnitude more effective than anything else at producing beautiful, world-changing software. It may be worse. But it does produce software every month, month after month.
It's in this list of preconditions for success that we find what will probably doom any billion-dollar Hail Mary IRD software project: control. He tells the story of ham and eggs, where chicken was involved but the pig was committed. Getting away from weak teams, another source of failure is the omnipresent threat of “chickens.” A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team. Even a single chicken can take a project out. Chickens are a special case of “external dependencies.” Special, because they are often politically entrenched. Danged if that doesn't describe government to a t.
So, sorry IRD: in just 55 pages I've found the words for why I think you're doomed. If you want to talk about how to fix it, leave a message on my phone and I'll call you back when I'm done with this lawn ....
Displaying 1 of 1 review