Before I came to work at Menlo, I was Director of Development for a small software firm in Southfield, MI. Though I enjoyed the challenges the job offered, and had an absolutely great team, we were all more than a little tortured by the process of creating software.

The cycle typically went something like this:

1. Dev team would work many long hours, late nights, and weekends to meet deadlines
2. Dev team would throw the release candidate over the wall to QA/QC
3. QA/QC would find bugs and throw the release candidate back to the dev team
4. Dev team would work many long hours, late nights, and weekends fixing bugs
5. Dev team would throw the release candidate over the wall to QA/QC
6. QA/QC would find bugs and throw the release candidate back to the dev team
7. Sales team would start screaming bloody murder because of release delays
8. Dev team would work many long hours, late nights, and weekends fixing bugs
9. Dev team would throw the release candidate over the wall to QA/QC
10. QA/QC would find bugs and throw the release candidate back to the dev team
11. Technical support team would start screaming bloody murder because of release delays
12. Company owners would step in and demand release happen, regardless of number of bugs.
13. Release happens. I am not happy.
14. The phone immediately begins to ring as customers find bugs. Customers are not happy. Tech support team is not happy.
15. Work begins on the first service pack to patch the release. Team is not happy as they have to work many long hours, late nights, and weekends…

Sound familiar?

When I came to work for Menlo, my first role was software developer. Now it had been many years since I’d worked as a software developer. The last language I had spent any real time programming in was MUMPS, which was of little help when I came to work at Menlo.

My partner, Aparna, was very patient given many of my “navigator” directions consisted of statements like, “Don’t we need one of those thingies that’s a lot like one of those [pointing at the screen], but different?” Perhaps to call her patient is the understatement of the Century.

Not only was I learning a new programming language, but I was learning about unit testing, too. At the time, I was fairly convinced that it was going to break my brain to think in this new way, but I worked hard to learn. Eventually I came to feel more confident in my rusty skills. Somewhere in that gray matter of mine, a long slumbering portion of my brain was beginning to stir.

Though I could write a unit test, I can’t say that I really understood the point of unit testing yet. I wrote a test (with my partner, of course). Wrote a little code. Wrote another test. Wrote a little more code. Thankfully it was a small project, so I was able to see the process through from beginning to end. After about a week, we were done and released the software to the client.

It was at this time that I started to feel an looming sense of doom. I was nervous. I was a little agitated. I felt like I was waiting for something ominous. Finally it occurred to me: I was waiting for the phone to start ringing.

Except the phone didn’t start ringing. Not the day of release. Not the next day. Not the next day, either.

I was dumbfounded.

It wasn’t until I reflected on the experience with my partner that I really started to understand the power of unit testing. The phone wasn’t ringing because all those red bars and green bars we’d seen during the project meant we’d ferreted out the problems before they ever made it to the client’s hands.

That was a powerful realization, not only as a programmer, but as an executive too. Having seen this same scenario play out time and time again at Menlo — on projects both big and small — I now “get it.” It isn’t about testing quality in at the end, it’s about building quality into the product every step along the way.

We’re not perfect. We do make mistakes. But even after 8 years, Menlo doesn’t have (or need) a tech support department.

And that’s a beautiful thing.

2 Responses to “Waiting for the Phone to Ring”

1. Tathagat Varma says:

   November 13, 2009 at 9:28 am

   Nice article, and the picture you depict about “throwing stuff over the wall – to and fro” is so global! However, what I don’t understand or agree with is that small stuff like unit testing alone could magically fix problems at all levels of software – code, design, architecture, requirements, performance, scalability, interop, memory…and so on. I think there is a legitimate need for better unit testing…there is no doubt about it. But, I would be sceptical to treat it like panacea for all software development malaise.
2. Lisamarie says:

   November 13, 2009 at 9:49 am

   You’re right about it not being the panacea for all software ills. It’s only one part of a larger equation. In my particular case, my first brush with unit testing was on a small (very small) project. There was no doubt larger issues at play (design and architecture, for example) of which I was largely oblivious given I was trying to learn a new programming language *and* how to unit test. In that case, I suspect that my pair partner was bearing much of the weight of those larger concerns. (Thank you, Aparna!)

   Speaking of my pair partner, I also believe that pairing plays a big role in the success of projects. Constant code review, two minds working on a common problem, support for standards, etc. all contribute to project success. We’ve written about that a bit already, but will undoubtedly tackle it in more detail in the future.