A Software Developer’s New Year’s Resolution

Or: 5 Things You Can Do Today to Improve Your Software Product

New Year’s eve is around the corner. It is the end of this year, and there’s a whole new year full of potential to be better, just waiting to begin. So how can you make it better? If you, like me, are a professional developer, then you can improve your life (and your boss’s and your team’s) by reducing software delivery related stress. Here are 5 things you can do, effective immediately, to make your product better:

1. Make a Version Management Plan

If your version control system is a mess, the first thing you should do is straighten it out. If you are not using one, then you should begin doing so immediately. There really is no excuse not to do so. For starters, there are plenty of high quality tools out there that are open source and free (git, mercurial, and subversion are the most common ones), as well as other commercial tools (I happen to use and consult on the use of Microsoft’s TFS). Either download and start using a free one, or get one that offers a trial period.

If you are using a VCS, but it’s a mess, and you find yourself mired deeply in merge-hell every time you want to deliver your software (internally or externally; it doesn’t matter), then you should straighten it out. Unfortunately, if you have a considerably sized source repository, this may seem as an impossible endeavor. Here’s one way to alleviate at least some of the pains of software delivery, in a few easy steps:

1. Create a new root-level folder named sources. This folder will contain your new source code repository.
2. Create a branch from your current repository, and call it main (e.g. /sources/main). This will represent your latest and greatest version, and should be kept as stable as possible, at any moment. No development will be done on it; you will only merge completed changes into it.
3. Create a branch from main, named dev (e.g. /sources/dev). This branch will be the branch that developers work on to create new features, checking code in and out from there. If there are multiple independent teams, you may have multiple dev branches.
4. Create a releases folder, which will contain release branches from main. Every time you wish to release your software (internally or externally), create a release branch from main (e.g. /sources/releases/1.2).

This is just one possible branching plan. It works particularly well for agile development, where effort is made towards developing as many features as possible before a release, merging them into main when ever they are done, and branching when the iteration is over. Note the following division of work:

• New features are developed only in dev. They are merged back into main when completed.
• Fixes are developed on release branches and reverse-integrated into main, and then back to dev, so that they won’t get lost.

This structure allows you to develop new software and stabilize a release at the same time without one effort polluting another. It is also a step towards being able to release a new version anytime.

If your development and release mechanism is well established, but not suited to fit this branch plan, make one that does work. Just make sure to be able to support feature and fix separation as well as the ability release anytime you need.

2. Automate Your Build

Even if all you do is copy sources from the repository to some drop folder, you have some sort of a build process. Automate it. Even just a part of it. Even just the compilation phase. Every step you let a computer do rather than yourself, is one less step to worry about. If you aren’t already using an automated build tool, you should start now. There are many open source tools as well as commercial ones. Most are powerful enough to suit your needs. Remember – If you can run it from command line, you can automate it as well.

Every time you run the build, you will not only create a deployment package of your system, but you will get a good indication about the health of your product (if the product doesn’t build, you will want to know sooner rather than later). Additionally, you will have the start of a platform for testing the system.

For a synergetic benefit with your versioning plan, schedule the following automated builds:

• Build the software every time you check in changes to your code (on dev or a release branch); most build and VCS tools support this – it is called continuous integration.
• Build the software every time you wish to merge dev to main. It is even better if you require a successful build as a prerequisite for the merge. This is called a gated check-in in many tools.
• Schedule a nightly build on main. This will let you know what the state of your system is. Fix any problems here first. Keeping a healthy build will allow you to deliver software at the drop of a hat. Amaze your PM!

3. Add a Health Report

Even a simple email message to the team in case a build fails will greatly improve your ability to fix problems with your software. Shorter feedback cycles means that you can fix problems when their causes are still fresh in your mind! Let your build system email you if it fails. Almost every system supports it. Conversely, you may wish to post successful build reports to some company wiki. Let everyone know of your successes.

4. Add an Automated Test

While the benefits of TDD as a design mechanism are far greater than just having a suite of tests, we should not belittle the benefit of an automated regression test. Even a simple record & replay automated smoke test, with a black-box test tool will greatly improve your system. Start with a single test that runs through as many parts of your system as you can easily manage. (Note – this might mean you need to add a deployment action to your automated build). Report if it fails. Run it every time you build. The more tests you add, the greater confidence you’ll have in your build system! Maintain your tests; fix any tests that fail due to legitimate changes and remove those that are no longer relevant. You don’t want your system to cry wolf!

5. No Broken Windows!

The most important thing you can do is to make a new year’s resolution that you will not suffer any problem with your software delivery lifecycle to remain unfixed! Once you fall off the wagon, your system will start to decay back to uncontrollable chaos. Think of maintaining your ALM like brushing your teeth. You may not like it but you do it every day (more than once), or your teeth will rot out until ultimately you won’t be able to eat!

In conclusion,

My new year’s resolution is to vigilantly keep my teams’ products “on the wagon”.What is yours?

Happy Holidays, and Happy New Year!

See you all next year,

Assaf.

Technorati Tags: Agile,Build,TDD,Test,Report,Version Control