Archive for October, 2013

You don’t get big by writing tests

October 21, 2013 Leave a comment

You don’t get big by writing a lot of tests (or checks). You get big by getting stuff done with competent people that pay attention to the changes they apply. YMMV – bradfordw


Running unit tests

An example of running unit tests – Resharper

I vehemently disagree with this statement for three reasons.

First, it is extremely naive.  It implies that one can avoid the need for automated tests just by being an assiduous programmer.  If you are the sole developer on a project, this may be true (I doubt it).  Once you involve other programmers and the code is composed of different loosely coupled systems (as befits a good design), there is absolutely no way that a programmer can manually ensure that his changes are not breaking other code, even if his own code is perfect.

Second, it draws a false distinction between the behaviors of writing tests on the one hand and being competent and getting things done on the other.  Yes, writing tests slow down development in the short term, and in that sense are a hindrance to ‘getting things done’. In the long run they are absolutely crucial to the health of the code base.  Why?  Let me count just a few of the ways.

  1. Well designed tests help you catch many common errors (fencepost errors, typos, mixed up conditionals, overflows, underflows, etc.)

  2. Tests provide good documentation in the form of usages of your code to clients.

  3. By coding tests which exercise the contract (external API) of your class, you have a safety net for refactoring and improving it.  You can swap algorithms, data structures, etc., while having some assurance that your code still performs correctly.

  4. Tests allow you to prevent regressions.  If you fix a bug once, you can add the code that exercises that failure condition to the test suite and ensure that it does not creep back in with future maintenance.

While some of this may be possible to verify manually each time, it is incredibly wasteful of engineering time and talent.  Something as important as software testing and verification should not be left up to manual tests.

Third, and perhaps most importantly, it is patently false.  Large companies have many thousands (millions?) of tests.  The bigger the reach of software, the more potential cost a software error can have, and thus the more engineering effort is spent towards alleviating that risk.  The larger the software becomes, the less possible it is for a single person to understand the entire the system and to know all the possible repercussions of a change to his code.

I don’t know if the original poster was trolling or not, but it gave me a chance to collect some thoughts I’ve had about testing. When I was in college, I barely wrote tests of any kind unless they were explicitly required. The coding I did was mostly for projects that were completed in a week, submitted, and never seen again. After I joined the Northern Bites robotics team, I started working with a real, 100K+ SLOC code base that had evolved over years. There it was immediately drilled into my head the importance of testing. The fact that multiple people touched the same module, and that the same module might outlive your time on the team by years, made it absolutely crucial to test thoroughly.

It was also crucial to save time. We worked with Sony AIBO robots, and to put the new code on them involved cross compiling, putting the code on a memory stick, turning off the robot, inserting the stick, rebooting the robot, then waiting for the code to turn on. This easily took a minute or two each time. The more of the testing that could be performed automatically in software via unit tests and integration tests, the less time I had to spend in the painful compile/execute/debug cycle using actual robots.

Northern Bites in competition

Northern Bites in competition

Once I got to my first job, I mostly did software prototyping, meaning the quality of the code did not have to be incredibly high – they were proofs of concept, and were not intended for production. Nevertheless, I took with me the lessons I learned from the robotics team, and found that writing unit tests up front really did save a lot of time in the long run. Just as with the robots, it’s a lot faster to exercise the system via repeatable, automated tests rather than manually launching an app and verifying behavior.

I’ve since moved on and spent the last two years at a very large tech company, I am absolutely convinced of the efficacy and importance of automated tests. The smallest change can have unintended consequences, even when that code change is reviewed and signed off by other engineers. For instance, we recently had a case where someone changed a single flag to the empty string and it ended up breaking an entire pipeline in production. It was only configuration that was being changed, not code proper, yet it took down the system. Had there been a test that exercised the handling of the empty string, we would have prevented many hours of wasted effort. This sort of thing happens even with extremely smart, talented, conscientious people. I shudder to think how code bases devolve with only manual tests.

I’ve heard the expression ‘you play how you practice’, and it applies equally well to sports, music, and coding. The sooner you learn the importance of testing, the better. Even on my hobby projects, I will rarely write a line of code without starting with the tests. I encourage anyone reading this to do the same. The original poster claims that you don’t get big by writing tests. In my mind, you don’t get anywhere without writing tests.

Why E.B. White Couldn’t Write the Next Charlotte’s Web – Lessons in Mail Overload

