Automated Builds - Test Driven Development

Introduction
Your development process can be improved if you automate your build process and implement some form of test driven development. All of us have been on projects where the integration phase takes a long time, often longer that the development time itself.
By taking steps toward automated builds and test driven development over time, you will make the integration process a non event. The mantra is “Find as many issues as possible, as early as possible”.
The first step toward automated builds is to develop a script that extracts everything from version control and builds your system using one command. The goal is to be able to visit an empty machine and build your app with this single command.
This means that everything you need for you application should reside in version control. This includes database schemas, stored procedures, views, seed data, source code and ideally, unit tests.
If the build succeeds, an installation package is created and success notification emails are sent to a distribution list. This installation package is stored in a drop folder and made available to anyone who needs it.
nAnt is a good open source tool that can perform these tasks.

Version Control
The heart of automated builds is Version Control. Everything necessary to build your application should reside here.
Your database schema represented in the form if a SQL script resides in Version Control. Ideally, this script should be created using a database modeling tool. The modeling tool creates the script and is stored in version control.
All of the scripts necessary to create your stored procs, views and other programmatic database objects reside in version control as well. A master script that executes these scripts in the proper is also required. It is not a good idea to develop database objects directly in the database. Always develop database objects via scripts.
The final database task you face is the scripting necessary to populate seed data. This could be lookup tables and other data necessary to operate your application.
Of course, all of the source code for you application must reside in version control. It is also suggested to include the source code for your unit tests. nUnit is a very good open source tool for unit testing.
When a build is successful, we will create an installation package. This could be as simple as a zip file with installation instructions or an MSI file to automate the install. Anything necessary to facilitate the install should be in version control as well.

The Build
A single command should perform the build. nAnt is an excellent scripting based on the popular Ant setoff tools in the J2EE world. nAnt should perform the following general steps:

• Cleanup – Perform any cleanup from a previous build. Delete any executables, config file or other objects.
• Drop Database – Drop the database that was created from previous builds.
• Extract From Version Control – Extract the files from version control.
• Build the Database – Create a new empty database. Execute the schema script, Script for Procs and views and seed data script.
• Compile the application – Perform a compile of the application and unit tests.
• Execute the Unit tests – Use the batch option to execute all of the unit tests for the application.
• Failure action – If any of the above steps fail, send a failure notice and log to failure distribution list.
• Success action – If the build succeeds, build an installation package and send an email to the success distribution list. The installation package is available to QA or anyone who need it.

In Closing
Even though it is a challenge to get an automated build setup the first time, it is worthwhile. If the build is run every night, problems are uncovered on a daily basis instead of being pushed to the end of the project.
The following links provide useful information on this topic:

• nAnt Home Page – Used to automate builds ( http://nant.sourceforge.net/ )
• nUnit Home Page – Used to develop unit tests ( http://www.nunit.org/ )
• Continuous Integration – Very good article that describes how this idea benefits development projects http://www.martinfowler.com/articles/continuousIntegration.html )

Don't have enough time to do a task - Time Box it

We have all faced with the situation where there is too much to do an not enough time to do it. Sometimes the technique of Time Boxing can save the day.

Time Boxing is useful when you have tasks like documentation, specifications or other analysis type work.

Say we have a system that need analysis performed. You estimate it will take 200 hours to complete the task. Well, what if you only have 75 hours.

The trick is to cover the width of the problem domain without going into the depth completely. So, as the diagram on the right depicts, you cover the problem domain an inch deep and a mile wide instead of covering the whole topic. The trick is cover enough width to have a meaningful deliverable.

It takes a bit of practice, but over time you will gain experience with this approach.

Are your clients reading your documents?

I was working at a client a few years back. Lets call this client Futz Inc. Futz was building a very complex application that was getting ready to go into the construction phase. Just as the construction phase began, the final version of the specification was sent to the copy center(this was before email was mainstream).
The cover letter of the specification asked the folks to review the specification and get back with any comments.
Well, the copy center made a mistake. Because this was a large document, they printed the specification duplex, or a page on each side of the paper. They accidentally skipped every other page of the specification.
So, the specification was obviously incorrect with every other page missing. Well, no one got back with comments. So, no one read the specification.
Since then, I use a trick. If I believe my customer is not reading my documents. I place an obvious error in the specification. For example I may say "There is one square wheel on the wheelbarrow".
If the customer says "Scott, we should not have the wheel square" I say, "Oh what was I thinking, of course it should be round, sorry".
But, if the customer does not ask me about the square wheel, I know to be very careful. I schedule meetings with the customer where i walk through the system in detail and ask questions.
So, if you want to see if your customers are reading, your stuff, make an obvious mistake and see for yourself.