I’m sure as a developer you’ve all heard of unit tests and best practices which preach to unit test your code in the finest details to ensure stability of the platform you are building. While my post does refer to Java (due to my recent experience) I am convinced that this can be applied to developers in any other language – in particular, years ago in a previous life I used to write C++ and I know the points made here are still valid for that language.

So you’re a developer, you write code, you test it and your code ultimately makes it in production as a result of some release process – which can range from someone simply deciding “let’s make a release today” to a lenghty’ properly managed cycle. Either way, part of your job, you think, is to document and unit test your code. And you’ve done all that, code goes into production and everyone is happy.

But the very next day an uber-urgent request comes up to change some of the functionality you’ve implemented and add some new one too. (If you ever worked in a startup you know that is such a common scenario!) Since you wrote that code in the first place it becomes your job to address these new requirements, naturally. Deadline is tight and you realise that you need to change a lot of the guts of your code to make it happen. And then you realise that your effort has to be doubled now because you have to change the unit tests too! Not only does the re-factoring make your tests not compile anymore but the actual scope of the tests themselves changed too. If you work in a small team where eveyone has about 10 tasks on their lists at any given time, passing the responsibility of writing the tests to someone else is unrealistic so you’re stuck with them – and with longer working hours to beat the deadline. At this point maintaining a whole set of unit tests becomes a burden that slows down the development and your time is spent half and half in between implementing functionality and writing tests – and do I need to remind you that tests don’t make the business any money? Arguably, the fact that your tests are there ensure your company product is stable – however psychology tells us that first of all since I’m writing the tests for my own code, the errors I’m putting in the code will most likely make it in the unit test too – and as such my code will look perfect after running the tests when the reality is far from it. Secondly, same psychology suggests that if I’m pressed for time I am less likely to pay attention to something like unit tests which are ultimately not crucial for the application. And in fact, I’m more likely to comment out or remove pieces of the old unit tests which need major effort and/or don’t compile anymore – and this just renders the time previously spent on unit tests useless – so I have managed to waste my time and the company time for nothing. (Be honest now: how many times have you not commented out unit tests yourself or seen it done just to get the work done and out of the way?)

So there it is: the joy of unit tests! Having worked with a few startups in my time I started detecting a pattern which mostly says write your code first – if your dev team is good enough (please tell me you haven’t hired just the “standard” in a startup – how will you survive?) then your code is 90% there. It will have bugs but make no mistake about it, it won’t have the standard “if null value passed in, system crashes” – it will have in fact errors so well hidden inside that in most cases your unit tests won’t reveal it anyway as they are contextual and only probably manifest under serious load. And such problems will only manifest themselves not by running a nightly build together with the unit tests but by actually having this in production for a few months and hitting a peak of traffic. And I don’t care what you say, but I’m yet to find that developer who can write unit tests to emulate 5,000 requests a second to test his shit! So really your unit tests protect you from your average Joe Bloggs touching your code – and if you hired him/her I think you deserve to pay the fucking price: if you’re some big corporation hiring people by the dozen or outsourcing to Elbonia or somewhere in the middle of fucking nowhere then you deserve your faith! I think you should spend most of your time writing unit tests for the idiots you entrusted with your code!

I am not against unit tests though – for those of you who made up your mind already! – I think it comes a time in each company’s evolution when you cannot justify anymore not hiring the “standard”. At that moment in time you do have lots of resources and time on your hand to afford the luxury of unit tests; at that moment in time product development doesn’t mean introducing 5 features in your product each day; at that moment in time you no longer have just a bunch of enthusiastic clever guys who want to change the world, you have the financial backing, you have the money and resources to start worrying about unit tests and processes – and that is a nice problem to have. But in my humble opinion is you’re small, if you ticked all the right boxes and you’ve got a small core of developers doing a great job, unit tests will only slow you down. And the main purpose for your startup is to provide rapid development and turnaround for your clients and I doubt that writing unit tests will help you achieve that.