Is Software Management Obsolete?

Committees don't make great software. It takes a single person, an author. Maybe he gets some help. Teams don't do it. Nobody sees the whole elephant.

I'm pretty sure I heard that basic sentiment first in about 1986, from Dave Winer, who was then the author of a Macintosh outlining program named More (now he's better known as the de-facto father of blogging).

What reminded me over the weekend was my son emailing me about Jeff Atwood's Software Engineering: Dead post on Coding Horror. He's looking at this article by Tom DeMarco, author of Controlling Software Projects, a software management classic.

What DeMarco seems to be saying -- and, at least, what I am definitely saying -- is that control is ultimately illusory on software development projects. If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.

The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed.

That sounds to me a lot like Dave Winer was getting at about 25 years ago. And if it takes a single user, someone writing code and working the application because he or she wants to use it, then that's hard to manage.

And if you're interested in software quality, creativity, and management, you might want to look at an exchange between user interface designer Dustin Curtis and an interface designer at American Airlines. It starts here with Justin's rant about the hostile interface on the AA website; and gets more interesting here with an AA interface designer's answer.

The group running AA.com consists of at least 200 people spread out amongst many different groups, including, for example, QA, product planning, business analysis, code development, site operations, project planning, and user experience. We have a lot of people touching the site, and a lot more with their own vested interests in how the site presents its content and functionality.

It seems that frustration was had by all.
And it certainly won't make you wish you had a creative or design oriented position in a large company.

Follow Tim Berry on Twitter: www.twitter.com/Timberry

Comments

[jsub]

1) Building software is a creative activity.

2) Projects are completed by the sheer passion and heroics.

3) In software "nobody can see the whole elephant."

4) Only projects that don't deserve or need the scrutiny end up getting them.

5) To build software without metrics, just pick the projects with very high ROI.

6) We should abandon this charade and stop using software metrics.

I agree with 1, 2, and 3.

However, I think it's possible to impose the right controls throughout the software development life cycle.

Software is made by dozens of people making independent decisions, coming together in the end as the finished product. And when it all comes together, there's no foolproof way to know how this thing is going to work in the real world!

Process metrics alone won't do. In addition you need PRODUCT metrics. A measure of the QUALITY of the evolving product.

I work for a company where we define and precisely measure the quality, size, and complexity of large-scale software systems as they evolve. No human can see the whole thing end to end, but CAST can.

Point 4 may be right, but unfortunately, it doesn't lead to 5. We don't get to choose the projects we work on, and Demarco's guidance is simply not practical.

Finally 1+2+3 is not reason enough to believe in 6. We can get complete visibility over the entire software system, and we can measure it the way engineers measure their output.

[nowThenzen]

code can not yet be mass produced by machines. corporate/­capitalist model does not look for a watch maker, it looks for a machine that makes watches. a machine sophisticated enough to dynamically write code would be a machine as sophisticated as a fairly sophisticated person and that sophisticated machine would be temperamental and demanding like any good coder is.

That is why American business hates technology; they can't control it.

[kmsbt]

IT as an industry matured too quickly. The overwhelming majority of work effort since the dot.com bust has focused on process not product. The industry is flooded with a generation of project managers who believe that technical design and coding are the least important aspects of any given IT project. Their perception has been aggressively reinforced by the greedy, short-sighted practices of large companies that relentlessly analyze and attempt to break down technical tasks to their simplest components. If the job becomes turning a wrench, anybody can turn the wrench. This has effectively killed the sense or spirit of "craftsmanship" that DeMarco cites. Ironically, in this environment the corporations keep cutting expenses and the project managers keep claiming victory while the IT "elephant" is about as responsive and ultimately as rewarding to its users as it was 25 years ago.

[nowThenzen]

spot on