Tools and Training

No Silver Bullet tells us to be skeptical about claims of tools that can provide drastic improvements in productivity. What we can instead hope for from productivity tools are minor, yet still significant, improvements.

However, both lowering our expectations and going with proven technologies aren’t enough to receive productivity benefits when introducing a new tool. Many companies still fail because of a certain classic mistake: Lack of Training.

Steve McConnell neatly sums this problem up in his book Rapid Development by providing a story:

The more powerful the tool is, the more difficult it can be used effectively. Without adequate training, tools that could provide significant productivity benefits often sit on shelves unused. Wayne Beardsley puts it this way:

Think of our software company as a construction company. Our task is to dig up a ditch from the street to a farmhouse five miles away. We’ve purchased the latest backhoe systems for the work crew. On a typical day, the crew members drive the backhoe from the street to the end of the ditch, hop off, and use the shovels that came with the backhoe to dig another few feet. At the end of the day, they hop back onto the backhoe and drive it back to the street. Maybe we should explain that the backhoe wasn’t purchased for commuting. (Beardsley 1995)

This analogy fits altogether too closely to many software projects.

This is the most memorable part of Rapid Development for me simply because I am still haunted by the memories of my first software project.

It was a fairly large project; at its peak we were about a hundred developers, analysts, and testers. In hindsight, one of the worst things in that project was surrounding the web framework we used.

Normally, the company uses an in house web framework for developing systems. For this project, they decided to get an established open-source web framework to do the job.

In itself, it was a good move. The web framework was far more advanced than the current in-house web framework. The bad news was that it was too advanced for the developers.

The framework uses a combination of Struts and Hibernate to form a Model-View-Controller (MVC) architecture while using Spring to glue things together via dependency injection. The problem was that not even the most senior of developers knew what “MVC” and “dependency injection” meant or what benefits they can provide to us. The framework also had a test framework ready, but since none of the senior developers knew how to do automated testing, this test framework wasn’t used.

If we had put more effort into understanding the fundamental concepts behind the design decisions of that framework as well as provide adequate training based on those studies, we might have reaped the benefits from using that framework. Unfortunately, schedule and resources (i.e. developers) was tight so they decided that as long as we were making working applications, our skill level then was already acceptable.

In the end, we only got to use only the basic features of the framework. Still, it was a robust framework and not even our incompetence could ruin it. It’s just kinda sad that we never got to use the framework’s full potential.