News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

There WILL be a JavaOne this year
JavaOne will happen in 2010, as a co-located event with Oracle's OpenWorld, on Sept. 19-23 in San Francisco.
01/27/2010 01:02 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Windows & .NET Watch: Losing control




August 15, 2009 — 
Tom DeMarco has dropped a bombshell. His recent “Viewpoints” column in IEEE Software disavows several of the fundamental aspects of software engineering, including the premise that “control is an important aspect, maybe the most important, of any software project.” It isn’t, he says.

A stunning statement, given the source. DeMarco’s “Controlling Software Projects: Management, Measurement and Estimates” was among the most influential texts in the 1980s. For software managers of my generation, “You can’t control what you can’t measure” has been as much a touchstone as, say, “Don’t blame me; the requirements were incomplete.” DeMarco is one of the most influential people in our field, having written classic books both on his own and with Timothy Lister ("Peopleware," "Waltzing with Bears").

For many of us, the problems of software management have seemed to be problems of control; managing developers is like herding cats, choosing a technology is like landing a plane on an aircraft carrier, controlling client expectations is as important as developing software, and so forth.

 It’s not that these problems are illusions, says DeMarco now. It’s that they don’t capture the potential of software. Sure, some software projects may only deliver a small payback on their development costs, but many software projects provide returns that are huge multiples of their costs, and they transform the business. Does it matter that a retail website had cost or time overruns if the payback is the transformation of a brick-and-mortar storefront into a global vendor? Does it matter that two tries at a new application had to be scrapped if the third try puts you on top of the market?

It strikes me (as things often do at this time of the year) as akin to baseball, where one can obsess over small-ball issues. But let’s face it: Stadiums get built for power hitters. The wonderful thing about software is that most software development teams can, if unleashed, propose software that has the potential to be transformative. Developers are necessarily immersed in software and technologies and will likely be the first to imagine recasting a domain problem into a new type of technology or platform.

On the other hand, as I discussed in a recent column, few teams are so trusted that they are given research, development budgets and the freedom to grab for a brass ring. The augmented reality application that I recently investigated would have been great, but there was no way to sufficiently mitigate the risks, and in the end I decided not to propose it to the client.

Was that a failure of imagination on my part, clinging to an old-fashioned need for control? Perhaps. But I just don’t live in a world (and certainly not in an economic climate) where clients accept “big risk, big payoff” as a justification for a software project.  
The case is different, of course, if you’re doing “greenfield” development. I was recently brainstorming with a colleague, and he kept berating me for suggesting things that were too incremental. “If we launch with such a thing, we’re going to be lost in the noise. How can we capture market share if we’re just a ‘nice improvement’ on established products?”

He was thinking very much in the mode that DeMarco advocates, trying to imagine something to build a company upon. I was doing what DeMarco warns of: “[T]he more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.”

One of the most appealing things about DeMarco’s recent writing is that he declines to descend into the weeds of methodology. Beyond incremental delivery and “starting early,” he has little to say about development processes. Agile methods may be superior, not because they are necessarily better routes towards consistency and predictability, but because certain things are not as important as we’ve thought they were.

Incremental delivery, it should be remembered, allows business users the one aspect of control they really care about: funding. If, every few weeks, a client is given a new potentially deployable application and the opportunity to continue the project down the path or cancel it, they are likely to feel more in control of the software development process than most.

Of course, this raises the question of how one goes about imagining software that is both transformative and incrementally developable. These seem contradictory, at least to conventional thinking. But perhaps if we spent as much effort trying to solve this contradiction as we have trying to figure out which metrics to collect, we might put our industry on a more satisfying path.

Larry O'Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.



Related Search Term(s): software development


Share this link: http://www.sdtimes.com/link/33683
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading