If indeed human activity is causing global warming, then we can solve this problem inteligently or stupidly. The intelligent solution starts with nuclear power.
No, the intelligent solution is to tax carbon and let individuals figure out the best way to get emissions back in line. Fission power seems like the obvious choice on a simple analysis, but economic considerations (like insurance costs and waste disposal costs) make it a much more dubious proposition over the long haul.
The fact is that we don't know the right answer yet. Soviet-style industrial planning didn't work particularly well for them, so I'm not seeing why we should adopt it here.
Yes! These so-called "analogies" frighten and confuse me. All words should be restricted to their narrow, original, literal meanings. I demand we return to speaking Proto-Indo-European so that we can be sure all these hideous neologisms are banished forever.
Sure, when dealing with clients face to face it's important, but otherwise it doesn't matter.
A friend of mine is that rarity, a well-dress geek. When he got loaned to a sales team as a technical expert, they asked him to dress down for meetings so that the clients would trust him more.
Correct me if I am wrong, I don't think any of the tools that you mentioned can generate any intelligent comment.
You are absolutely right. When reviewing code bases or taking on code from other developers, comments like this are worse then useless. I can already see the exception declaration right there. And since the programmers are used to ignoring the useless auto-generated comments, when they change the code they just blow on by the comment, taking it from useless to actively misleading.
I think you can generate nice documentation from information embedded in the code; JavaDoc proves that well. But generating comments in the code from data in the code is just retarded; the only problem it solves is a gotta-have-comments checklist item.
And the original poster should consider the benefits of something nearly that loose.
Don't arbitrarily set up standards. Ask people what problems they have. Tell people what problems you're facing (e.g., you need to be able to move people more easily between projects). Then ask the developers who don't have those problems what they do. Feel free to toss in your own suggestions, too. But let them talk first. And let the developers decide how to do the work as long as they address your needs.
Remember that you're not working in some Taylorist 1930s factory where you have to specify every motion. Creative work, which is what your developers are doing, is utterly different than factory work. (See the book Artful Making for more info on that.) Treat them like professionals and they'll act like professionals.
As the head of sales of one of the largest PM training companies in the world, I was interested in this book. Upon reading this chapter however, all I can say is... what crap!
So let me get this straight.
Your job isn't to get things done, or to run projects yourself. Instead, your job is to convince people that they can't get their shit together on their own, and so they need lots and lots of help from your company. Which, apparently doesn't actually do anything either, instead making a living telling people how to do things that you guys don't do yourselves.
And you're telling us that this book is terrible? That alone is enough to get me to buy a copy. Given what I've seen PMI-trained people do to perfectly good software projects, anything that a PMI training marketroid is so deeply opposed to must have some good in it somewhere.
The PMBOK is geared to the construction field, so there's a lot of stuff there that us IT people don't need.
Excellent point. People who draw construction analogies seem to miss that in software development we spend most of our time on what people who make buildings think of as design. The proper software development analogy for construction isn't coding; it's what happens after we type "make".
The way to make this happen is to offer something more than credit in return. If you are going to collect a lot of data on an application, you'll have the opportunity to give them some cool reports about where the bottlenecks are. Offer the reports in exchange for the data. Sure, they *could* make the reports themselves, but most places never do.
If you can't get in on your own, convince some important vendor (e.g., IBM's Websphere group) that you're legit and can help them if they'll help you.
And if nobody bites on the "we'll give you reports for free" thing, then charge them $30k for your reports or $20k if they let you reuse the anonymized data in your research. You'll need a business listing and a sales guy with a nice suit to pull this off, but I promise that it will work, especially if you let the sales guy keep all the money.
Becaused they won't implement the simple policy of extending an auction based on most recent bid (a very simple solution to the problem of sniping, and one that would be an elegant, simple, and beneficial solution to eveyrone), sniping is now 'de rigeur' for any auction.
Have they ever said why they won't do that? I've always wondered.
If code works right 95% of the time on the first try, that is a sacrifice they are willing to make.
That may be a possible choice with traditional QA testing (which you do right at the end), but that's not the notion with unit testing. I don't write tests to increase quality as such; I write them to increase my development speed. If the code usually works, I spend very little time debugging. When I do make mistakes, the test coverage means I generally find out right away about bugs, so the problems are easy to find. And when I'm doing new work, the existing suite reminds me of all the little details that went into the existing code base, meaning I have to spend a lot less time on design archeology before ading new features.
I don't do test-driven development just for better quality. I do it because it helps me go faster, and with less stress to boot.
I figured this out after my first project got too big. Am I missing something here?
It endlessly amuses me that the two main first reactions to XP are
That's completely impossible, unheard of, and unworkable. You people are frothing lunatics.
That's completely obvious, reasonable, and effective. We were doing that thirty years ago. You people are scam artists for trying to pass it off as a new method.
I don't know why groups never talk to one another, but I sure wish they would.
Agile development is about working with the customer, giving them something to see and test and provide feedback on as quickly as possible. Instead of giving them crap they don't want in a week like XP, give them a basic test in 2 days, and then refine it to be what they want over the rest of the week.
That's how my XP experiences go. Weekly iterations are there to force everybody to come together at least once a week. But the product manager is sitting with the developers, so on all the teams I've seen, they spend a lot more time talking. Typically my team will check in with the product manager after every few hours of work on a feature.
At the end of 6 months the business user discovered that we had built something he didn't want. Big-design-up-front still has its place.
One of the XP practices is frequent releases. How many releases did you have?
Another practice is the on-site product manager. Was the business user in the room with the developers?
Assuming you were doing weekly iterations, your business use has 26 opportunities to see that the product wasn't the right one. How would more up-front design have helped them see that sooner?
There is no kinda doing XP, the creators of XP have always been very clear that you either blindly follow all their arbitrary rules, or you are not doing XP, and your bad results are your own fault for not doing XP.
That's patently false. I don't deny that there are some people who are fundies, but you get that with anything. The second edition of Extreme Programming Explained moved even farther from particular rules in the direction of broad principles, and on the Extreme Programming mailing lists you regularly see people like Ron Jeffries saying that the original 12 practices are where they'd like to see people start, but that local adaptation is an important part of it. When Kent Beck pops in, it's generally to argue against firm rules in general.
applications that are a constantly moving target "this would be cool to have"
XP's planning practices pull out the most important and most stable features and work on those first. Because XP only works on things an iteration at a time, most of that which is moving is not part of the target. The product managers get to go off and argue while the developers get on with this week's features.
Also, by having a new version ready every week (if not more often) risky features can be tried out easily. A little real-world experience helps settle arguments and clear up confusion that is behind moving targets.
Sometimes, though, the target does move. When that happens, you change the tests to the new target and then make them pass.
applications where the moving-targetness lies in the presentation
Well, most of your tests should be below the presentation layer, so it's not a huge deal. For some presentation layer changes, you just change the tests and make 'em pass. But if that happens a lot, then I like to go for some data-driven presentation system. E.g., a content management system or a skins system. Then you test that the tools work and that the copywriters and skin designers can't crash the app, but you don't test each little UI change anymore.
some customers bitch about any change in presentation
This is not a software development problem; it's a business problem. XP is just about software development.
applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data.".
This happens to me occasionally, but it's pretty rare. It's a sign that we missed a case in the unit tests. When that happens, we add the case and make things pass. Since the tests are run on every checkin, the case never is a problem again.
Also, XP teams should take any real-world bug as a lesson in process improvement. One place where I had a problem with weird data we created a pruned copy of the messy production databases and ran our whole test suite against that nightly. Not only did that keep us from a lot of bugs in production, but it also showed us where the original team had been sloppy checking inputs, and so we added some tests to make sure garbage data from getting saved anymore.
[...] if management itself is unwilling to live by its own rules I can guarantee you the programming staff won't either
Strongly agreed!
Generally speaking, things like Scrum will only work in larger organizations where a top-down policy can be enforced.
My experience is just the opposite. I've had the most luck with XP in smaller companies. Why? Because XP provides a number of feedback mechanisms to get people to behave sensibly. In small companies, people can see it working. But in big companies the people with the power are often so far from any contact with business realities that theory, politics, and ignorance can override behaviors that are obviously sensible to the teams doing the work.
If you seem to have more time its only because you have not spent it on quality.
I disagree, for two reasons.
Time saved can come through reduced waste. Short-cycle iterative methods like XP and Scrum help keep expectations in line with reality. This reduces last-minute panics where something 80% complete is removed to get the product out the door. Also, the availability of early releases lets people see earlier that particular features should be dropped or changed, reducing the amount of wasted effort.
Improved quality saves time. I've done my last few products test-first, where I write test code before production code. This helps make my bug rates very low (well under one production bug per developer-month), meaning practially zero time spent in bug fixes. These days I average perhaps five minutes a day using the debugger.
And really, this is something that's obvious in a lot of other professions. "Measure twice, cut once," is a long-established method for saving time through putting quality first. I'm glad that it's finally catching on in software.
Another great way to learn about your network is to install a packet sniffer like Ethereal. Capture some packets, pick a random one, and try to figure out what the hell it's for.
For the advanced version of the game, do something specific (bring a DHCP machine up; do an FTP transfer; surf a web site) and write down what you think goes on on the network. Then capture the packets and see how close you can get.
By learning what a network looks like when it's working normally, you'll have a much better chance of figuring out problems when they happen.
What is a patent? It is lending government's monopoly on the use of force. It is completely incompatible with freedom.
Well, I'd say that since it's a very, very limited grant of power, it is also a very, very mild loss of freedom. Most people want political freedom, but the freedom to manufacture a certain widget with a particular arrangement parts now rather than twenty years from now is not so popular.
But suppose you're right, suppose the patent is completely incompatible with your notion of freedom. Then what? Freedom isn't the only thing we value. We also value things like technological progress and rewarding artists for their work. If you want to persuade us to burn the whole patent system down you'll have to convince us that it's a better approach.
I've written two books that are "freely" copyable. In both I request $20 to acquire my official version and help motivate me to write more. Guess what? I get the money. Often. With the web, it is even easier to make money this way.
Well gosh. If you can get the occasional Jackson in the mail, that's good enough for me. In fact, where's your book? I'll make a copy but change it so the money comes to me. Or now that you've proven the market, perhaps I'll print up 10,000 paper copies and sell them through WalMart. Which you're cool with, right?
And sadly, your tale is not enough to convince an editor and an illustrator to work with me on my own book. Any suggestions for them? And any tips for my friend the inventor who needs $3 million to finish his R&D and do the first production run? Because it turns out the people he knows with that kind of money would want some assurance that a Chinese manufacturer won't buy the first one and then flood the market with knock-off copies and put my pal out of business.
It's not "impossible" to debug binary software. [...] What they actually mean is, "I don't really want to" [...]
Even if it only makes their lives harder rather than impossible, that's good enough for me. If having source they can review and work with means they can spend more time on things that they think are important, that's a win.
A stable binary module interface would help open source developers too [...] Take for instance ZeroInstall.
That doesn't seem like a persuasive case to me. A full binary kernel API seems too low-level to solve those problems. I think the better approach is to create specific higher-level APIs that enable developers to work. In the case of ZeroInstall, I notice that a user-space filesystem adapter is now in the kernel.
Re:disappointed -- try the java cert exam
on
Java Puzzlers
·
· Score: 1
When I ran across this exact puzzle in production code, except with 50 lines of complex ifs in the try block, my solution was both simple and effective: I beat the responsible programmer with a power cord until he promised to never, ever do that again.
This also depends on the size. Which I am just realising is what you ment by differenciating group and team. so, yah just argeeing with you there.
Partly; I think that it's impossible to get too large a group to cohere into a team. But there are many small groups that aren't teams as well. No collection of thirty fingers is a hand, but not all collections of five fingers act as a single hand, either.
One of the big problems with extreem programing (other that the name) is the lack of a team leader.
Yeah, I agree that the name is ridiculous. On the other hand, many fewer people paid attention to the ones with boring names, so perhaps it was necessary.
Having a formally designated single leader for everything is one way to make a team, but in my opinion it's not the best one. Look at a basketball team, for example. Neither the manager nor the coach is on the team, and leadership can change hands from moment to moment. I think your story isn't a failure of XP; I think it's a management failure or a coaching failure. I've happily had XP teams with multiple leaders.
The XP way to deal with people whose ambition exceeds there sense is to give them enough rope so that they find out the painful truth, but not so much that they bring the team down. I coached one team where one of the members would regularly get excited about particular design ideas and would push hard for them. The solution was that for each one he had to propose an experiment where for some upcoming feature he'd lead us in trying the technique in a limited area of the code. Only if everybody liked the results would they introduce it more broadly. A couple were really good ideas; several weren't. The first category taught the team to listen to him a bit more, and the work of the process plus the failures taught him to distinguish carefully between merely interesting ideas and ones that really worked for our project. Everybody won, with no need for a formal leader.
Slashdot Mirror
If indeed human activity is causing global warming, then we can solve this problem inteligently or stupidly. The intelligent solution starts with nuclear power.
No, the intelligent solution is to tax carbon and let individuals figure out the best way to get emissions back in line. Fission power seems like the obvious choice on a simple analysis, but economic considerations (like insurance costs and waste disposal costs) make it a much more dubious proposition over the long haul.
The fact is that we don't know the right answer yet. Soviet-style industrial planning didn't work particularly well for them, so I'm not seeing why we should adopt it here.
So what if we are exitinct? Who cares?
After you, pal.
Yes! These so-called "analogies" frighten and confuse me. All words should be restricted to their narrow, original, literal meanings. I demand we return to speaking Proto-Indo-European so that we can be sure all these hideous neologisms are banished forever.
Sure, when dealing with clients face to face it's important, but otherwise it doesn't matter.
A friend of mine is that rarity, a well-dress geek. When he got loaned to a sales team as a technical expert, they asked him to dress down for meetings so that the clients would trust him more.
Correct me if I am wrong, I don't think any of the tools that you mentioned can generate any intelligent comment.
You are absolutely right. When reviewing code bases or taking on code from other developers, comments like this are worse then useless. I can already see the exception declaration right there. And since the programmers are used to ignoring the useless auto-generated comments, when they change the code they just blow on by the comment, taking it from useless to actively misleading.
I think you can generate nice documentation from information embedded in the code; JavaDoc proves that well. But generating comments in the code from data in the code is just retarded; the only problem it solves is a gotta-have-comments checklist item.
And the original poster should consider the benefits of something nearly that loose.
Don't arbitrarily set up standards. Ask people what problems they have. Tell people what problems you're facing (e.g., you need to be able to move people more easily between projects). Then ask the developers who don't have those problems what they do. Feel free to toss in your own suggestions, too. But let them talk first. And let the developers decide how to do the work as long as they address your needs.
Remember that you're not working in some Taylorist 1930s factory where you have to specify every motion. Creative work, which is what your developers are doing, is utterly different than factory work. (See the book Artful Making for more info on that.) Treat them like professionals and they'll act like professionals.
As the head of sales of one of the largest PM training companies in the world, I was interested in this book. Upon reading this chapter however, all I can say is ... what crap!
So let me get this straight.
Your job isn't to get things done, or to run projects yourself. Instead, your job is to convince people that they can't get their shit together on their own, and so they need lots and lots of help from your company. Which, apparently doesn't actually do anything either, instead making a living telling people how to do things that you guys don't do yourselves.
And you're telling us that this book is terrible? That alone is enough to get me to buy a copy. Given what I've seen PMI-trained people do to perfectly good software projects, anything that a PMI training marketroid is so deeply opposed to must have some good in it somewhere.
The PMBOK is geared to the construction field, so there's a lot of stuff there that us IT people don't need.
Excellent point. People who draw construction analogies seem to miss that in software development we spend most of our time on what people who make buildings think of as design. The proper software development analogy for construction isn't coding; it's what happens after we type "make".
The way to make this happen is to offer something more than credit in return. If you are going to collect a lot of data on an application, you'll have the opportunity to give them some cool reports about where the bottlenecks are. Offer the reports in exchange for the data. Sure, they *could* make the reports themselves, but most places never do.
If you can't get in on your own, convince some important vendor (e.g., IBM's Websphere group) that you're legit and can help them if they'll help you.
And if nobody bites on the "we'll give you reports for free" thing, then charge them $30k for your reports or $20k if they let you reuse the anonymized data in your research. You'll need a business listing and a sales guy with a nice suit to pull this off, but I promise that it will work, especially if you let the sales guy keep all the money.
Becaused they won't implement the simple policy of extending an auction based on most recent bid (a very simple solution to the problem of sniping, and one that would be an elegant, simple, and beneficial solution to eveyrone), sniping is now 'de rigeur' for any auction.
Have they ever said why they won't do that? I've always wondered.
If code works right 95% of the time on the first try, that is a sacrifice they are willing to make.
That may be a possible choice with traditional QA testing (which you do right at the end), but that's not the notion with unit testing. I don't write tests to increase quality as such; I write them to increase my development speed. If the code usually works, I spend very little time debugging. When I do make mistakes, the test coverage means I generally find out right away about bugs, so the problems are easy to find. And when I'm doing new work, the existing suite reminds me of all the little details that went into the existing code base, meaning I have to spend a lot less time on design archeology before ading new features.
I don't do test-driven development just for better quality. I do it because it helps me go faster, and with less stress to boot.
It endlessly amuses me that the two main first reactions to XP are
I don't know why groups never talk to one another, but I sure wish they would.
Agile development is about working with the customer, giving them something to see and test and provide feedback on as quickly as possible. Instead of giving them crap they don't want in a week like XP, give them a basic test in 2 days, and then refine it to be what they want over the rest of the week.
That's how my XP experiences go. Weekly iterations are there to force everybody to come together at least once a week. But the product manager is sitting with the developers, so on all the teams I've seen, they spend a lot more time talking. Typically my team will check in with the product manager after every few hours of work on a feature.
At the end of 6 months the business user discovered that we had built something he didn't want. Big-design-up-front still has its place.
One of the XP practices is frequent releases. How many releases did you have?
Another practice is the on-site product manager. Was the business user in the room with the developers?
Assuming you were doing weekly iterations, your business use has 26 opportunities to see that the product wasn't the right one. How would more up-front design have helped them see that sooner?
There is no kinda doing XP, the creators of XP have always been very clear that you either blindly follow all their arbitrary rules, or you are not doing XP, and your bad results are your own fault for not doing XP.
That's patently false. I don't deny that there are some people who are fundies, but you get that with anything. The second edition of Extreme Programming Explained moved even farther from particular rules in the direction of broad principles, and on the Extreme Programming mailing lists you regularly see people like Ron Jeffries saying that the original 12 practices are where they'd like to see people start, but that local adaptation is an important part of it. When Kent Beck pops in, it's generally to argue against firm rules in general.
applications that are a constantly moving target "this would be cool to have"
XP's planning practices pull out the most important and most stable features and work on those first. Because XP only works on things an iteration at a time, most of that which is moving is not part of the target. The product managers get to go off and argue while the developers get on with this week's features.
Also, by having a new version ready every week (if not more often) risky features can be tried out easily. A little real-world experience helps settle arguments and clear up confusion that is behind moving targets.
Sometimes, though, the target does move. When that happens, you change the tests to the new target and then make them pass.
applications where the moving-targetness lies in the presentation
Well, most of your tests should be below the presentation layer, so it's not a huge deal. For some presentation layer changes, you just change the tests and make 'em pass. But if that happens a lot, then I like to go for some data-driven presentation system. E.g., a content management system or a skins system. Then you test that the tools work and that the copywriters and skin designers can't crash the app, but you don't test each little UI change anymore.
some customers bitch about any change in presentation
This is not a software development problem; it's a business problem. XP is just about software development.
applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data.".
This happens to me occasionally, but it's pretty rare. It's a sign that we missed a case in the unit tests. When that happens, we add the case and make things pass. Since the tests are run on every checkin, the case never is a problem again.
Also, XP teams should take any real-world bug as a lesson in process improvement. One place where I had a problem with weird data we created a pruned copy of the messy production databases and ran our whole test suite against that nightly. Not only did that keep us from a lot of bugs in production, but it also showed us where the original team had been sloppy checking inputs, and so we added some tests to make sure garbage data from getting saved anymore.
[...] if management itself is unwilling to live by its own rules I can guarantee you the programming staff won't either
Strongly agreed!
Generally speaking, things like Scrum will only work in larger organizations where a top-down policy can be enforced.
My experience is just the opposite. I've had the most luck with XP in smaller companies. Why? Because XP provides a number of feedback mechanisms to get people to behave sensibly. In small companies, people can see it working. But in big companies the people with the power are often so far from any contact with business realities that theory, politics, and ignorance can override behaviors that are obviously sensible to the teams doing the work.
I disagree, for two reasons.
And really, this is something that's obvious in a lot of other professions. "Measure twice, cut once," is a long-established method for saving time through putting quality first. I'm glad that it's finally catching on in software.
Don't even get me started about my porn perferences ;)
Dude, that you perforate your porn is TMI.
Another great way to learn about your network is to install a packet sniffer like Ethereal. Capture some packets, pick a random one, and try to figure out what the hell it's for.
For the advanced version of the game, do something specific (bring a DHCP machine up; do an FTP transfer; surf a web site) and write down what you think goes on on the network. Then capture the packets and see how close you can get.
By learning what a network looks like when it's working normally, you'll have a much better chance of figuring out problems when they happen.
Remove "copy"-right and replace it with "profit"-[r]ight.
Dude, have you not heard of a Hollywood accountant?
What is a patent? It is lending government's monopoly on the use of force. It is completely incompatible with freedom.
Well, I'd say that since it's a very, very limited grant of power, it is also a very, very mild loss of freedom. Most people want political freedom, but the freedom to manufacture a certain widget with a particular arrangement parts now rather than twenty years from now is not so popular.
But suppose you're right, suppose the patent is completely incompatible with your notion of freedom. Then what? Freedom isn't the only thing we value. We also value things like technological progress and rewarding artists for their work. If you want to persuade us to burn the whole patent system down you'll have to convince us that it's a better approach.
I've written two books that are "freely" copyable. In both I request $20 to acquire my official version and help motivate me to write more. Guess what? I get the money. Often. With the web, it is even easier to make money this way.
Well gosh. If you can get the occasional Jackson in the mail, that's good enough for me. In fact, where's your book? I'll make a copy but change it so the money comes to me. Or now that you've proven the market, perhaps I'll print up 10,000 paper copies and sell them through WalMart. Which you're cool with, right?
And sadly, your tale is not enough to convince an editor and an illustrator to work with me on my own book. Any suggestions for them? And any tips for my friend the inventor who needs $3 million to finish his R&D and do the first production run? Because it turns out the people he knows with that kind of money would want some assurance that a Chinese manufacturer won't buy the first one and then flood the market with knock-off copies and put my pal out of business.
It's not "impossible" to debug binary software. [...] What they actually mean is, "I don't really want to" [...]
Even if it only makes their lives harder rather than impossible, that's good enough for me. If having source they can review and work with means they can spend more time on things that they think are important, that's a win.
A stable binary module interface would help open source developers too [...] Take for instance ZeroInstall.
That doesn't seem like a persuasive case to me. A full binary kernel API seems too low-level to solve those problems. I think the better approach is to create specific higher-level APIs that enable developers to work. In the case of ZeroInstall, I notice that a user-space filesystem adapter is now in the kernel.
When I ran across this exact puzzle in production code, except with 50 lines of complex ifs in the try block, my solution was both simple and effective: I beat the responsible programmer with a power cord until he promised to never, ever do that again.
This also depends on the size. Which I am just realising is what you ment by differenciating group and team. so, yah just argeeing with you there.
Partly; I think that it's impossible to get too large a group to cohere into a team. But there are many small groups that aren't teams as well. No collection of thirty fingers is a hand, but not all collections of five fingers act as a single hand, either.
One of the big problems with extreem programing (other that the name) is the lack of a team leader.
Yeah, I agree that the name is ridiculous. On the other hand, many fewer people paid attention to the ones with boring names, so perhaps it was necessary.
Having a formally designated single leader for everything is one way to make a team, but in my opinion it's not the best one. Look at a basketball team, for example. Neither the manager nor the coach is on the team, and leadership can change hands from moment to moment. I think your story isn't a failure of XP; I think it's a management failure or a coaching failure. I've happily had XP teams with multiple leaders.
The XP way to deal with people whose ambition exceeds there sense is to give them enough rope so that they find out the painful truth, but not so much that they bring the team down. I coached one team where one of the members would regularly get excited about particular design ideas and would push hard for them. The solution was that for each one he had to propose an experiment where for some upcoming feature he'd lead us in trying the technique in a limited area of the code. Only if everybody liked the results would they introduce it more broadly. A couple were really good ideas; several weren't. The first category taught the team to listen to him a bit more, and the work of the process plus the failures taught him to distinguish carefully between merely interesting ideas and ones that really worked for our project. Everybody won, with no need for a formal leader.