Software Development and 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 in agreement. Which reaction you have will depend upon your perspective and position in the software development process.

With few exceptions, you do NOT have as much control over the software development process as you may think.

I can see half of you stridently shaking your heads (fists) and saying things like 'but we have tools and processes and even a strict policy of re-use, backed up by a fully documented re-use catalogue.'

This thinking provides a comforting (but false) illusion of control, and the reality is that most organisations have software developers who will find ways of working around the 'process,' so that they can actually deliver working and valuable code.

Organisations who spend a lot of time trying to formalise re-use efforts with catalogues, or who view communities as committees are wasting valuable time delivering a shelf full of 3-inch thick white binders that very few developers actually look at or even read.

I can also see the heads shaking out there now because some of you work for companies that provide tooling to help accomplish some of the 'process' of Application Lifecycle Management. There is nothing wrong with tooling to help you better organise your software development efforts.

However, even the best tooling cannot overcome the basic human desire to avoid the constraints of admin and red tape. The best approach is to first develop a 'community.' Community members are here because they're interested, not primarily because it's their job.

Achieving a community is not as simple as following a 10 step list to success. It takes serious thought and a dedicated grass roots effort supported by a committed management structure. Tooling is useful once you've identified who your stakeholders are in the community and how they work together.

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 simply push back against and actively seek ways to get out of. This is where having an outside community consultant come in to help jump-start the process can help.

People ask can a tool enforce certain strict processes, or function as a re-use catalogue/repository? The answer is, that while it can do that to a certain degree, we encourage you to view the tool not as a compliance enforcement tool nor is it intended to develop a virtual shelf full of thick binders, for no one to read or use.

Instead, look at any tool with a critical eye. Examine closely the collaboration features (wikis, discussion forums, and even trackers) and ask yourself how will these help you foster a community while you organise and identify your software assets.

Ultimately, software development should be weighted toward producing useful and working code, which is very much part of the Agile/Scrum manifesto. It is not there to generate reams of documentation to feed the process machine.

An organisation's time and money are better spent building, supporting and facilitating a community, not building committees, because your good developers will become frustrated and actively find ways around delays and impediments to getting the job done.

It's much more productive to support, facilitate and foster that creative behaviour to the benefit of the community, than to try and stifle, and fight against it.