Commoditization of Software Engineering

As any practice matures, it’s practitioners try to find ways to drive up efficiency, quality and reduce risks and costs. Generally speaking, this leads to better and cheaper products. However, IT services companies seem to be taking this concept a bit too far.

Most tech organizations evolve processes that try to be predictable, cost effective and at the same time less dependent on people. The process relies more on roles such that any person can be cast into it. The processes warrant that people be replaceable since they aren’t predicable. The process maps software development into and assembly line.

Using such processes, companies reduce software engineering to a trade able commodity whose unit price is set in terms of a man-hour. Thus every IT service company can now be compared purely on the basis of it dollar rate per man hour.

But here’s why commoditization doesn’t work:

• How much you can accomplish in an hour is different for different people especially when most of that hour is spent thinking.
• Assembly lining is useful when you are mass producing the same goods again and again. In the case of software engineering, you are always building something new since you would have used the old thing had it existed.
• It sets-up an illusion of an all-things-being-equal state where your billing rate alone becomes your sole competitive advantage.

In addition to not working, here is how such processes can be harmful to software engineering:

Over specialization

The processes lead to creation of rigid roles - System Analyst, Architect, UI Designer, Coder, DBA, Tester, Support Guy, Maintenance Guy, etc.

No team member really knows every thing about the system. I have interviewed programmers with 3 years of experience and yet have no knowledge of databases since the DBA did the database stuff. Large projects may be divided vertically (functionally) but not horizontally (by phase). Each team member needs to know and work on an entire module across the phases. This is one place where the Unix philosophy of “Do one thing, do it well” just doesn’t work.

Loss of flexibility

When an over bearing process always forces you to negotiate with the DBA (who doesn’t understand what you do) whenever you want to make a change in the database structure, you loose flexibility. When this goes on long enough, you subconsciously loose the ability to innovate.

When a team is driven by a process rather than it’s people, what you are really saying is:
“I don’t have enough faith in you guys to trust your judgment. Hence you need to follow this process because it is predicable even though it might not be the best way to go about.”

Unfortunately, we have been trained from childhood to assume that anything based on mathematics is too left-brained and un-artistic. It’s important to realize that software engineering is a creative field because most of the time is spent thinking of ways to overcome problems, elegantly. And anything that is creative cannot be commoditized. If it could be done, wouldn’t there be Big Art Companies that employ full-time artists to sit in cubicles from 9-5, creating great works of art and billing their clients by the man-hour?

(3 votes, average: 3.67 out of 5)

 Loading ...

This entry was posted on Wednesday, November 22nd, 2006 at 12:06 am and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.