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....

Monday, May 28, 2007

US techies 10-times more productive than Indian

US techies 10-times more productive than Indian
If the above link didn't work, here is the gist:
Wipro's earnings is $50K per employee while top US IT companies make close to a million dollars per employee.

First some questions:
  • What is the ratio of expenses vs income per employee in the US and India? There may not be such a big difference in this criteria.
  • When talking about IBM, Dell etc., does the statistics include their operations in India and other countries or not?
  • Does the statistics include the contract workers or consultants for US companies?
  • Would American companies have the same efficiency if the cost of outsourcing increases?

I am fine with Indian companies generating less revenue per employee as Indian companies contribute a lot toward employment and overall spread of wealth.

Thursday, May 24, 2007

Process, People and Innovations

In Indian software industry context, ISO, CMM have been the buzz words. They were used by the consulting companies to score a marketing point and in the process, also brought in some organized way of working. I am not a big fan of process for process sake and I'm going to bitch about it in this blog.

Way back in 1995, when I worked for a relatively small consulting company in Mumbai, I was asked to write the test plan after I finished all the development work. There were two problems: 1. Usually developers are not the owners for test plans and 2. We were making a mockery of the process by writing the plan when the product was about to be launched. When I protested, my boss said that the organization is going for an ISO certification and it has to be done. Better late than never was his argument. I didn't argue further and complied. But that gave an idea on what process and quality mean to people.

When I was in US, consulting for a number of companies, there were hardly any documentation. Process was there, but was very subtle. Check-in comments and notifications, code reviews were all followed not for the sake of them, but as a standard practice.

After I returned to India, I worked for one of the top 5 consulting companies in India and faced a lot of documentation for the sake of ... documentation. I hated the work. The Manager was not a fan of efficiency or brilliance in software design and development, but liked to define useless processes on and on. I quit the company within 6 months and joined a start up and started implementing simple processes - like reviews and simple plans that could be followed.

In the past few years I come across a number of candidates who have experience in CMM Level 5 companies and know nothing about innovation. They are rendered as the next generation of sophisticated clerks by the respective organizations. British rule left us with systems that were designed to suspect people supported by processes run by clerks. CMM rule is doing the same to our Engineers killing any innovation. I doubt whether a piece of the process was designed to fix a problem after it was "experienced". Processes are blind following of rules defined by impractical Managers, copied from one organization to the other. They generate loads of documents that no one reads after the first month.

To be continued...

Thursday, May 10, 2007

Giving up on Microsoft

Giving up on Microsoft

Like Jeff and Mike, I started programming with MSC 6 and used almost every version of developer tools from MS, including MFC, ATL and a console based editor called PWB for Programmer Work Bench (I would like to call it a People's Work Bench for its simplicity and utility). At times, I strayed into Open source for more practical solutions. For our organization, we chose Linux based server apps like Samba domain controller, Postfix / Sendmail mail servers and portals based on Liferay. We had time to play around with these and weren't willing spend money on Windows and Exchange servers. I chose Lucene on .NET over full text search as we needed search to work remotely. And Lucene seemed to be a lot more fun to develop than FTS. But I would always choose the developer tools from MS over Open Source tools. Even if Eclipse offers a plug-in for C#, I would consider the express editions of C#/ASP.NET a lot easier to use if cost is a factor. If I have the luxury of spending a few thousand dollars, I will always choose MS developer tools.

At one stage in my career I wanted to work for MS. And within a few months after I was rejected, I was scared of competition from MS as they could build a better product faster and market it easier as compared to the product I was working on. From time-to-time, I might choose between MS and Open Source, but I can't hate either.

For those who choose one and hate the other, don't blame it on MS or Open Source. Blame it on your upbringing that doesn't allow you to stay in shades of gray but expects you choose between black or white.