Software Processes: Should You Pick One?

While we in software industry debating which process to adopt for development, I found something in manufacturing very intriguing. On a recent article of Business Week The Case for Making It in the USA, it mentioned a GE factory in South Carolina where aircraft jet engines are made. What struck me is the following:

“Teams can adjust the line operation as they see fit to remove bottlenecks and maximize productivity. Recently, two teams came up with different ways to speed up the washing of turbine blades. The plant leader, rather than picking one way as the winner, approved buying equipment for each team to wash the blades its own way.“

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

I would say it’s pretty rare today where standardization and unification are emphasized for high productivity. But it happened in a GE factory. I don’t know whether it yields high productivity but for sure high morale of the two teams. With a little nice competition, we may expect higher productivity than otherwise.

As an industry, we’ve been treating software development as manufacturing software, therefore we’ve invented many different processes and methodologies. The initial and very famous one is the water fall process, which model the software development the same way as manufacturing. It turned out not working well in most software development.

After that, there are many other processes coming up, for example, Rational Unified Process (RUP), which I had worked on while I was at Rational Software years ago. This is mostly perceived as a heavy process meant for big companies with big teams.

Most recent buzz is the agile process, which is in fact a family of different processes like Extreme Programming (XP), Scrum, etc. Even RUP, as I heard later, has an agile edition which is a strip down version. If you engage in a conversation on software process, I bet what you hear the most is the agile keyword.

From business perspective, being agile is definitely a great thing. Anyone is not interested in being agile? I haven’t heard anyone. The real question to ask should be whether it works. In my experience, it depends a lot on the team: company culture, project, past experiences, etc. It may work well or not. Considering all these, an agile process is not a silver bullet. To be honest, I actually doubt if there is a silver bullet in software process.

Having said that, I think different processes have their own audiences. Even you’ve decided to adopt one, you don’t want to treat it as something fixed. For example, the daily meetings could be a nice thing for some people but may turn off others.

I think the most important thing is not about processes, it’s about principles behind them. As it stands today, the commonly accepted and proven principles include: iterative development, continuous integration, etc.

Because software process is not something deterministic, I think whatever process should be left to team members. In some cases, there may be no well known process but a team’s own way to get software done.

You may then wonder, how to manage an organization with different processes? It definitely adds some complexities on communication and expectation across different teams. The key is to be result oriented. As long as it’s delivered on time within budget, it’s a good “process” for a team. Don’t try to force the team to change just because of management preference.

Having said that, I do think it’s critical to have a standardized, not necessary uniform, infrastructure like build system, bug tracking system. These are good enough mostly for insights into an ongoing project.

Last thought, software process is important. Equally important, if not more, is the software architecture, which I will talk about later.

This entry was posted in Software Development and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. jcai
    Posted May 16, 2011 at 1:08 pm | Permalink

    Very well said, Steve! The last thing you want is doing Agile for the sake of doing Agile, where basic software development practice, such as having a design before coding, is shattered in the name of “we are agile and we will re-factor the code in coming sprints”.

  2. Posted May 17, 2011 at 2:01 pm | Permalink

    Thanks for sharing your observation! I’ve seen the similar as well.


  3. Posted December 6, 2013 at 8:39 am | Permalink

    I feel this is among the most significant info for me.
    And i’m glad reading your article. But want to observation
    on few normal things, The site style is ideal, the articles is truly
    nice : D. Excellent job, cheers

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.