Development Done Right

In my projects, I’ve always been the one who took care of infrastructure, standardization and quality assurance from the development perspective. The funny thing is that I’m no admin and no QA guy, so most of it wasn’t even my job. In this article, I’m going to list a few things that in my opinion as a software developer are essential to a professional software project.

What you need is no secret: If you read a few books and follow some technology blogs you know the bits and pieces. I’ll list a few things from a Java/Maven perspective, so some of this may or may not apply to other platforms.

First of all define a common coding style. I shouldn’t even have to mention this, but there will be chaos and conflict among developers if you don’t have it. Just use Sun’s Code Conventions, make some exceptions like “maximum line length is 120 characters” or “no tabs allowed” and you’re halfway done. Provide a bit of example code (one class, one page of paper) and put it up on a wall. This style guide should include rules for things like logging and exception handling strategies as well. Too few developers are even aware that you need a strategy here, so write it down! Don’t forget to define package namespaces for your project.

For Java projects provide organization-wide Maven archetypes that give you a solid basis for your project. Use existing open source ones to get you started! The effort for this pays off with each new project in reduced setup costs. But wait, each of your projects is different? Oh please, then adjust your build scripts. That’s no excuse to start from zero each time!

On a related note, invest in a proper internal Maven repository setup. Maybe use a stripped down version of Atlassian’s setup. You don’t want your builds to break just because some external repository isn’t available. Define rules who may deploy what to your repository. I’ve seen a lot of chaos here, so remind people to actually think before deploying stuff and breaking builds.

Get yourself a proper bug tracker and define how you’re going to use it. It doesn’t have to be fancy, a Trac installation will do in most cases and it will give you a wiki for your technical documentation, too. Do you just track issues or also tasks for developers? What’s the workflow? Who may open a ticket, who may close it? What amount of testing is required?

For god’s sake, define rules for working with your revision control system. How often should developers check in? How should a commit message look? How does your release process look like? When do you create a branch, how are releases tagged etc. Read up on the features of your system, branching may no longer hurt. Move on if you’re still using CVS.

A professional software project needs continuous integration. Period. Set it up (I recommend Hudson), define the proper reports and actually read them. It’s crucial to check test coverage and other metrics right from the beginning. If you add reports later, you will typically get warnings for every other line of source code. Nobody will read those reports anymore and it’s too much work to clean up the code.

Provide developers with a proper workstation setup that corresponds to the platform you’re targeting. Yes, it’s a good idea if everyone on the project used the same JVM and application server versions. If that’s what your production environment uses, even better! It might improve the chance that things actually work. Just saying.

I’m barely scratching the surface here, but it’s enough for one article already. For many of the points above you can find articles on the web (check my blog’s best practices category, for example). And still, it’s frustrating how little many software companies invest in those bare essentials.

Advertisements
This entry was posted in best practices and tagged , , , , . Bookmark the permalink.

3 Responses to Development Done Right

  1. David Linsin says:

    >> In my projects, I’ve always been the one who took care of infrastructure, standardization and quality assurance from the development perspective. The funny thing is that I’m no admin and no QA guy, so most of it wasn’t even my job.

    And that’s where I think the problems begin! A project must have someone who is in charge of this stuff, someone who is responsible for it! It’s not our job as sane developers, who FEEL responsible for it, to do this! Why? Because it is almost a full time job to setup this kind of infrastructure and it takes up even more time to keep it up to date and running.

    IMHO if project management is incapable of putting someone in charge or even worse if they don’t want to, then the project is doomed to fail! It might sound drastic, but I think being blunt about such an important topic is the only way to go.

    At my current project we half this position filled half heartedly which leads to the “broken window syndrome” – e.g. CI fails and nobody feels responsible for it and the poor person which is in charge has other problems and no time to check on it.

  2. mafr says:

    My former company had guys who were responsible for this kind of infrastructure. Not everything worked perfectly, but a lot of time was spent on standardization and build infrastructure and it certainly was an improvement to the situation we had before.

    Maybe some companies don’t have the resources (or priorities) to even get things started. Perhaps a community project that provides development guidelines (style guide, repo structure, release management strategy etc.) could help here. Organizations could take what they need and adopt it to their needs. What do you think?

  3. David Linsin says:

    >> Maybe some companies don’t have the resources (or priorities) to even get things started. Perhaps a community project that provides development guidelines (style guide, repo structure, release management strategy etc.) could help here. Organizations could take what they need and adopt it to their needs. What do you think?

    I think it’s an awesome idea. Blogging about stuff like this is a first step and your checklist is something every infrastructure guy should take into account when kicking off a project.

    However, I think most of the problems are not technical, they arise due to the lack of resources or priorities. If project leads or people in charge don’t make sure that this kind of infrastructure and the necessary processes around it are in place BEFORE development begins, there is no way that they are able to make up for it afterwards. You will have unhappy developers who spend hours a day waiting for build or merging conflicts. You’ll have project managers who cannot just add another programmer, because it takes days to setup his dev environment. It’s a ripple effect which will eventually lead to the failure of the project in one or the other way.

    As long as management or project lead don’t recognize the amazing effect a great development environment has, on the people, as well as on the resulting software, infrastructure will stay something that is neglected in every software project….just like testing and software quality.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s