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


   

 
 
Download Current Issue
ISSUE 3/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

Open source on Windows
Open source developers are targeting Windows with great frequency, says Microsoft.
03/09/2010 01:41 PM EST

 

Events calendar tab
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

3/15/2010 to 3/17/2010
Las Vegas
Microsoft

3/16/2010 to 3/19/2010
Las Vegas
Penton Media

3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
Most Read Latest News Blog Resources

The Good, the Bad and the BS




October 1, 2006 — 
The software profession has failed, in both the small and the large, to make visible the quality of our work. Programs are judged by the aesthetics of their interface or the immediate utility of their functions. For end users, these are rightly the first and last concerns (with perhaps a small reserve for some awareness of reliability). The problem is that there are times when we, either as individuals or as businesses, need to convince others that one choice in programming (us) is better than another choice (them). As an industry, we have failed to develop a unified message to help those outside our circle discriminate between good and bad.

Not only is there no objective measure that we can offer, but we don’t even have any traction on subjective measures like safety or “feel.” The end result is that decisions about hiring (individuals or subcontractors) are utterly dominated by only two issues: price and fear of failure. Amongst ourselves, we know that at the request-for-proposal stage, promises about cost and satisfaction are signifiers of incompetence, if not outright fraud, but at some point all of us will lose a job because a CEO heard “risk” from us and “certainty” from another. Saying “good riddance to such a clueless person” may console us once or twice, but the truth is that 40 years after the phrase “software engineering” was coined, we hardly have a clue to give.

I have a client that’s facing a legitimate crisis: Serious shenanigans on the part of an existing software subcontractor have created a true threat to the business. I was engaged as a potential coder (the domain is one that Google steers my way), and I found myself in meetings whose purpose was to interview other potential subcontracting teams. It wasn’t my place to lead the discussions, so I passively observed a smart CEO and MIS director trying to decide between, on the one hand, one of the most impressive initial architectural discussions I’ve ever witnessed and, on the other hand, bozos with sales skills. As with many companies, my clients didn’t view themselves as a software development company, and the MIS director, while sharp and more than competent at handling infrastructure and integration, just wasn’t experienced in developing strategic software. While his BS detector had the right trend, what appeared to me to be a black-and-white decision was, to him, still gray. Thankfully, they both asked for and took my advice. Life is too short to program with bozos, and while there are no guarantees, I feel pretty good about the odds.

Another story, on a different scale: Back in 2001, in the midst of the post-dot-com implosion, a programmer (let’s call him “Gary”) architected and helped code core components of a system for a start-up company. With the business climate grim and a long engagement, Gary charged a far-from-extravagant living wage. Recently, the company contacted Gary again and told of their success: hundreds of clients, tens of millions of dollars in transactions going through the 5-year-old architecture. Would Gary be interested in helping architect the system to take them “to the next level”? Of course! Not only were they good people offering a great challenge, but surely he could charge them a pretty penny.

For a private contractor like Gary, a “pretty penny” still falls dramatically short of the rates charged by major consulting firms for even a moderately experienced developer. Recently, the FBI announced that a US$170 million project given to SAIC in 2001 resulted in 730K lines of code. Putting aside the fact that the code didn’t work, back-of-the-envelope calculations estimate 300-400 person-years of effort at around $200-$300 per hour. (This calculation accords with the report that as many as 200 programmers were kept on staff.) SAIC surely charged $400 per hour for architects and “just” $150 per hour for a Web designer, but that’s just a kabuki dance: SAIC undoubtedly produced reams of documentation and gigabytes of PowerPoint slides, but ultimately, everything a contractor does during the development phase is in support of the code.

So when Gary said that he’d be thrilled to work with the company at twice the rate that they had paid him five years ago, he felt that he was being generous. For less than what the FBI paid for an assembly-line developer, the company would be working with the person who had helped architect their current system to a rare level of success. Are you surprised to hear that not only did the company balk, but that negotiations ended when Gary held firm to a 40 percent raise? To them, that the previous work had held up for half a decade and scaled from two to 800 clients reflected little glory on Gary. That’s what’s systems do, right?

The software development industry has held too long to insular debates about what constitutes an ideal quality metric and in jostling buzzwords up and down. Every company of any size is now in the business of software development, and management needs to be educated, not about our internal debates, but about truths that we know to be universal about software development: Different individuals and teams vary greatly, tools and processes matter, and the difference between a good architecture and a bad architecture is the difference between an evolvable system and a quagmire.

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


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading