The Illusion of Control

What I’m about to tell you will either: a) scare you to death, or b) make you nod your head violently in agreement. Which reaction you have will depend upon your perspective and position in the software development process. Ready? Here goes:

With few exceptions (Space Shuttle source code, etc.), you do NOT have as much control over the software development process as you think.

I can see those of you in camp ‘A’ above stridently shaking your heads and saying things like ‘but we have tools and processes and even a strict policy of reuse, backed up by a fully documented reuse catalog.’ This thinking provides a comforting (but false) illusion of control, and the reality I’ve learned over almost 20 years in the software industry is that most organizations have software developers who will find ways around the ‘process’ so that they can actually deliver working and valuable code. Organizations who spend a lot of time trying to formalize reuse efforts with catalogs, or who view communities as committees (as described by CollabNet’s CTO Jack Repenning) are quite frankly wasting valuable time delivering the equivalent of the shelf full of 3-inch thick white binders that very few (if any) developers actually read.

I can also see the heads shaking out there now because I work for a company that provides tooling to help accomplish some of the ‘process’ of Application Lifecycle Management. Let me set the record straight – there is nothing wrong with tooling to help you better organize your software development efforts. However, even the best tooling cannot overcome the basic human desire to get past red tape. Those who have read this blog in the past can imagine what I’m going to throw out there as the solution to this dilemma. Yes, that’s right, the oft-uttered and mostly misunderstood notion of ‘community.’

Jack’s post had some wonderful descriptions of community, and I’d only add one small wrinkle to his first comment about why people participate in them:

“Community members are here because they’re interested, not (primarily) because it’s their job.”

Achieving community is not a simple ‘do these 10 steps in order’ kind of an operation. It takes serious thought and a dedicated grass roots effort supported by a willing management structure. Where do tools like CollabNet TeamForge fit into this equation? Tooling is useful once you’ve identified who your stakeholders are in the community and how they work together (if at all). Even then, you sometimes have to adjust the tools to fit your community’s expectations; however the overriding goal of tools should be to help loosely couple the community together, not constrict or control them into an overly formal process that people will look to get out of. This is where having an outside community consultant come in to help jump-start the process can help.

I won’t go into great depth here on Agile as a development methodology (you can read much more in-depth and detailed posts on the subject at the CollabNet Scrum and Agile blog), but I have to say that my experience in the past one and a half years using Agile/Scrum is that it best captures the balance of community involvement with just enough process to keep people organized.

People ask us all the time as CollabNet consultants whether our tool can enforce certain strict processes, or function as a reuse catalog/repository, and while it can do that to a degree, we highly encourage folks to view the tool not as a compliance hammer or a way to develop a virtual shelf full of thick binders no one uses. Instead, look at TeamForge (or any tool for that matter) with a critical eye toward how the collaboration features (wikis, discussion forums, and even trackers) help you foster community while you organize and identify your software assets.

Ultimately, software development should be weighted toward producing useful and working code (part of the Agile manifesto), not reams of documentation to feed the process machine. An organization’s time and money are better spent facilitating community, not building committees, because human nature will lead your good developers to find ways around impediments to getting the job done anyway. It’s much more productive to facilitate and foster that behavior rather than try to fight against it.

[Photo Credit: Crunched.org]

Posted in Agile, TeamForge
2 comments on “The Illusion of Control
  1. It seems to me that reuse repositories are a bit like corn fields. You can go down to Safeway, buy some ears of corn, bury them in the field, then dig them up … and voila! you have corn! But not very much. And you probably don’t want to eat it, anyway. If, on the other hand, you take a handful or a hopper full of seed corn, bury it, care for it, raise it up, and then harvest it, you get hundreds or thousands of ears of corn. Nice corn. Corn you want to eat.
    It’s the same with reuse: if your attention to reusability starts when the product is finished, if you begin “reuse” when you toss the finished products into the repository … then you won’t get much reusable stuff, and it won’t be very tasty.
    CollabNet products, services, and training enable you to produce software that’s worth reusing, and to capture the development metadata like discussions and decisions as they happen. You don’t have to build a separate catalog or generate separate documents any more than you have to bury corn silk and cobs: the process itself takes care of those parts, you just harvest them when it’s done.

  2. Guy Martin says:

    Wow – thanks Jack!
    You’ve just given me an awesome analogy to use with customers now. The idea of a repository isn’t a bad one, but, as you point out, if it becomes a ‘dumping ground’, the value is severely diminished.
    -Guy

Leave a Reply

Your email address will not be published. Required fields are marked *

*