all

If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

there's something wrong with the methodology itself if 90% of the projects fail to use it properly





I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!

Edsger Dijkstra



better

we judge the table saw on whether and how it can improve the results we could have obtained with another tool

incremental value





The mythical marginal





unactualized potential

Shipping software is not an emergant property of competent programming, nor is it a consequence of management technique.

It always comes back to hiring

has the individual demonstrated success shipping software in the past

True happiness comes from the joy of deeds well done, the zest of creating things new.

shipping software is not an emergant property of competent programming, nor is it a consequence of management technique

(Update

Postscript: The difference between Sashimi and Nigiri

If we're judging success or failure of a development methodology, we have to judge the results on whether the development itself was successful. We can't judge whether the software made money, or whether the company's stock soared. Such things can be studied, however those are product management problems, not software development problems.



People have criticised Google, saying that althought it has a track record for shipping products, only one, AdWords, is financially successful. If you want to compare product management methodologies, that's fine, but you aren't talking about software development. You have to compare similar kinds of projects, for example you can't compare an in-house IT project with a known ROI (reduce the time spent entering a new Blort Ticket by 50%, saving $47.32 per week per Fizbang team member) to speculative product development like a new Web 2.0 calendar.



Who else is trying to create new products? Apple? Microsoft? Dan Bricklin? Compare them to Google, and if they are doing a better job of making money with their projects, post a critique of Google's product management on your blog.



-r.b.



There is only one problem with development methodologies. Just one. It affectsmethodologies, agile and otherwise: No methodology can 'fix' projects that are staffed with underperforming people. People are more important than process, period.This is the underlying issue with the language 'wars' as well. No magical combination of JSON, static typing, design patterns, IDE whizzies, and frameworks will somehow help a million monkeys produce any of Shakespeare's works.Steve Yegge has suggested that if 90% of the projects adopting a methodology fail, you have to stop blaming the people. You have to stop saying "you're not doing it right." You have to saySounds reasonable. But why would this be true for methodologies but not true for programming languages?99.999% of the software written in almost any language (including Lisp, Python, and Ruby) is buggy. Yet we readily say that the problem is the programmer. We think that some languages are better than others, that some languages help eliminate certain classes of bugs, but we take as a given that good tools are not sufficient unto themselvesfor good results. We know that the quality of the result is almost entirely driven by the quality of the programmer.Home Depot might suggest that buying a new table saw will cause beautiful woodwork to appear in your home. Yet just because a duffer with a table saw cannot make built-in closets all by himself, we don't abandon table saws outright. We assume that good woodworking iswith good tools. And if we are blessed with the skill to make a built-in closet with a hand saw, we know that we can also make the closet with a table saw, andThis is my criteria for judging a methodology. Can it improve a team that is already fundamentally qualified to write software?If you want to stop reading here, my statement is that you can only judge a methodology on the basis of the results it delivers for a team that has already proven it can ship software. You judge it on the basis of. You don't compare its results to the results some other team gets, or to your fantasy of what results the team 'ought' to get.What I've written seems obvious. Yet, billions of dollars are paid every year to people who are selling a different perspective. What is it that causes companies to buy silver bullet after silver bullet? Why do companies lurch from consultant to methodology to programming language like infomercial junkies looking for something that will flatten their tummies without sweaty exercise or unpleasant diets?I bifurcate teams into those that are fundamentally qualified and those that aren't. And I believe that to fix an unqualified team, you start with the people, not the process or the tools. So what could the rest of the IT industry possibly believe?I have observed a belief in a marginal team. A team that is somehow straddling the fence between incompetence and competence. They can ship software, but only with help from their process and tools. If 'marginal' is too perjorative a term, you could think of them as havingIn truth, I have worked with several such teams, so I believe they exist. However, I believe that such teams are quite rare, while proponents of silver bullets make a living convincing customers that marginal teams are commonplace.The primary example I have observed of a marginal team is a team composed of individuals who are not working together well, yet they have achieved success on other teams in prior roles. Something like the Los Angeles Lakers before Phil Jackson arrived. There is a lot of latent championship potential in the individuals, but the team isn't performing.Why does the IT industry believe that perhaps most teams that fail are marginal teams? They have to believe this, otherwise they wouldn't waste time and money trying new silver bullets ("everything should be a stored procedure," "tests are the only documentation that matter").My broken-record assertion is that the industry as a whole embraces the above model of a marginal team: latent potential in the individuals. The difference between the industry and I is that I have an objective measure of latent potential:The industry doesn't apply this test rigorously, if at all. A typical interview with a developer focuses on patterns and archiecture, on talking about past achievements. Developer's don't juggle . Developer's don't design software . And especially, managers don't hire developers with super-strong references from strong employees that have worked with the candidate in the past.Basically, managers ask developers if they can ship software and then take the candidate's word for it. If you take only one thing from this blog post, take this:. Someone can demonstrate the ability to write software but lack the ability to actually ship software.: nothing in this post should be construed to suggest that people cannot become better developers through study, mentorships, or training. However, training is to hiring as tools are to skill. And they are not mutually exclusive, any more than good programmers and good tools are mutually exclusive.)I believe that the reason why the IT industry believes that most failing teams are marginal rather than outright incompetent is that they believe that these teams are composed of individuals who can write software and managers who can direct work. All they need are the right tools to write software "better" and better software will emerge. All they need is a methodology to manage software development better and software will ship.If you have a marginal team, a team composed of individuals with proven ability to ship working software, you might have something there. But if a team isn't even marginal, no methodology will help. And that's why a useful methodology can still fail to help 90% of the teams that try it.For the same reason that Wasabi makes Sushi divine.

Labels: agile, popular