Essential Development Practices

posted on 06/09/08 at 09:27:09 pm by Joel Ross

Over the past month, I have been helping a client establish a solid and reliable environment for team development. To be honest, I'd heard stories about poor development environments, but it was just theory and for all I knew, it could have been "Straw man" type argument meant to demonstrate the importance of certain development practices. You couldn't actually be doing team development without source code, right?!?

Well, I can now say that it is possible - I've seen it with my own eyes. The good news is that they were fully aware of the problems, but when you're heads down day in and day out fixing issues and developing features, it's tough to get your head above water and get a few things in place - even if it will make life easier in the long run.

At some point, they knew they needed some better practices, but didn't have the time to put it together themselves, so I was tasked to help them out. In the course of just a few hours, we were able to get source control and issue tracking in place. This included importing their source, and a brief training on the basics of checking in and checking out.

The project is still on-going, and we have a few more things that we want to do, but this whole process got me thinking about what I consider to be the "no brainers" of software development - the things that you use on every project that you just take for granted. Of course, this reminded of a post by Russell Ball where he listed out his seven essential practices.

For me, the absolute, bare minimum I expect on projects I work on are source control, issue tracking and continuous integration. There are other niceties, but without those three things, I'd rather not work on the project. I feel so strongly about those three that I ensure that even for personal projects, I have all three in place. Sometimes for personal projects, issue tracking may be as simple as a wiki, but the point is that I have something. CI is such a critical piece to me that I've implemented it on projects in my spare time - and I usually end up saving time down the line because deployments are easier and I know the code at least builds at all time (or why it doesn't!).

So, what are your absolute bare minimums before you'll say that you'd rather sit and be idle then develop in those conditions?

Categories: Consulting, Development, Software