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.“
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
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.