Slashdot Mirror

Just worked on a project using LEAN. What we would do is let all developers deliver the same prototype. At the end we evaluate each one, pick the best and move on. In diverse projects, different developers will excel in different areas. This was one way we could quickly see who is strong in which areas making later task assignments easier - especially when you are done with prototyping and now need to add all the other functional requirements. This sounds very similar...

No, it is not. Not by a long shot. You are missing the entire point and essence of that practice.

The author of that ill-advising article is suggesting small businesses to hire three independent programmers (none of them working in collaboration, but in competition, and thus, not necessarily acting with anyone else interest in mind), and somehow be technically capable of evaluating which is the best (and only one to pick up.)

Yeah right.

The lean approach you are suggesting entails pitting ideas and designs for later evaluation by a team of colleagues. Yes, one design gets picked up as the primary contender. But chances are that other ideas from the other designs will be picked up and integrated to the final design as well. If this integration of ideas does not take place, and the only thing being done is to take a winner to the exclusivity of the other designs (which is what will happen with what the blog author is suggesting), then you are doing something wrong. That's not engineering.

Just worked on a project using LEAN. What we would do is let all developers deliver the same prototype. At the end we evaluate each one, pick the best and move on. In diverse projects, different developers will excel in different areas. This was one way we could quickly see who is strong in which areas making later task assignments easier - especially when you are done with prototyping and now need to add all the other functional requirements. This sounds very similar...

You have a point. "Motivations" such as this can actually hurt morale and lead to in-fighting and nasty politics. Mary Poppendieck wrote a great essay on this subject [Warning: PDF]. It's more geared towards corporate environments but a lot of the same principles still apply.

"I'd love to do this in Linux"

STOP: You're failing already.

Don't project your wishes onto the solution space. F'er example, WTF is wrong with their DVD soln?

You _don't_ know!

Because you've not captured the GOALS and mapped them into REQUIREMENTS, framed by CONSTRAINTS. Then, and only then, start thinking of possible SOLUTION ARCHITECTURES.

And first, make sure you don't have a wicked problem. (See http://www.poppendieck.com/wicked.htm)

• Lean Software Development
• Implementing Lean Software Development

I personally really related to these, as I'm a software guy with a Mechanical Engineering degree...

• Lean Software Development
• Implementing Lean Software Development

I personally really related to these, as I'm a software guy with a Mechanical Engineering degree...

I've found this only works if you have a client who doesn't want to force you into a fixed bid contract.

After a lot of years developing software, I have never even heard of a fixed bid software job where everybody ended up happy. Every one I have seen up close has ended up with at least one side feeling like they got screwed, and generally both sides feel that way.

The good news is that there are other options. This book has some great options for software development contracts that work in an Agile context.

There are pitfalls to using purely monetary compensation as a motivating factor.

The question of client value is one that has been ignored up until very recently, with areas like interaction design, and Agile methodologies incorporating client needs and goals into the day to day programming work. It comes down to this - only do what work has obvious value to the customer . The only question for these standardizers is : what value does this peice of work have? I would purport that standarizing on a language across multiple disparate teams for it's own sake has no value. So whats the reason these people have for wasting company time and money? Are they backed up in their claims by metrics, prior experience of a successful changeover, or published works backing them up? OR are they, as I would assume, going with a bad idea through lack of imagination? Trollish as it may sound, lack of imagination in people who have big ideas is a bigger problem than people realise. Those who come to the idea first, and quickly, are those who are most unwilling to change (src: http://www.poppendieck.com/ Lean development techniques). It is exactly these types of personality which graduate towards management positions, pushing bad ideas until they are proven irrevocably wrong. Who are they anyway? Are they programmers themselves? (in which case I'd be inclined to dismiss their opinion on the basis they are naturally biased to one language anyway) or are they managers? (in which case I'd be inclined to dismiss their opinion on the basis they don't know what they're talking about)

http://www.poppendieck.com/construction.htm

Modern project management is an exercise in managing uncertainty.

More precisely, it's an exercise in managing risk. Developing software involves all sorts of monetary risk, including real costs and opportunity costs (i.e. doing x instead of y yields $10,000 less money). Generally, uncertainty is the biggest contributor to the total risk.

Joel's painless scheduling is a step in the right direction for estimating and learning from previous estimates.

Comparing software to construction is helpful. Construction projects are not as lean as people think, and they sure seem a lot like software projects, when it comes to risk. The best things to learn include several, varied-length schedules (i.e. a daily schedule set at the beginning of the day, a 3-week schedule that is reviewed often, and a long-term schedule). Also, regularity in scheduling is an amazingly helpful habit. Regularly-scheduled builds, regular releases, regular fixing helps estimation and provides incentives for progress and scaling back the impossible. That all helps minimize risk.

I know a great deal about software design; it is what I do for a living. Management likes to think like you do, because it simplifies their view of things - they do not understand software development, so they feel the need to equate it to something that they think they understand. Then they make decisions based on a flawed world view.

Which is not to say that programmers cannot learn some things from other industries - see here for an interesting discussion of this.

This thread is turning out better than some others about Extreme Programming, like here and here.

I worked on a project that used XP for most of 2001. It was a liberating experience. We had two domain experts who also acted as XP coaches, which helped a lot. Our biggest problem was convincing some team members to suspend their disbelief long enough to give the XP practices a chance. At the end, we found we were about 50% more productive than similar, non-XP projects, despite spending a lot of time cutting excess code out of the project. About 20% of the source code was devoted to unit tests and mock objects to support the tests.

When budget-cutting forced us to halt development abruptly, we had 12 known bugs. 11 of them were GUI problems, which we could not easily unit test. We had 70-80% unit test coverage, most of it written under the mantra "write the test, then the code." This turned out to be a key factor in our code quality.

Having all those unit tests in an automated test framework gave us tremendous confidence to keep moving forward. This leads to the other key factor TDD provides a project: freedom from fear. Why worry about failing the regression tests at the next code freeze when you can run them every hour?

Our XP project convinced me that one big reason for quality problems in C-language software is the lack of automated unit test tools. Sorry, that's just another good reason to move to OO, even for embedded systems.

TDD is still valuable without the other XP practices. Short development iterations also deserve wider use outside XP.

For all the naysayers... Look, nobody is saying you have to abandon experience, judgement or common sense to use XP. What you have to do is immerse yourself in the experience -- add the flow of programming the XP way to the other tools on your belt. XP is a little harder than riding a bicycle, definitely easier than Tuvan throatsinging, and as hard to describe on the printed page as both.

That said, Kent Beck's testing book is pretty thin. It adds very little to what you'd get from reading Extreme Programming Explained plus the JUnit tutorial. To understand why people "get religion" about TDD, understand why people are religious about the most effective ways to get software development done. Two views that come to the same place from vastly different starting points are Alistair Cockburn's excellent book, Agile Software Development , and the "lean software development" material at Mary Poppendieck's website.