(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Sunday, October 01, 2006
Three questions and three answers about Wasabi and Rotten Fish
I have read some questions about my post Wasabi cannot cure rotten fish. Here are the questions and my replies:
Reg, are you really saying "a good team will succeed despite methodological strategy"?
No. I'm saying that a "good" methodology cannot save a bad team. That does not mean that a good team can survive a bad methodology. There are four critical parts of a successful software project, and in my experience you cannot succeed if any of them are missing. People are the first of those, management the last. Methodology is a part of management in my view. In some situations, strong management can impose an informal rather than a formal methodology. But it would be stretching a point to claim that such situations lacked process or had a bad process.
Reg, when you say "the quality of the result is almost entirely driven by the quality of the programmer", are you also saying "the quality of the tool employed is irrelevant to the quality of the result"?
No, although I might have chosen better words for this idea. What I'm saying is that the difference in results between good and bad programmers using the same tool is much, much larger than the difference in results for programmers of equal abilities using good and bad tools. The good tools are wasted on bad programmers, who find ways to write Visual Basic in any language. The bad tools are the source of frustration for good programmers, who waste time and energy "greenspunning" the bad tools into passable tools.
So I am not saying that (good programmer, bad tool) == (good programmer, good tool). I am saying that:
(good programmer, any tool) - (bad programmer, same tool) >
(any programmer, good tool) - (same programmer, bad tool)
So it is to your advantage to combine good programmers with the best tools available to them. It is always possible to cause a project to fail by selecting bad tools. There is still a difference in result between a good programmer with a good tools and a good programmer with a bad tool. Just because it is a much smaller difference than the difference between good and bad programmers doesn't change the fact that there is a difference.
As Paul Graham and Assaf have pointed out, tool selection strongly drives your ability to attract and retain good programmers. So while in theory you may be able to combine good programmers with bad tools, in practice you may have programmers who are experts in buzzword obfuscation and UML refactoring, but they are not competent in actual programming.
Some "bad" tools have such fatal flaws that it is unrealistic to expect even talented teams to overcome the weaknesses in the tool. In that case my expectation is that a good programmer will fail just like a bad programmer, but the good programmer will alert you to the tool's weaknesses much earlier than a bad programmer, perhaps in the exit interview. Good luck with any project where your best people quit because of poor tools, management, or working conditions.
Finally, in some situations management does not restrict themselves to only prescribing a poor tool but compounds the error by proscribing effective use of the poor tool. In plain English, they don't just force their "A" programmers to use a "C" programming language, but they tell them to write software that they think a "C" would be comfortable maintaining.
(Aside: The usual intent is to "make the code easy to read and maintain." But the measure of "easy to read and maintain" is wrongly "would an inexperienced programmer write the code this way." This is not the same thing as "would an inexperienced but motivated programmer be able to study this code, learn from this code, understand this code, and then maintain this code.")
There is a much larger difference between good programmers using good tools and good programmers forced to use bad tools and bad programming practices. There is some debate as to whether my assertion holds for this "worst case scenario" (such organizations often go for broke, treating the Joel Test as a golf score and do things like demand that their programmers wear ties or refrain from using the Internet).
It may be that the formula becomes:
(good programmer, good tool) - (bad programmer, good tool) >
(good programmer, good tool) - (good programmer, bad tool+bad practices) >
(bad programmer, good tool) - (bad programmer, bad tool+bad practices)
Reg, I don't get the connection to the Wasabi DSL!?
The title was actually snarfed from Guy Kawasaki, who wrote this aphorism approximately twenty years ago. It may be traditional Japanese wisdom. Then again, it may not.
Reg, not everyone can hire the top 1%, 5%, 10%, or even 50% of all developers. So isn't your simplistic "hire great developers" suggestion broken?
(Make that four questions and answers)
You know, this kind of question reminds me why I'm prejudiced in favour of working for CEOs that have a background in competitive fields like sales or competitive team sports like Soccer.
In sales, nobody abandons the idea of hiring good salespeople because "not everyone can hire the top salespeople." Imagine being appointed coach of an Ultimate team. Do you abandon the idea of recruiting the most gifted athletes you can find because every team ought to be able to do the same thing and therefore you will have to settle for average players?
No, obviously not. There can only be one top company. There can only be one championship team. To win in a competitive arena, you have to have better people, and better strategy, and you have to out-execute your competitors. Your goal is to be the one company, to be the one team.
Of course your strategy won't work for everyone, it won't work if everybody tries it. By definition, in a competitive (or "zero-sum") game there is no strategy that can help every player win.
That's ok, you are not interested in World Peace, in every company providing nice working conditions and good management for programmers. You are ruthlessly attempting to beat those companies into oblivion. You want them closed, bankrupt. If they have any talented programmers you want to hire those programmers away from them and put them to work building your dream while their former employers mumble platitudes about "methodologies that produce great results from mediocre people".
Consultants can wander around selling utopian visions of methodologies that work for every company and every programmer, no matter how inexperienced or incapable. Language and tool vendors can spend billions convincing everyone that their silver bullet eliminates all of the bugs that cause projects to fail. IDE mavens can tout the code generation and auto-completion bells and whistles that will give every programmer, no matter how mundanely talented, the productivity of a wizard.
These people have a vested interest in maintaining the illusion that software development is a positive sum game where everyone can win, where every project can succeed, where every product will make money.
But if you are working in a start up where you have to compete for talent, compete for funding, and compete for business success, you do not care whether your strategy can work for 100% of the projects in the world. You care whether it works for just one project, yours.
If you are working on an internal project where you compete with the prospect of your work being outsourced, where you compete for funding with other projects, where you compete for executive mind share, you do not care whether your strategy can work for 100% of the projects in the world. You care whether it works for just one project, yours.
Honestly, what matters to me is how I manage my own projects.
post scriptum: Not everyone wants to be the top salesperson, some people play competitive sports for the camaraderie, not to win, and some people go to work for the purpose of collecting nothing more than a pay cheque. If this describes you, you may find a kindred spirit in the "Angry Aussie": In praise of an average career.
I have read some questions about my post Wasabi cannot cure rotten fish. Here are the questions and my replies:
Reg, are you really saying "a good team will succeed despite methodological strategy"?
No. I'm saying that a "good" methodology cannot save a bad team. That does not mean that a good team can survive a bad methodology. There are four critical parts of a successful software project, and in my experience you cannot succeed if any of them are missing. People are the first of those, management the last. Methodology is a part of management in my view. In some situations, strong management can impose an informal rather than a formal methodology. But it would be stretching a point to claim that such situations lacked process or had a bad process.
Reg, when you say "the quality of the result is almost entirely driven by the quality of the programmer", are you also saying "the quality of the tool employed is irrelevant to the quality of the result"?
No, although I might have chosen better words for this idea. What I'm saying is that the difference in results between good and bad programmers using the same tool is much, much larger than the difference in results for programmers of equal abilities using good and bad tools. The good tools are wasted on bad programmers, who find ways to write Visual Basic in any language. The bad tools are the source of frustration for good programmers, who waste time and energy "greenspunning" the bad tools into passable tools.
So I am not saying that (good programmer, bad tool) == (good programmer, good tool). I am saying that:
(good programmer, any tool) - (bad programmer, same tool) >
(any programmer, good tool) - (same programmer, bad tool)
So it is to your advantage to combine good programmers with the best tools available to them. It is always possible to cause a project to fail by selecting bad tools. There is still a difference in result between a good programmer with a good tools and a good programmer with a bad tool. Just because it is a much smaller difference than the difference between good and bad programmers doesn't change the fact that there is a difference.
As Paul Graham and Assaf have pointed out, tool selection strongly drives your ability to attract and retain good programmers. So while in theory you may be able to combine good programmers with bad tools, in practice you may have programmers who are experts in buzzword obfuscation and UML refactoring, but they are not competent in actual programming.
Some "bad" tools have such fatal flaws that it is unrealistic to expect even talented teams to overcome the weaknesses in the tool. In that case my expectation is that a good programmer will fail just like a bad programmer, but the good programmer will alert you to the tool's weaknesses much earlier than a bad programmer, perhaps in the exit interview. Good luck with any project where your best people quit because of poor tools, management, or working conditions.
Finally, in some situations management does not restrict themselves to only prescribing a poor tool but compounds the error by proscribing effective use of the poor tool. In plain English, they don't just force their "A" programmers to use a "C" programming language, but they tell them to write software that they think a "C" would be comfortable maintaining.
(Aside: The usual intent is to "make the code easy to read and maintain." But the measure of "easy to read and maintain" is wrongly "would an inexperienced programmer write the code this way." This is not the same thing as "would an inexperienced but motivated programmer be able to study this code, learn from this code, understand this code, and then maintain this code.")
There is a much larger difference between good programmers using good tools and good programmers forced to use bad tools and bad programming practices. There is some debate as to whether my assertion holds for this "worst case scenario" (such organizations often go for broke, treating the Joel Test as a golf score and do things like demand that their programmers wear ties or refrain from using the Internet).
It may be that the formula becomes:
(good programmer, good tool) - (bad programmer, good tool) >
(good programmer, good tool) - (good programmer, bad tool+bad practices) >
(bad programmer, good tool) - (bad programmer, bad tool+bad practices)
Reg, I don't get the connection to the Wasabi DSL!?
The title was actually snarfed from Guy Kawasaki, who wrote this aphorism approximately twenty years ago. It may be traditional Japanese wisdom. Then again, it may not.
Reg, not everyone can hire the top 1%, 5%, 10%, or even 50% of all developers. So isn't your simplistic "hire great developers" suggestion broken?
(Make that four questions and answers)
You know, this kind of question reminds me why I'm prejudiced in favour of working for CEOs that have a background in competitive fields like sales or competitive team sports like Soccer.
In sales, nobody abandons the idea of hiring good salespeople because "not everyone can hire the top salespeople." Imagine being appointed coach of an Ultimate team. Do you abandon the idea of recruiting the most gifted athletes you can find because every team ought to be able to do the same thing and therefore you will have to settle for average players?
No, obviously not. There can only be one top company. There can only be one championship team. To win in a competitive arena, you have to have better people, and better strategy, and you have to out-execute your competitors. Your goal is to be the one company, to be the one team.
Of course your strategy won't work for everyone, it won't work if everybody tries it. By definition, in a competitive (or "zero-sum") game there is no strategy that can help every player win.
That's ok, you are not interested in World Peace, in every company providing nice working conditions and good management for programmers. You are ruthlessly attempting to beat those companies into oblivion. You want them closed, bankrupt. If they have any talented programmers you want to hire those programmers away from them and put them to work building your dream while their former employers mumble platitudes about "methodologies that produce great results from mediocre people".
Consultants can wander around selling utopian visions of methodologies that work for every company and every programmer, no matter how inexperienced or incapable. Language and tool vendors can spend billions convincing everyone that their silver bullet eliminates all of the bugs that cause projects to fail. IDE mavens can tout the code generation and auto-completion bells and whistles that will give every programmer, no matter how mundanely talented, the productivity of a wizard.
These people have a vested interest in maintaining the illusion that software development is a positive sum game where everyone can win, where every project can succeed, where every product will make money.
But if you are working in a start up where you have to compete for talent, compete for funding, and compete for business success, you do not care whether your strategy can work for 100% of the projects in the world. You care whether it works for just one project, yours.
If you are working on an internal project where you compete with the prospect of your work being outsourced, where you compete for funding with other projects, where you compete for executive mind share, you do not care whether your strategy can work for 100% of the projects in the world. You care whether it works for just one project, yours.
Honestly, what matters to me is how I manage my own projects.
post scriptum: Not everyone wants to be the top salesperson, some people play competitive sports for the camaraderie, not to win, and some people go to work for the purpose of collecting nothing more than a pay cheque. If this describes you, you may find a kindred spirit in the "Angry Aussie": In praise of an average career.
Labels: agile
Comments on “Three questions and three answers about Wasabi and Rotten Fish”:
<< Home
I've seen a new "good tools" pattern about one year ago: a fair pile of famous tools jar without any rational use. Four or so graphic widgets sets, two container things, three XML parsers (not counting the one in the JDK).
I think this is another aspect of your point: tools won't save you and neither will tool accumulation.
I think this is another aspect of your point: tools won't save you and neither will tool accumulation.
# posted by 
: 4:14 AM
: 4:14 AM
I'm glad you liked my post. As a little clarification, I'm a strong believer in aiming for your personal best. I just think that by definition only a tiny number of people are going to be the best of the best so we shouldn't tie ourselves in knots trying to be the absolute number 1.
<< Home
