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]