The post “Why Good Programmers Are Lazy and Dumb” by Philipp Lenssen is a very interesting read. To be a successful and agile development shop, it is not enough to have good project managers, architects and designers, you must also have really good programmers. They do the actual coding – the output that directly contributes to the success or failure of a project.
Since it is tough to recruit and retain good programmers, most companies create processes to reduce dependence on good programming talent. To an extent, this is true. Ensuring proper documentation, quality processes and metrics collection allow you to manage defects and maintain a certain level of quality. Software processes reduce “noise” in the project which negatively affects the project.
But process “manages”, it doesn’t “lead”. Let us take an example. A process may seek to manage delivery time and bug count. Bound by this criteria, the programmer gets the job done by the deadline and exercises all the documented test cases successfully. The process may not care about the internal code quality – did the developer write the code from scratch or did they choose a tried-and-tested library function?
Now you can start putting in processes to try to manage that, but there are many unwanted side effects. Say you want a process that places importance on less lines of code (LOC) in an attempt to encourage reuse and streamlined code, but that encourages programmers to skimp on validation code and effective error messages. On the other side, you cannot measure LOC productivity because that encourages developer to split up lines.
The point I am coming to is that it is not easy to reconcile conflicting parameters simply through a software process that involves metrics collection. You need to add the people factor into it – you need programmers with a certain bent-of-mind and, whenever possible, with the correct experience.
The best programmers have a overwhelming need to organize. They religiously follow their own standards in their code. They are constantly cleaning up their code to make it shorter and more legible. They are interested in frameworks that keep code in neat pigeonholes.
As Phillip mentioned, good programmers are always looking for ways to reduce repetitive work. Good programmers like challenge. They don’t like repeating the same boiler-plate code everywhere. They build or use code generation tools, they refactor, they use libraries.
Good programmers are never satisfied. They probably want to have one line of code do the entire program. They are inquisitive and always learning about new stuff, because they think they are still dumb and want to understand more.
When you have such a person on your team, you will find that code maintenance becomes less of a nightmare. At this point, the software process helps, because it helps manage the talents of the programmer with the business needs of milestones, deadlines and functional quality.