Dogma vs. Data – Software Development Edition

As a software developer with a keen interest in data I find myself unable to resist articles like this one on Empirical Software Engineering. When I was in college the computer science department was part of the college of engineering. This always struck me as odd because it felt as if we did something that could be described as engineering by only the broadest of definitions. Sure, we had big O notation and cyclomatic complexity, but these other engineers had great tomes of data that told them if something worked. We had Professor Morse who threw things at us if our curly braces didn’t line up.

I find most of the fads in software development to be pretty tiresome, mostly because they tend to not work and spark religious style flame wars in the same place that I’m trying to find the answer to whatever the current problem I’m trying to solve is. As an aside that current problem usually has something to do with an unintended consequence of whatever fad is being peddled at the moment. The amazing part is how long some of these fads stick around.

One of my favorite, or least favorite, is the idea that you can just throw more people at a problem to solve it. I thought The Mythical Man Month blew this out of the water with so much data that when I read it in college I was convinced I’d never see this problem in industry. In fact, I see this problem all the time. Managers constantly try to save late or over budget projects by adding more people (or changing the people who are working on it). There are reams of studies and data that refute this, but it keeps coming around. What is equally amazing is that managers who should know better (i.e. former developers) do this as often as those who might not be as versed in development (i.e. business majors). They justify this flaunting of the data by assuming they are being roguish leaders who will prevail where others have failed and try to convince the team of this approach by using whatever buzzword is popular that day. I’ve heard “pulse the team”, “flex resources” and my personal favorite “strike team.” As if there is some development Nerd SEALS who can drop in without disrupting the existing team, come instantly up to speed and “hit the ground running” to solve a project’s problem. Yeah, I threw in another one there.

The speed and frequency at which new ideas come into the world of software development are what make it an exciting and really fun area to work. That doesn’t mean that ideas shouldn’t be put to the test and discarded if they are found to be lacking. All too often ideas are accepted and defended because they match the individual’s world view, not because they are empirically better or worse. As software increases its already huge footprint in the world measurement and effectiveness become increasingly important. We, both businesses and developers, need to understand what works to achieve greater and greater results.

The overriding point to the article I link to above and this post is that our guts, preconceived notions and dime store truisms don’t really help us as much as we think. Data driven decisions are dramatically better than intuition and end up saving more than the time spent gathering and analyzing the data.

1 Comment

• 
  Roseanna January 9, 2012 at 7:27 AM

  Deep thinking – adds a new dimension to it all.

  Reply