In Defense of Development Practices

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.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Shawn Stratton (@mfacenet) wrote at 3/12/2010 1:12 am:

While I agree with you and Marco on process, let me say something of my own; I’ve worked on enough projects where there were no practices or standards that I’ve realized they are a necessity but at the same time best practices of the community don’t work on every team equally. Best practices are awesome in a perfect world where every team member is well versed, the project and methodology is well documented, and the deadline allows enough time to implement them. Sadly almost no project I’ve seen in the wild meets any of these 3 qualifications, so you literally have to pick and chose what practices to follow and which to cast aside in order to do what programing is really intended for, produce a working product. Yes I agree uptake time is important, maintainability is important, and I even agree the larger messes of code (WordPress as an example) work, but really the single best practice that most developers and managers need to learn is how to compromise and balance between good/best practices and doing our jobs.

Chris D wrote at 3/12/2010 3:51 pm:

Martin Fowler (mentioned in Marco’s post) made up all that crap just to get free drinks and woo women at computer and business conferences.

I bet he never though that people would actual believe it when they sobered up.

Stephen Cox wrote at 3/15/2010 11:07 am:

First question i ask; “Does it work?”. That’s all I need to know.

Look, the end users don’t care about code. They want the app to work. If YOU want to spend all YOUR time “perfecting” YOUR code, have at it. As long as I’m not paying your salary. ;)

Shawn, is right. it’s a balancing act. A balance of time, people and resources. All done to make sure the app works. And that’s the important thing. ;)

Mikael (@mikaelgramont) wrote at 3/15/2010 12:52 pm:

@Stephen Cox
“Perfecting” code is a way to ensure new features will be easy to add. If you don’t overdo it, it’s also a way to save money. And keep clients.

Copyright © 2023 by Brandon Savage. All rights reserved.