Over the past week, there has been an interesting thread being talked about in software development. It started with a blog post by Ted Neward where he quoted Billy Hollis as saying:

Agile is treating the symptoms, not the disease.

Here, the agile being talked about is a reference to agile software development processes. Agile processes help manage the software development lifecycle, as well as managing what features should be in a project and managing expectations. These are good things, but it does not address the real problems in software development. Now, please stay with me as I am using this software development example to refer to a larger point.

Returning to Ted’s post, he summarizes his feelings very well in this one quote:

How does an agile process reduce the complexity load? And the answer, of course, is that it doesn’t—it simply tries to muddle through as best it can, by doing all of the things that developers need to be doing: gathering as much feedback from every corner of their world as they can, through tests, customer interaction, and frequent releases. All of which is good … But agile is not going to reduce the technology complexity load, which is the root cause of the problem.

Agile processes have been adopted by many development teams around the world. The processes do help in the long term, but the basic idea is that we are still just managing risk. Agile processes highlight the issues developers may be facing as well as quickly identifying any delays in the schedule. This is still risk management. The question is not how do we manage risk better (though that is still a good question), the real question is how do we remove risk.

Finally, I get to the point, but I am going to continue my software development examples. In any business, people will fail at various aspects of their job. Usually, this becomes a problem as more failures occur. At some point, a process is created to ensure that we know when a failure occurred, instead of finding out at the deadline. This is more of an issue with new concepts, software development being fairly new compared to engineering disciplines, and new technologies. For example, look at social media and its effects on marketing and feedback. Many companies are undertaking new “social media marketing” campaigns. Typically, they create a hopefully viral video and post it on YouTube. Then they share a link on Twitter and post a note on a Facebook page. Maybe they even get a PR firm to email a bunch of bloggers about this cool new viral video. Lastly, they sit back and wait for the sales to increase.

In this example, there is a boatload of risk and absolutely no management of that risk. Now, companies are looking into social media monitoring tools to start managing the risk, with risk being a huge number of negative comments on YouTube, Twitter and Facebook. In other cases, companies manage risk by moving in the opposite direction, shutting down their social media efforts, but failing to realize that the risk is already there because the people are there. Social media monitoring helps you identify failure or success much quicker than before, but it is just a process that tries to manage risk. Again, the process rarely fixes the problem.

So, how do we eliminate or reduce risk? Simplification. If we look at a follow-up post by Ted Neward, he looks at this from a different angle.

Why can’t end-users create tools of their own to solve their own problems at a scale appropriate to their local problem? … End users have just as much a desire and right to be amateur software developers as we do at being amateur cooks, photographers, poets, construction foremen, and musicians. And what do you do when you want to add an addition to your house instead of just building a doghouse? Or when you want to cook for several hundred people instead of just your family? You hire a professional, and let them do the project professionally.

Basically, if the problem is really too big for you to handle, you can minimize risk not by managing it, but by hiring people who do that for a living. Hopefully they are more experienced than you or have more expertise in the particular niche where your problem lies. This transfers the risk from yourself to the consultant.

There is another approach which has wider reaching affects, and that is simplifying the tools. Ted has a great quote from the first post mentioned, “Where is this decade’s Access?” Access is the database program in Microsoft Office that allowed users to create a form based application to store your data. In the 1990s, lots of people were creating little applications for their department to use. Sometimes these applications would later be absorbed by a larger corporate data warehousing strategy or they were converted to a small web application on the company’s intranet.

In terms of the departmental applications, we are seeing their equivalent in offerings like SharePoint and Google Sites. Granted, the development tools to create even form based applications are still too technical for normal users, these applications get users much closer to a local Access application. However, for larger web applications there is not a simple tool to help you get started. Ted uses the example of what a new Java programmer needs to learn in order to be productive in today’s web applications. He outlines a 5-week training program that is fairly limited in its scope compared to some applications.

This is the kind of thing that happens when people do not address the problem, but only address the symptoms. For the Java developer example, some people would say, use a framework like Spring. Even then, things may be simpler, but are they really simple enough? Why can’t we create an application like we put together a puzzle? Why do we need one application to post our video online, another to monitor the reactions, a third to send emails to various bloggers, and another that let’s us reply to people on Facebook and Twitter? A process will not fix this problem, it will only address the symptoms.

http://static.zemanta.com/readside/loader.js