On Tuesday, Marco Tabini told us that we were doing it all wrong. He makes some fantastic points about software development overall, and about the state of our profession. This article’s point isn’t to be a rebuttal, but a corollary to what he had to say.
Marco is right: every one of us is “doing it wrong.” If we examine our development practices, and compare them against the “best practices” of our industries, we’re never perfect. We always fall short of the goal. Yet our code doesn’t fail; in fact, for almost all of us it works and works well – it’s the only reason we haven’t gone on to basket making as a profession.
None of us became programmers because we liked process or red tape. Most of us became developers because we had a problem to solve, a computer program solved it, and we were hooked. Or we became programmers because we liked to tinker and make computers do things our way. But whatever the way we came, none of us came to programming because of the love of development practices.
So why should we pay attention to development practices at all? There are three reasons.
First, development practices help us work with other programmers. When we were young programmers writing code for ourselves, it didn’t much matter the file system structure, code design, design pattern implementation or function signatures we used. That changes when you add a team. In business, time is money; the longer it takes a new team member to ramp up on a project, the more expensive it will be to complete it. So development practices give a standard, boilerplate way to organize teams around a common goal.
Second, good development practices help keep things organized on a project. Imagine a project without a way of tracking the code, the issues, and the features being built. This would describe to many a chaotic environment devoid of organization or structure but is sadly the working conditions of many developers today. The code can only be as complete as the people working on it make it; if those people cannot track the issues, features, bugs and requests needed, or preserve changes in the code from being overwritten by others, the code quality suffers as a result.
Finally, good development practices make us happy. If you don’t believe me, take a look at the various shops you’ve worked in: where were you most happy? Were you happy in a shop where the code was a mess, there was no ticket tracking, version control was a pipe dream and specs were unheard of? My experience has been that I’m most happy in places that employ ticket tracking and version control; the stress level is lower, and the quality of the work naturally improves as a result.
This is certainly not meant to discount the many hardworking individuals who work on codebases like WordPress and Drupal; in fact, these code bases, despite their seeming disorganization, have huge communities that regularly submit patches and develop against them. The reality is that these projects exist and thrive because they do something no other product did at the time they were invented: they solved someone’s immediately pressing problem. This is their truly single claim to fame. They not only solved the problem of the person who invented them, but they solved lots of other people’s problems, people who thought to themselves “I need a blog” or “I need a CMS” and found WordPress and Drupal, and implemented them.
The point here is that development practices don’t necessarily make code run any better. The compiler doesn’t know that your tickets were closed and that version control was used; it simply sees syntax and function calls. Development practices are for developers, for their sanity and organization.
I agree with Marco: if you’re anguishing over good code, you can rest assured you’re doing it wrong. We all are. But our code works. And the rest is just for us.