Technical Notes

Do you ever run your code? Another case for unit testing

A few of my most recent jobs have been with start-ups.  Working with a start-up can be stressful due to the urgency of getting to a product release.  Some of the employees of one particular start-up I worked with put in over 70 hours per week.  This wasn’t because they were under-staffed.  There were plenty of people to do the work but the company leadership was unable to come up with any sort of plan or priorities for the work.  What they had was people furiously working on projects that were irrelevant to the company.  Some people were working on projects that wouldn’t be needed for years, if ever.  One thing I recall about this company is that a lot of things were broken.

I took on the project of integrating the start-up application with an application made by one of their customers.  The start-up application was running an instance in production for another one of their customers.  Part of the project was defining and building a RESTful API that both my customer, the start-up, and their customer could use to communicate between applications.  The API had to include comments made to different event types.  When someone makes a comment on the start-up app it gets propagated to their customer app.  When someone makes a comment on their customer’s app it would be sent to the start-up’s app through a RESTful API call.  It would be similar to having Facebook and MySpace synchronized on your status updates.  Update your status on Facebook and MySpace reflects the change too.

As I built the API I found that their comment model didn’t work.  I looked back a few months in the SCM and found the methods in the model hadn’t worked in months.  Comparing that version with the previous version showed that everything except the class definition was new.  The comment model never worked.  The comment model had no unit tests to verify its functionality is correct nor did QE raise any questions or file any bugs on it.  The developer never actually ran this code.  The mistake would have been obvious if they took the time to run it.

Asking if anyone knew that commenting didn’t work was met with blank stares.  “No, it works.”  I asked them to demonstrate on any environment they had set up.  I hoped I was wrong and I didn’t have my environment set up right.  Leaving a comment failed every time on every environment.  I found out someone checked in a fix “last week”, but that developer never bothered to run the code either.  I don’t know how he verified his fix.  No one could leave comments anywhere, not even in production.  Yep, this code was broken for months in production for another customer and no one noticed.

I finally found out someone was “cleaning up” the comment functionality.  I asked about the precautions the developer is taking with this bug and was told something I already knew – how to “temporarily” fix it while the developer worked on the “clean up”.

Fixing the bug was beside the point.  This company needed to figure out a way to prioritize development.  Priorities save developers from wasting time building software that no one will use for months, years or ever.  Part of the start-up mentality is “throw stuff against the wall and see what sticks” but at the cost of basic functionality?  That’s a poor implementation and a poor business decision.

Getting off to the right start in a project is critically important.  Automated test frameworks are available for every major software development platform.  Not using them right at the start of a project makes it impossible for meaningful tests to be added later.  Not difficult – impossible.  We don’t use the strict  “waterfall” methodology anymore because testing after development is complete doesn’t work.  As a community we have known this for a long time.  Short, tactical releases are the way to go.  These short iterations are the perfect time to write tests with or even before writing the software.  Test-driven development and behavior-driven development are hot for a reason.

A long time ago I picked up some work for a shop that had a test-first mentality as part of the culture.  Before day one at this company they decided a test-first approach was the way to go.  Every developer was held to unit-testing their own software.  They also didn’t build any software that wasn’t needed for the current iteration.  Looking to build functionality needed “in the future”, they learned, was a waste of time.  That future never came.  Instead they used that time to test the software that was needed for that iteration.  They typically had well-scoped projects and were customer driven.  They had a lot of customers.  Somehow they found a way to please everyone.  Short, planned, targetted releases made those guys a lot of money and it was a pleasure to work with them.