Impact on Code Development

Impact on Code Development

When developers first learn of check-in policies, code analysis, unit testing, and test-driven development, they often despair that they will never be able to be as productive as they were when they could just develop without restrictions. In some cases, developers have legitimate worries. If a developer is a superstar and only rarely creates a bug, why should unit tests have to be built to verify and cover the code? The developer will argue that building unit tests and having to deal with check-in policies will halve the amount of code that can be created.

These restrictions placed on developers by their project managers, architects, and senior developers serve an important purpose, however. Even if every individual developer writes fewer lines of code each day, the project will likely be completed earlier than it normally would have been without these restrictions. This paradoxical result is easily explained. Even superstar coders end up creating code that, by necessity, interacts with the code created by other developers. Although everyone strived for loose coupling, it can never be completely achieved. That coupling means that a change in one person's code can break the code created by another, or at the very least, break a feature that depended on a particular interface. This means more debugging and more testing, both of which take up a considerable amount of time, especially if the issues are discovered late in the development life cycle.

When developers are restricted to following best practices and a particular development methodology, they might feel less productive and more restricted at first. After all, they have to fulfill a number of tasks that may not seem directly related to implementing customer features. However, most developers soon learn that these restrictions actually allow them far more flexibility than they were accustomed to because a strong unit test harness and good practices allow them to make desired changes in their code (refactoring) without having to worry that their changes will create undetected breaks in code somewhere else in the system. If, during refactoring, some code is broken, it will show up immediately when all the unit tests are run, allowing developers to actually become more productive and have considerably more freedom. In an ad hoc development process, developers were tied very tightly to existing code and existing interface, mostly out of fear because (as most developers are aware) making a change to an interface usually involved considerable time tracking down all the impacts in the code. And even then, some impacts were missed, only to be found late in the development life cycle—either by testers, or more upsettingly, by users.

An analogy is car brakes. Why do you put brakes on a car? Is it so you can drive more slowly? NO! You put brakes on a car so you can drive faster more safely. If you lost the brakes on your car, chances are you wouldn't drive very fast at all (only as fast as your fenders could easily handle). That's where we are in software development without a process. With brakes, we can drive far faster because we're confident in our ability to slow down quickly when circumstances warrant. When we develop with a process, we're more like a car with brakes: We can develop faster with the knowledge that if we make a mistake or something changes, we can recover easily, quickly, and safely. After only a few months of development within a smoothly running process, most developers are converts.

The problem is that historically, the process has been very difficult to integrate smoothly. Instead, process was often implemented outside of the development environment, forcing developers to leave their IDE and enter data about what they just did. Nothing is as frustrating to a developer as reentering data or entering data in a different package that could have easily been tracked without any effort if their environment supported it. This is where Visual Studio Team System is so valuable. By integrating process smoothly, inside of the developers' preferred tool, developers can focus on writing code, not on reporting on what they've done. Visual Studio Team System also makes it easy to adopt a process because the integration with the code development area is outstanding.