Build it or buy it?

Posted on March 5, 2008

2


Oftentimes this is a question when it comes to software itself.  People are always trying to determine whether they should build a given application or buy something off the shelf and just use it.  A great blog entry speaks to the exact issue.  There is a school of thought that software should fit the process and not the other way around.

I’m questioning if there’s another level this can be extended to.  Do you “buy” a software development process (SDP) or build your own?  There’s a broad range of SDPs out there today so it certainly would be easy to take one and use it, right?  Why would you ever start from scratch and roll your own?

For one, I think that most large processes are freakish monoliths that are more marvels (and I mean “marvel” in the least generous of terms) of engineering than practical applications.  CMM, for example, though not an SDP per se, is a great example.  I have been on a team who was attempting to reach CMM level 3.  We abandoned the effort because it killed our flexibility.  Now, it may have been a lack of creativity on our part, or it just may be that the process was more demanding than we needed to be effective.  That team of folks had a very lean development process and insanely low defect rates.  The system of about 100,000 lines of code had 12 known low-criticality defects.  It was a medical device, so having defects was a big issue.  And yet, we didn’t benefit from having a bulkier process for getting our work done.  Defect containment rates were consistently 100% and defects found during test were usually very minimal.  The existing process was very, very sound.

And yet, someone thought, “why are we using our own process?  There’s one out there we could use.”  Can and should are two different things.  So here I am at my new company, almost 12 years later and I’m hearing “we should switch to Agile.”  Putting aside my rants re: Agile in general, what is driving us to even think about it? 

Do we have problems with our development?  Sure, who doesn’t. 

Do we have defect rates we don’t like?  Sure. 

Do we have schedules we don’t like?  Sure. 

But we have a process which the company has been using for years.  How is it we are unwilling to understand what we have but willing to buy what someone else is selling?  If we don’t understand what drives the performance of the current process, what makes us think that going “Agile” is going to solve any of our problems.  What if our current process is good, but the key driver of performance is the below-average employees we hired?  An Agile implementation would suffer greatly in that reality, based on recommendations from Barry Boehm’s work.

A favorite refrain in the Six Sigma world (at least the one I’m in) is to “not boil the ocean” which has led us to attempt to chip away at the efficiency and quality issues in the organization.  Yet the process which our customer sees is from request to installed functionality.  Why are we fixing just software design or coding or unit testing?  If we understood the real end-to-end process we could optimize across the hand-offs and truly make a difference.

There are no silver bullets.  Are we “buying” a process because we’ve given up and we don’t understand the one we have? 

Are you?

Advertisements