underdevelopment

Well I figured a provocative title like that would catch your attention, so please read on to find out I am not as stupid as you might think.

Unit tests are great, they reduce unknown bugs and arguably lead to better object design. The reasons for this are simple; Well thought out unit tests will force you to think about the input and output of any method your objects may have, forcing you to correctly decomposition the needed functionality within your object, because methods that have too much responsibility are a pain in the ass to write unit tests for. Simple one task methods however are easy to write unit tests for. Because your writing unit tests you are (hopefully) actively thinking about what can go wrong so that methods can actually fail.

So taking for granted that the above is true, why does test driven development suck?
Well the answer to that is a market one and really only applies to professional business. When a client comes to your business and asks for a offer for his project, you will quote him X, where X is roughly the amount of hours it takes to create the unit tests and then fill in the code + other stuff.

A development house that doesn’t use test driven development will quote that same client only for the time it takes to write the code + other stuff. We all know that after that he will spend a few weeks/months bugfixing, but that’s not what he quotes or tells the client.

Naturally the client will more often then not choose your competitor, unless you can positively convince him that the extra hours you spend will actually save him money in the long run. Which from the clients standpoint is a bit of an unproven claim if he is not technically inclined. So from a business standpoint, test driven development sucks as a selling tool.

Secondly, while this heavily depends on the morality of your business, those bugfix hours can be profitable. Depending on how smooth your talk is, you could very well be billing the client for those hours.

Thirdly, test driven development often suffers when deadlines need to be met. We all know that estimated hours is an imperfect science and often goes wrong, be it overconfident developers or overselling sales people, deadlines tend to be missed in our industry. So when deadlines are creeping, unit tests are often one of the first things to be dropped off schedule. Yes, we all know that shouldn’t happen, but it does. Once this has happened and no extra time is allocated to bring the tests up-to-date again (good luck getting that approved), the test driven development has failed and you’re just plainly developing again.

So for these reasons I think test driven development sucks. I might sometimes use it for private projects or open-source projects (for which I think it is absolutely brilliant), but certainly not for business ones. With the possible exception of in-house developed products, but I haven’t had much experience with that.

For anyone who now still thinks TDD is a sound development methodology, I would be very interested to hear you thoughts.

I’ve recently changed the way I work so I figured I would detail it here.

First off all let me describe the setup. Basically all my code resides in a subversion repository on server X. My development environment is a virtual server run on virtualbox, a default ubuntu server with a LAMP stack. On my client I run the PDT edition of eclipse with subclips installed.

The client side:

• Install PDT eclipse, you can download it from http://www.eclipse.org/pdt/downloads/.
• Go to http://subclipse.tigris.org/ and follow the text to install it into your eclipse installation.
• In your eclipse choose import from the file menu and select “checkout project from SVN”
• You now should have a checkout on disk inside a project to work from in eclipse

Development environment side:

• Create and setup a LAMP based virtual server. (I’m going to assume ubuntu because that’s what I’ve used)
• Create a virtual host for your project.

The actual interesting bit:

Now the above is really standard stuff, so that’s why it’s a bit brief, but now comes the interesting bit.

What we want to do is mount the code checkout from your client machine as the serving directory of your development environment. Because I’m lazy I want to be able to do this with one click of the button, so we are going to break some security things to be able to do this via the browser.

We want the apache user (www-data in my case) to be able to mount via sshfs and unmount. This will enable it to mount the checkout from my client pc to the serving directory of apache on the virtual server.

First we want to add www-data to the fuse usergroup, we do this via the following command.

sudo usermod -G fuse www-data

Now the www-data user will be allowed to use sshfs.

Next we create the file /var/www/index.php and put some code into it. The following code is really simple and could probably be made more elegant but currently I don’t care


<?

if ($_GET['mount']=='myproject' )
  `sshfs user@192.168.1.20:/home/demo/workspace/myproject /var/www/myproject`;

if ($_GET['umount']=='myproject')
  `sudo umount /var/www/myproject/`;

if (is_file('/var/www/myproject/index.php'))
{
?>
myproject is currently mounted -- <a href="?umount=myproject" />umount</a>
<?
}else{
?>
myproject is currently not mounted -- <a href="?mount=myproject" />mount</a>
<?
}


What this allows us to do is to go to the default hosts index.php and remotely tell the server to mount or unmount the environment. There are a few things we need to do to actually make the above code work though.

First the mounting.
sshfs uses ssh, so since we want to use it without user interaction we need to create a private and public key for www-data.


sudo su - www-data
/bin/bash
ssh-keygen


After that you should have a set of keys, then copy the public key to your client and add it in ~/.ssh/authorized_keys of the user you need to log into.

Now the mounting of the repository should work.

However for the unmounting we need to use sudo to get the rights to do that. So for that we need to edit /etc/sudoers on the virtual server and add the following line somewhere.

www-data ALL = NOPASSWD: ALL

Yes, it would be much safer to not allow ALL, but only the umount, but for my virtual development box i’m really not concerned with security, I just want a trouble free and quick fix.

So now I created a simple script that will let me mount and unmount my working copy of the code on the virtual server.

I typed this all up rather quickly so if anyone wants some parts explained in some more detail just leave a comment.

Now this piece of wisdom is actually not mine, but from a colleague at ibuildings. He basically states the following; “If a client or user ever finds a bug or a security hole, then don’t ever say ‘Oh, i knew about that’.”

Now the observation here is that sometimes while you are reading older code you will see a bug or security leak. Often enough you will think “Oh well, this is old code and has been running for years”. That however is not the right thought to have.

The right thing to do is to estimate how many hours would be needed to fix it and what the impact of the problem is. If you then have enough time, you fix it. If you don’t, you register it and escalate it to the person responsible of the project.

At least then, you don’t have to say “Oh, I knew about that”. This phenomena is closely related to that of the broken window effect*, which teaches us that it is human nature to not fix the window. It is therefore wise to always keep the above in mind, and consciously force yourself to do the right thing.

So next time you see a bug, don’t say to yourself that you will fix it next week, because we both know that will probably never happen.

* This effect is wonderfully described in the book ‘the pragmatic programmer‘, required reading for any programmer if it was up to me.