Agile is all about code quality

Agile promises clean code. That's the purpose of the 'refactor' phase. After creating a test and modifying the code, the developer refactors the code to eliminate compromises made during the changes.

But how much refactoring is enough? One might flippantly say "as much as it takes" but that's not an answer.

For many shops, the answer seems to be "as much as the developer thinks is needed". Other shops allow refactoring until the end of the development cycle. The first is subjective and opens the development team to the risk of spending too much time on refactoring and not enough on adding features. The second is arbitrary and risks short-changing the refactoring phase and allowing messy code to remain in the system.

Agile removes risk by creating automated tests, creating them before modifying the code, and having developers run those automated tests after all changes. Developers must ensure that all tests pass; they cannot move on to other changes while tests are failing.

This process removes judgement from the developer. A developer cannot say that the code is "good enough" without the tests confirming it. The tests are the deciders of completeness.

I believe that we want the same philosophy for code quality. Instead of allowing a developer to decide when refactoring has reached "good enough", we will instead use an automated process to make that decision.

We already have code quality tools. C and C++ have had lint for decades. Other languages have tools as well. (Wikipedia has a page for static analysis tools.) Some are commercial, others open source. Most can be tailored to meet the needs of the team, placing more weight on some issues and ignoring others. My favorite at the moment is 'Rubocop', a style-checking tool for Ruby.

I expect that Agile processes will adopt a measured approach to refactoring. By using one (or several) code assessors, a team can ensure quality of the code.

Such a change is not without ramifications. This change, like the use of automated tests, takes judgement away from the programmer. Code assessment tools can consider many things, some of which are style. They can examine indentation, names of variables or functions, the length or complexity of a function, or the length of a line of code. They can check the number of layers of 'if' statements or 'while' loops.

Deferring judgement to the style checkers will affect managers as well as programmers. If a developer must refactor code until it passes the style checker, then a manager cannot cut short the refactoring phase. Managers will probably not like this change -- it takes away some control. Yet it is necessary to maintain code quality. By ending refactoring before the code is at an acceptable quality, managers allow poor code to remain in the system, which will affect future development.

Agile is all about code quality.

The (eventual) rise of style-checkers

The IT world changes technology and changes practices. We have changed platforms from mainframes to personal computers, from desktop PCs to web servers, and now we're changing from web servers to cloud computing. We've changed programming languages from assembly to Cobol and Fortran, to Basic, to Pascal and C, to C++, to Java and C#. We're now changing to JavaScript and Python.

We change our coding styles, from "unstructured" to structured and from structured to object-oriented.

We also change our development processes. We started with separate tools (editors, compilers, debuggers) and then shifted to the 'IDE' - the integrated development environment. We added version control systems.

The addition of version control is an interesting study. We had the tools for some time, yet we (as an industry) did not use them immediately. I speculate that it was management that spurred the use of version control, and not individual programmers. Version control offers little benefit to the individual; it offers more to managers.

The use of version control systems allows for larger teams and larger projects. Without version control, team members must coordinate their changes very carefully. Files are kept in a common directory, and updates to those files must ensure a consistent set of source code. It is easy for two programmers to start working on different changes. Both begin by copying the common code to their private workspaces. They make changes, and the first one done copies his changes into the common workspace. When the second programmer finishes, he copies his changes to the common area, overwriting the changes from the first programmer. Thus, the work from the first programmer "disappears".

These problems can be avoided by carefully checking prior to copying to the common area. For a small team (less than fifteen) this requires effort and disciple, and is possible. For a larger team, the coordination effort is daunting.

An additional benefit of version control systems: the illusion of accountability. With controlled access and logged activity, project managers could see who made which changes.

Project managers, not individual developers, changed the process to use version control. That's as it should be: project managers are the people to define the process. (They can use input from developers, however.)

We have style checking programs for many languages. A quick search shows style checkers for C, C++, C#, Java, Perl, Python, Ruby, Ada, Cobol, and even Fortran. Some checkers are simple affairs, checking nothing more than indentation and line length. Others are comprehensive, identifying complex modules.Style checkers are not used in a typical development project. The question is: when will style-check programs become part of the normal tool set?

Which is another way of asking: when (if ever) will a majority of development teams use style-check programs as part of their process?

I think that the answer is: yes, eventually, but not soon.

The same logic for version control systems has to apply to style checkers. It won't be individuals who bring style checkers into the process; it will be project managers.

Which means that the project managers will have to perceive some benefit from style checkers. There is a cost to using them. It is a change to the process, and some (many) people are resistant to change. Style checkers enforce a certain style on the code, and some (many) developers prefer their own style. Style checkers require time to run, time to analyze the output, and time to change the code to conform, all of which take time away from the main task of writing code.

The benefits of style checkers are somewhat hazy, and less clear than version control systems. Version control systems fixed a clear, repeating problem ("hey, where did my changes go?"). Style checkers do no such thing. At best, they make code style consistent across the project, which means that the code is easier to read, changes are easier to make, and developers can move from one section of the code to another. Style checkers invest effort now for a payback in the future.

I suspect that the adoption of style checkers will be slow, and while lead by project managers, it will be encouraged by developers. Or some developers. I suspect that the better developers will be more comfortable with style checkers and will want to work on projects with style checkers. It may be that development teams will form two groups: one with style checkers and one without. The development teams that use style checkers will tend to hire other developers who use style checkers, and the development teams that don't use style checkers will tend to hire developers who don't use style checkers. Why? Because a developer in the "wrong" environment will be uncomfortable with the process - and the code. (The same thing happened with version control systems.)

For style checkers to be adopted, I see the following preconditions:

• The style checkers have to exist (at least for the team's platform and language)
• The style checkers have to be easy to use
• The recommendations from style checkers has to be "tuneable" - you can't be swamped with too many messages at once
• The team has to be willing to improve the code
• The project management has to be willing to invest time now for payment later

 We have the tools, and they are easy to use (well, some of them). I think teams are willing to improve the code. What we need now is a demonstration that well-maintained code is easier to use in the long term.