October 3, 2013 2 comments
E.B. White

E.B. White

E.B. White, the children’s book author of Charlotte’s Web, wrote a letter explaining how fan mail had become his enemy – it sapped all of his time and prevented him from writing new creative works. Substitute email for fan mail, and you get an almost perfect description of the problems many office workers face. I’ll describe some of these problems and strategies for solving them.

All of the following quotes come from the letter, followed by my thoughts.

I would like to write another book for children but I spend all my spare time just answering the letters I get from children about the books I have already written.

White talks about the inadvertant harm that results from teachers encouraging their students to write him letters; each teacher thinks of the class in isolation without thinking of all the other people having the exact same idea. This leads to far more mail than he can possibly deal with:

The result is the author swamped with mail. Letters now come to me faster than I can answer them. Many of the letters contain requests—for an autograph, for a dust jacket, for an explanation, for a photograph. This to me presents a real problem. I have no secretary here at home, and if I am to deal with my mail I must do it myself; if I am to mail a book I must find the wrapping paper, the string, the energy, the right amount of stamps, and take the parcel to the post office up the road. This can occupy a whole morning, and often does.

This problem still exists, as message senders do not consider all the other requests vying for the attention of the recipient. I’ve heard of a few ideas to combat this, like the now defunct Smoke Signal, and, which both aim to indicate to the sender how much email the recipient has in his inbox.

About four years ago, I had an idea for a story for children. It seemed like such a pleasant idea that I spent my spare time for several weeks doing research and making notes—the raw material of a book. I put everything in a folder and there it still lies, awaiting a spell when I feel enough caught up with life to tackle the writing. Every once in a while I take this folder out and examine it, hungrily. But then I look at my desk where the unanswered letters and the undone things lie in accusing piles, and I stick the folder back in its corner.

I relate to this a distressing amount. I find it very difficult to ignore requests that come into my inbox, and as a result spend a large portion of time reading and responding to emails instead of actually accomplishing the things that are on my list. I try to mitigate this problem in a few ways.

Reducing distractions

I’ve written previously on ways to deal with information overload, including including shutting off any sort of email alerts (sounds, growl notifications, etc). I turn off all push notifications on my phone, and I do not link my phone to my work email account. This keeps email a ‘pull’ sort of system which I can read at my leisure rather than a ‘push’ system. I try not to leave a tab open, and instead open my inbox only a few times a day.

Aggressive filtering

I use Priority Inbox in Gmail and it does a remarkably good job of classifying emails as important or not. I set up additional filters so that, in general, only mail which directly includes me on the ‘to’ line makes it into my Important box. I try to keep the Starred and Everything Else sections minimized or hidden so that those streams of messages do not distract me from the important ones at the top of my inbox.


Despite what I mention above, I still check my email too frequently, and I still get too much email. I have a tendency to want to reply immediately to questions that come my way, even if it’s to a group of people and not directly addressed to me. This is a Very Bad Thing, because it conditions people to expect an immediate response from you, and reinforces the sender’s notion that their request really was urgent. I’m trying to learn to sit on my hands for the emails I see that are 1) addressed to more than just me and 2) don’t seem urgent. That way it gives others a chance to chime in and hopefully resolve the issue without my involvement.

Some products that implement the ability to ignore a message for a set amount of time are Snooze Your Email for Gmail and Boomerang for Gmail. I personally use a small Google Apps Script, so I can’t vouch for those two products.


E.B. White describes the problems that excessive fan mail caused him. I see very similar problems every workday dealing with email.

It’s dangerous to get in the habit of answering each request, no matter how small.

  1. It is distracting. The messages are likely to be about many different topics, causing context shifts and interrupting flow.
  2. Answering quickly reinforces the notion that the person making the request was right to consider the request as urgent.
  3. Answering emails tends to lead to receiving more email.
  4. You can feel a false sense of accomplishment by responding to emails, at the expense of doing your real work.

Some celebrities like Ringo Starr and Thomas Wilson choose to handle the problem of excessive fan mail by refusing to open any of it. Most of us cannot get away with that approach for email, but there is a middle ground we should take between that extreme and the extreme of obsessively answering each request as soon as it comes in.

There are mitigating strategies you can use to prevent emails from dominating your time and creativity. These include removing notifications, filtering your inbox, and snoozing non-urgent mails. For many other techniques you can read Merlin Mann’s 43 folders site.