SDD before TDD?

David Aiken has an interesting blog post about adopting TDD (Test Driven Development, for those of you have been living in a cave) for his next project.  In said blog post, David suggests that before even writing tests that one should write the setup logic:

First,  I'm adopting a TDD approach. So you would think my first piece of code was a test. WRONG! My first piece of code is the installer!

Installer? - there is nothing to install. Correct. But there is still an installer project, which compiles and builds and installs pretty much nothing. (It actually installs a DLL from the 1st project - the DLL contains an empty class otherwise you cannot build an installer). I've decided to use WIX as the installer technology (the same as we used for DinnerNow)

David's line of thinking goes right along with my philosophy that setup should be integrated directly into the development process.  Maybe we should call this process of writing the setup project up front SDD for Setup Driven Development.  <smile/>

The same way that TDD encourages the development of code that can be better unit tested, SDD would encourage the development of code that can be better deployed.  I argue quite often that many of the problems developers face in setup were caused by poor design or implementation decisions early in the development lifecycle.  Setup Driven Development would flush out deployment complications as soon as they were introduced into the application.  Seeing the deployment issues right away better enables the developer to make a decision to address the issue by writing complex setup logic or by simplify the application's deployment needs.  I would often encourage the latter.

Hmm, maybe this Setup Driven Deployment idea isn't so crazy after all...

 

6 Comments

Comment by Heath Stewart on Friday, August 10, 2007 8:19 AM

When Windows Installer first released their 1.0 beta they had a whitepaper that said very much the same thing: you develop your setup along with your product. Primarily this was intended for on-demand installs but it still held true for setup in general.

Unfortunately this ideal was not added to the SDK documentation and seems to have been lost forever. Treating setup as another import feature to design along with your product is definitely the right way to go. Setup as an afterthought always leads to tears.

Comment by RevFry on Friday, August 10, 2007 10:22 AM

No doubt, SDD. When I was doing "Release Engineering" we were always pushing to have our team in on the process from the beginning. All too often we'd get a quickly written email half-way through development - if we were lucky.

Most of the time it was a mad dash in the last 3 weeks of the project to get an installer on it.

No love. =)

Comment by Stefan on Friday, August 10, 2007 11:29 AM

This approach fits neatly into agile philosophy.

What good are rapid turn-around software development techniques if, in the end, the thing that ends up at your customer is what matters?

This goes even as far as enabling the customer to update / upgrade the current installation as painlessly as possible.

[Customer = any user of software, be it prototype / snapshot evaluators, beta testers, users of an Enterprise web application.]

What matters is: How fast and how reliably can you push your software to the customer?

Comment by Neil Sleightholm on Sunday, August 12, 2007 2:25 PM

I have long believed that the design process should be design, write install pack, code, etc. My theory is, if you can't install it, don't code it. Although I have said it many times no one seems to take notice! I believe the release process should be considered early on - how do we convinced the the non believers?

Comment by Christopher Painter on Tuesday, August 14, 2007 7:34 AM

Convincing can be practically impossible. In my experience, you have to throw up tough CM controls and beat them into submission as early as possible. Throw them a carrot while beating them... tell them ( and show them ) that you will make their life easier. Once you can control the source code library, the build automation, the deployment automation, the test environments, and access to the production environments, you'll have a chance at winning. Most developers I met love to talk the talk and argue about waterflow vs agile or go on and on about designing interfaces, but they will cut corners like hell and hand jam servers the first chance they get. They won't take Setup seriously until it's so painfully obvious that the way they are doing it won't scale and isn't reliable.

Comment by Stefan on Thursday, August 16, 2007 11:32 AM

I am in the suffering-from-"does not scale and is not reliable"-camp right now.

I believed, for too long, that having dedicated staff who deploys code into protected (staged) environments and comprehensive deployment documentation for really simplistic deployments (of ASP.NET components) would be perfectly fine. I have been disappointed.

So I am now swinging to the other extreme and doing everything in my capability to "relieve" <cough> this staff of its responsibilities.

I have always held the opinion, by the way, that once you deliver to third parties (be it as a service provider or as a seller of shrink-wrapped software), the installation experience really matters.

Leave a comment
optional