IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Let's start again.
The existing thread seems to be going off-tangent in a bad way.

Someone has just gotten the 6 Sigma religion and decides to apply it to the development of the new software. They define the development process, establish quality gates, count defects, produce statistics. But they're counting defects in the software. The software isn't the product, it's the tool.


Can you elaborate a bit more, without telling too much of course?

I assume the software supports the business ("the 'product' is actually a new process"), and the software isn't shrinkwrap that is shipped to customers.

In my other comments in this thread, cites have indicated that 6σ can be applied to software or any process that can be measured and improved. I get the impression that you feel that in the present case, applying 6σ to this software development isn't going to improve the software because the customers have no impact on the process.

In other words, is the problem that there's a disconnect between what the customers want and what the 6σ process is trying to optimize? Or is it your belief that the "new process" is not amenable to 6σ optimization techniques? Or is it something else?

My impression is:
1) 6σ can be applied to the development of new software that supports the customers.
2) The ideas behind 6σ and TQM and so forth can be applied to the development of a new business process, but measuring bug rates in the support software is only a tiny part of the problem.
3) Without a clear understanding of the overall business goal and the benefits and limitations of 6σ by those attempting to manage the process, they won't acheive their goals.

It's like that old [link|http://www.edn.com/article/CA601846.html|software development mantra]:

British computing pioneer Sir Tony Hoare once wrote: "Premature optimization is the root of all evil." Unfortunately, engineers often take this phrase out of context and use it to justify avoiding any thought of optimization or even plans to optimize in their code.

Charles Cook succinctly explains the problem with this approach: "The full version of the quote is 'We should forget about small efficiencies\ufffdsay, about 97% of the time: Premature optimization is the root of all evil,' and I agree. It's usually not worth spending a lot of time micro-optimizing code before it's obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems. An inexperienced developer will not bother, misguidedly believing that a bit of fine-tuning at a later stage will fix any problems."

The key point here is that inexperienced developers often write code without any consideration of the performance of their code. Unfortunately, system design without any concerns about performance rarely produces systems that perform well without major rewriting. The only thing worse than premature optimization is designing a system without any consideration of system performance. The assumption that 20% of a program's code accounts for 80% of its execution time has been the downfall of many designs.


Here, I suppose we could change it to, "Premature 6σ is the root of all evil." ;-)

Thanks.

Cheers,
Scott.
New Your point #2 is pretty much my whole point
The ideas behind 6σ and TQM and so forth can be applied to the development of a new business process, but measuring bug rates in the support software is only a tiny part of the problem.
I never suggested that you shouldn't count bugs. The whole problem is that I see lots of "6σ Black Belts" who think that all they have to do is show increased numbers of test cases, and decreased defects, and everything is A-OK. The question of whether the entire process is "pointed in the right direction" doesn't enter into their calculations.
     When 6 Sigma doesn't apply to IT projects - (dbishop) - (16)
         Well, on the flipside of this... - (folkert)
         Don't knock it quite so quickly - (ben_tilly) - (12)
             Answering both you and Greg - (dbishop) - (11)
                 That's not my understanding. - (Another Scott) - (2)
                     I didn't say there's no place for it - (dbishop) - (1)
                         Good points. -NT - (Another Scott)
                 Measure what you want to improve - (ben_tilly) - (7)
                     And that should be cost or revenue - (dbishop) - (4)
                         As I recall, at IBM, peer code reviews to catch - (a6l6e6x)
                         You misremember that article - (ben_tilly) - (2)
                             Do you think everyone not you is stupid? - (dbishop) - (1)
                                 No. Only when they ignore important stuff. - (ben_tilly)
                     Many elements of software development are stochastic - (dws) - (1)
                         One must keep balance. - (ben_tilly)
         Let's start again. - (Another Scott) - (1)
             Your point #2 is pretty much my whole point - (dbishop)

*plonk*
146 ms