|
INDUSTRY WATCH:
A Lord of Discipline
By David Rubinstein
September 15, 2004 —As an engineering discipline, it would be kind to say that software development merely is young. It often is unstructured, with poor—if any—preproject estimates of time, functionality, cost and manpower being done; little—if any—modeling of the project to gain a visual understanding of what is being built; and no—that’s no—licensing of programmers to show they have achieved a level of expertise. Far too often, the mentality is more akin to playing jazz than engineering: “Let’s just wing it.”
Further, to say that software development as an industry is young implies that it is moving toward a more disciplined approach. While this undoubtedly is true in certain circles, those fighting to bring structure to the masses repeatedly tell me they run up against a “cultural resistance” to these types of changes. Sure they do. Human nature tells us that people get comfortable doing things a certain way and are very resistant to anyone coming along to tell them it’s better to do those things in a different way—even if it really is a better way.
We hear time and again of software projects that missed their deadline (see “Longhorn Delayed Until 2006,” page 3), or of projects that had their functionality cut so they could make their deadline (see “Longhorn Delayed Until 2006, page 3). Only in the software world, it seems, is this kind of lackadaisical planning and delivery accepted as part of doing business. Many major cities, for example, are using the carrot-and-stick approach to engineering projects. Fix a major roadway, and bring it in on time and under budget, and we’ll reward you with a bonus. Bring it in late, and you eat the overrun.
Successful software projects need to have good preplanning as well as a way to assess the impact of any changes to the original plan. The real-world costs of bad software estimates can be enormous. No longer is software estimation an academic exercise.
Michael Mah has experience with software estimation. At Sperry Corp. in the 1970s, he worked as a group leader developing the navigational system for the Trident II nuclear submarine. You couldn’t cut functionality on that project to meet a deadline. It was a complex system that ultimately had to let a vessel roughly the size of a horizontal apartment building sail blind, through dark waters with canyons, trenches and undersea mountains. The project fell behind schedule, bugs were on the rise, and failure loomed.
But Mah came across the work of Larry Putnam, a nuclear physicist who had discovered a technique for regression analysis of software projects, creating a model to predict the outcome of a project. There’s lots of math under these predictive algorithms; Mah said his team was able to predict the amount of time necessary to complete the project, as well as the bug rate, to a 90 percent degree of accuracy.
Putnam went on to found QSM Inc.; Mah is now managing partner of the affiliate consulting arm QSM Associates. The company has developed the SLIM suite of tools for risk analysis, metrics, software size estimation and “in-flight” analysis.
Yet Mah has found that there remains a perception in the industry that accurate software estimation cannot be done. “Some people believe that no estimates, no deadlines, makes people work harder.” In reality, he said, if a company believes a project should be done in 10 months but an estimation of the work shows it will take 16 months, then hard decisions must be made. Perhaps you cut features. Perhaps you must hire more staff. “But a lot of political shenanigans go on in this area. There are some people who just don’t want the truth.”
Mah said that people with mathematical and physics backgrounds “get it.” But, he noted, it’s a harder sell to educate others looking for a quick fix, who believe sending a project offshore will help them cut costs and increase manpower on a project.
“If a U.S. company wants a project done in eight months, [in India] they throw an army at it,” he said. That thinking, though, is flawed, as Mah pointed out the laws of software-project physics show a nonlinear gain by adding people to a project. “If you can do a project in 10 months with 10 people, you could put 20 people on it, but it won’t cut it in half,” he said, while raising the point that more people often create more problems. “The complexity of communication for a team of 40 makes bugs go up. The bug rate is 30 or 40 percent higher.” He then lamented that “they get the contract to fix the bugs. It’s built-in job security.”
Mah clearly is no fan of outsourcing as a way to get around engineering problems: “The domain knowledge isn’t always as good. A health company wanted to outsource a project to India but changed its mind. There is no health insurance in India. They couldn’t write that code.”
The world is an uncertain place. There are best-case and worst-case scenarios. If software development is truly to become an engineering discipline, the guesswork must be taken out of it. Computers can test bounds or ranges, then retest them, and perform simulations. As Mah said, “Dealing with ‘We don’t know’ is something the industry needs to get over.”
David Rubinstein is editor of SD Times.
|
|
Advertisement
Click here for a complete listing of Industry Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|