Software: Art, Craft, or Business?
When I first met Greg Burnell, the CEO and co-founder of 6th Sense Analytics, he explained some of the vision and driving forces behind their metrics product. His vision is to provide the analytical insights that allow software development teams to truly understand their behavior, leading towards building better software. Essentially � to provide the sorts of data where no engineer has gone before.
As many do when introduced to their analytics, my initial reaction was one of Orwellian Big Brother dynamics. I simply couldn't envision any developer or team wanting to have this level of insight into what was truly going on. That it would be too intrusive or corrupt the performance and creativity of the team. Another concern was that the developers would game the metrics as many have done before.
Imagine that.
In that discussion, Greg couldn't seem to grasp my concerns about how this would corrupt the very essence of good software engineering. You see Greg is, at his heart, a "business guy" - having grown up selling software development tools, running operations and finance and managing people. Guess what, business guys get measured to death. They have to commit to business goals, objectives and quotas. Then provide daily updates as to how they're progressing to goals.
- If they're behind or ahead, it's visible.
- If there's a problem, it's visible.
- Individual and group performance isn't amorphous; rather it's clear and visible!
From his point of view, metrics and visibility were paramount to how you run a business and subsequently how you drive business value. He simply didn't see a problem with visibility and couldn't understand what the big deal was. Data was data and how else could you run a business? His basic point was software too is a business, so we need to view it as a business and drive it with data.
He didn't convince me in those early discussions. In fact, I thought he was a bit out of touch with the realities of software development. But as is my nature, I stew on things�thinking about them over time. My concern over taking a solely business view to software development is that we can...
- Lose our creative and innovative spirits
- Make the wrong trade-offs when implementing products
- Not build in sufficient quality
- Look to the short term over long term
- Burnout or abuse our teams
...mostly because I feel that software development is more art and craft than it is a hard-nosed business initiative. That true product greatness comes from creativity that can't be forced or planned, but that has to be nurtured.
However, I've come to realize over time (before and after conversations with Greg) that software, while not being SOLELY about business, it is ALSO about business, and that Greg by-and-large, is (dare I say it) right. And I, like many developers today, am struggling to adjust my thinking to this simple point. I'll point to a couple of examples of just this struggle�
In a recent post on 37 Signals, there was a discussion surrounding a project management quote from Fred Brooks � �How does a project get to be a year behind schedule? One day at a time.". In response to the point, they were taking the position that release dates and commitments don�t really matter�adopting more of a �if you build it, they will come" business strategy for driving software development.
Now perhaps this unique technique works for 37 Signals, but does it work for the environments that most (all) of us work in? Can (or should) we ignore release goals, milestones, targets, customer driven content -- in other words the "business side" of our work? I can't even imagine this working in a majority of product and business contexts. Nor should it! Software is ALSO about the business side and we need to internalize that point.
Quick question -- would I invest some of my retirement funds in a business that had no clear, date-driven goals or objectives? That doesn't really listen to their customers, but assumes it "knows" best I want to retire in a low stress, high quality, fishing oriented fashion, so I'll let you answer that one for yourself ;-)
Previous Post:
IT Governance, Asset Management and People-ready Metrics
Next Post:
Challenging Assumptions
