Thursday, May 31, 2007

More on the limitations on processes...

A few days ago, I cribbed about the process for process sake. More today...

After CMM, I heard 6 Sigma is the next buzz word for consulting companies in India. The idea is to ensure quality with a process that can be repeated. My view is that this suits the hardware industry a lot more than software industry. And I strongly believe that Indian software industry uses it as a marketing feature. How else can you explain the extended working hours of employees and delayed projects? Shouldn't quality of work reflect in quality of life?

For comparison purposes, I would split the car or other hardware manufacturing into two main functionalities - design and production. My understanding was, a process definition and practice would address quality concerns in manufacturing more than in design or inventive thinking. But when it comes to software, it is hard to separate the software like that. Design of software continues to flow into the lines of code and the underlying framework and OS. It is virtually impossible to ensure repeatability as the problem each software tries address may be different. The solutions can also be different even if the problem remains the same. A single smart developer can offer 3-4 solutions to a fairly trivial problem.

If you want to ensure quality honestly and not marketing sake, you would probably look at the theory of program proving and such sources instead of software engineering. Since the current set of processes are defined by Managers who were engineers, it is not likely that they would look at pure Mathematics for quality.

The US software industry is probably better off with more people with in-depth understanding of the science of programming. A well written program from MS or Sun can be a good sample in teaching programming. I am not referring to the hodge podge of programs MS includes in the tutorials and samples shipped with .NET and other libraries.

In spite of better designs and processes, there is often a divide between the customer facing product management and the technology groups in many companies. Surprisingly the designs and processes which were solutions at one time are parts of a problem at a later date. More on this and TRIZ later....

No comments: