Comments (5)

By Rich, June 21, 2010 10:36 am

I often hear the phrase, “We hire the best and brightest.” It leaves me wondering who hires the “worst and dimmest.”

In order to experience real success every team needs to determine how they can achieve extraordinary results with ordinary people. When I teach our Agile Explained class, I reference the six focus areas of Six Sigma. These include Environment, Measurement Systems, Methods, Materials, Machines, and People. My belief is most management teams first look at the people as the key to solving their most pressing problems.  “If we only had better people things wouldn’t be this bad.”

Don’t believe it. We have good people in our industry. The people in our industry are smart, dedicated, educated, and diligent. It’s not about the people.

When the Standish Group measures our industry and catalogs the top reasons software projects fail, competent staff often falls toward the bottom of that list. This resonates with me.  In fact, the Standish Group suggests that replacing your staff with even more competent people might only move your Successmeter by 5%.  Why? Because we already have competent staff on our teams. It’s not about the people.

One of the most intriguing stories I’ve heard along these lines is the story of the NUMMI Plant in Freemont, California, a joint-venture between Toyota and General Motors. Anyone who is interested in the effect of process on results should listen to this NPR story. This story outlines how in the 1980s the worst performing plant in GM history became the best performing plant.  Same people. Same machines. Same plant. Different methods and different measurement systems made all the difference.

We see the same effects here at Menlo. We often refer to ourselves as a refugee camp from an industry gone very very bad.  We are able to take members of  teams performing below industry standards and quickly assimilate them into our team. Their enthusiasm, energy, motivation, and productivity immediately rise. Same people, different process.

It’s not about the people. As you consider how you might make things better at your company, don’t start by looking at the people. Start by looking at yourself and then look at your process. The payoffs aren’t just in higher productivity and better quality, but also in a better life for you and your team.

We believe it is possible to have joy in software design and development. We hope the same for you.

Comments (1)

By Rich, April 8, 2010 6:00 am

The software development team at Menlo does not comment their code.

This revelation confirms the greatest suspicion most newcomers have about agile: “Agile means you no longer have to do documentation.” Given the mainstay of our business is creating intellectual property for others, this is often surprising to those who marvel both at our business success as well as the unprecedented level of quality and maintainability of the code we write.

The best way to describe this is to tell a real-life story.

I was teaching our one-day Agile Explained course to an IT team from a large financial services firm.  This firm has over 7,000 employees in their IT team. A question arose about our team’s coding standards. I explained that our team does not comment the code they write.

“If they don’t comment the code, how can anyone maintain it once it’s in production?”

It was a great question and one I decided to let their own team answer. Several students in the class were part of the company’s so-called “break-fix” team. Their job when the code breaks? Fix it.

I asked them, “When the code breaks, I assume you have 3 sources of information to inform your fix. Documents on the shelf. Comments in the code. The code itself.” They agreed. Did they run towards the documents? No. “The documents are always out of date.” Did they seek to understand the code by reading the comments? No. They’ve had too many experiences where the comments didn’t match the code because there wasn’t time to get them back into sync. The only documentation they could trust was the code itself.

We agree.

Our goal is to make the code humanly readable. We do this by using long variable names, long method names, methods that never span more than 1 screen, having a common coding standard that everyone follows, pair programming, practicing code stewardship (as opposed to code ownership), and refactoring mercilessly to increase understanding.

Simply put, no comments does not equal no documentation. The combination of automated unit tests and humanly readable code (created by a team that believes in this approach) results in higher quality and more maintainable code than any other system we have encountered in our careers.

What evidence do we have that this works? We’ve talked about it before: our phone doesn’t ring with support calls and we receive great word of mouth from people who use the software we create. We consider these our best measures of success.

Comments (3)

By Rich, March 1, 2010 1:13 pm

Even the most skeptical of our tour visitors sense both our passion and our enthusiasm for what happens in the Menlo Software Factory™.  However, a common question they ask is, “Do you have any data to show me that this actually works better than traditional approaches?”

I must admit my first reaction to this question is usually an unspoken emotional response along the lines of “You’ve got to be kidding. Can’t you just see the difference?” Sometimes it moves from emotional to reactionary as I want to ask them, “If I collect the data and show it to you, what will you compare it to in your world?”

I never actually verbalized either of these emotional responses and it wasn’t until last week when I received another version of this question via email, did I actually go and get some data and report it back. I thought you might enjoy peeking in on the interaction:

Hello Richard.

…  I would be interested in any metrics you may have collected on your teams performance. Such as defect rate (defects per KLOC [defects per thousand lines of code]) and output performance (i.e. lines of code per day).

To which I responded:

Interesting question about lines of code per day.  As part of our engineering practice, we actually value fewer lines of code rather than more.   By analogy, it is like the old quote “I was going to write you a short letter, but I didn’t have time, so I wrote you a long one.”

We often are able to add features by reducing the number of lines of code.  Counter intuitive, but powerful in both elegance, simplicity and quality.  Fewer lines of code to maintain, fewer “moving parts”, etc.  The other interesting statistic is that about 50%-60% of the “lines of code” we write are automated unit tests which are written BEFORE we write the production code they are going to test.  In addition to this being a phenomenal automated test approach, this is also a powerful act of very intentional design (i.e. you can’t devise a test strategy without conceiving the design of the code and that design most be modular so that it CAN be tested).  These lines of code are not shipped with the production product.

Regarding defect rate, I asked one of our project managers to take the total hours of one of our larger projects and separate out the number of hours spent working on “bug” cards.

Here’s the calculation:  669.25 hours working on bugs divided by 17,592.50 hours working on all (features and fixes) development.  Total percentage of time working on bugs is 3.8%.   Thanks for asking the question, as we’ve never had one of our clients ask for this.   Even I was impressed with the result!  I am going to ask this question of our other projects.  Happy to share those answers with you if you like.

Hope this helps.  Best wishes to you as well!

I’d be interested in hearing your thoughts on these performance metrics. What measurements have you done to demonstrate the effectiveness of your team? What measurements would you be interested in hearing more about?

Comments (0)

By Rich, January 11, 2010 8:00 am

It’s been almost 40 years since I typed in a 2 line program on a 10 CPS Teletype and the computer responded, “Hi Rich.”

I’ve witnessed many magical moments since then and even though I understand how computers work, there are still times that take my breath away when it comes to technology. The first one of those occurred in 1994 when my wife asked me to “search the Internet” for an article on “knowledge workers.” I assured her that was not how computers worked. To humor her request, I fired up the brand new Mosaic browser (as part of the Prodigy service), and typed in “Knowledge Workers.” To my amazement she got exactly what she needed. She asked for a printout and thanked me for my help. I tried to explain to her that a miracle had just occurred. She was confused, “Isn’t that the way computers are supposed to work?” I said, “Yes, but they don’t.” Having spent much of my career trying to get IBM mainframes and personal computers to do the simplest of communications in the most complex ways imaginable, the elegant simplicity of the Web astounded me.

A few years later I came home and was greeted excitedly by my oldest daughter, who was sitting at our home computer pronouncing, “Dad! You’ll never believe this! You can get any song you want for free!” I assured her that was not how computers worked. She ignored me and said, “Tell me the name of a song…” Determined to convince her that what she thought she was seeing wasn’t true, I picked an oldie but a goodie, “Bend Me, Shape Me” by the American Breed, one of my favorites from the sixties. She asked me which of the 35 versions that appeared did I want to download?

Just recently I witnessed an equally powerful, albeit not quite so “magical” moment. My oldest daughter had just bought her first car and she was looking for insurance. While I was imagining a Saturday trip to AAA, she had a different approach in mind. She went to the Web and brought up the AAA website.  She was convinced she could buy auto insurance online. I was dubious. AAA proved me right, she needed to visit the office to complete the transaction. Undaunted, she tried State Farm.  This experience was much better, and yet, at the key moment where she pushed the button to purchase the policy, the website failed and the transaction was not completed. At this point she brought up the website for Progressive. It seamlessly and effortlessly completed the transaction in just a few minutes. The experience was so smooth and enjoyable, I believe Progressive has a new customer for life.  At 25 years old, she is likely going to spend a lot of future dollars with Progressive; dollars that won’t be spent with AAA or State Farm.

The lesson of this experience is fundamentally important to all business. The cost of switching now approaches zero. The only effort my daughter had to expend was the effort to type in a new web address for a different company. Her expectations, set over the years by her experiences with Google, Apple, and yes — even Napster in the early days — have created a very sophisticated and demanding user. Companies that get this will thrive. Companies that don’t will not survive.

Menlo’s High-Tech Anthropologists® understand this fundamental principle of modern commerce. The world has changed and we must change with it. Failure to understand this change will bring down mighty institutions, even ones that have lived for decades.

Comments (0)

By Rich, December 23, 2009 10:59 am

While we would never even suggest there aren’t competent alternatives to using Menlo Innovations for user experience design and software development, I want to give you some insight on some common “pathologies” we see when people come to us.

Imagine Menlo was the not the first place you approached.  This is often the case with many who find us after they’ve tried one or more other avenues before they discover us.

Here are some common scenarios:

1.  They found a family friend who had some extra time and was willing to work very cheaply or even just for equity.

Common results:

a.  Friend’s life changed in the middle of the project (married, moved to another locale, etc.) and the project stopped mid-stream.  Because the friend worked alone, no one is quite sure where the latest copy of the software is located.  The friend was a brilliant programmer, but not very organized.

b.  Wasn’t actually that good a friend, more of an acquaintance of a friend and the business relationship wasn’t that well defined and now there are serious IP ownership questions.  It’s amazing to us how often the question of “who owns the code” is not an easy one to answer.

c.  Friend was willing to do the work for a low fixed price (say $20K), with half up front and half upon completion.  Things got off to a good start and then the friend stopped returning phone calls.  Then another friend was found who made the same promise.  The same results occurred the second time!  When they approached Menlo, they asked if we would do the same thing.  We said no and informed them it actually looked more like a $200K project.  They were adamant it was a $20K project because these two friends told them it was.  We interpreted the prior behavior and told them them that both friends eventually told them just the opposite when they realized they were working for less than minimum wage!

2.  Competent, well-know India offshore firm is contracted once client realized that Menlo’s estimate was 20,000 hours when offshore firm said they could do it in 4,000 hours.  The client needed the project done in less than 6 months.  India firm promised fixed price within timeline.  That was 4 years ago.  Still not done.  Client has had to invest thousands of their own team’s hours just doing QA testing.  I think they managed to avoid getting the lawyers involved, but it was touch and go.

3.  Friends scoff at Menlo estimate, saying they can do the project in less than 10% of the hours we predict.  We suggest they use those friends.  Friends say they are too busy right now.

4.  Friends point to myriad of open source tools available to make this a project of snapping together publicly available (and free) software components.  After $2M of development to “snap pieces together” project collapses under the weight of the competing bugs in all of the open source pieces.  Its not that open source can’t work … its just not free and you have to decide which of the hundreds of reported bugs you can live with, which ones you will choose to fix yourself, whether you wish to donate those fixes back to the open source community or keep them to yourselves, thereby inheriting the code to extend and maintain yourself, or whether you can simply wait for someone else in the community to fix them.

5.  Friends point to other systems that are already up and working as evidence of how easy this is to do.  We ask for an estimate of the effort to build those other sites and the friends aren’t sure, but they are certain is was easy.

The stories I reference above are real stories we have directly heard from people who have walked in our door over the years.  This is only a small sampling of them as well.

Our goal is not to frighten prospects away from pursuing their own projects. It’s just that professionally building software that works well, scales and is easy to navigate and thrilling to use is just plain old everyday hard work.  There are no short cuts to quality and software is just as hard as any other engineering discipline.

Take heed! There be dragons!

Comments (3)

By Tracy, December 10, 2009 8:00 am

There is a good chance that those who follow team sports closely would be able to name at least one team that actually got worse after hiring a star player.  If they have trouble, they might be able to name at least one team that looks fantastic on paper but just can’t quite deliver.  If we looked at these teams closely we would find that root cause of their inability to perform is an inability to behave as a team.  We can see it on the field as they play.  Each person seems to be acting independently.  Each player has their own goals or their own idea of how the game should be played.  There is nothing to unify them.  There is no common purpose.

Games are not won by an individual on a team.  Games are won by the team.  We all know this to be true for athletics.  Why is it any different for project teams?  We expect our athletic teams to practice together.  We expect them to set a common goal, to push each other outside their comfort zone, to be there to help each other out.  Shouldn’t we expect the same of our project teams?  Yet somehow the culture we build within business fosters the opposite.  Somehow we concentrate on individual performance rather than team performance.  We look for superstars rather than team players.  We stretch communication lines further apart rather than bringing them together.  We hinder the team’s ability to be a team.

Imagine what would happen if we asked a baseball team to practice on different fields.  All pitchers practice on field A, catchers on field B, infielders on field C, outfielders on field D.  It sounds absurd and yet this is what we ask of our project teams.  We put project managers on their own floor.  Business analysts are in a different building.  Quality assurance is in the basement, the development team is off in another country.  They all work on the same project and are expected to work towards a common goal.  How can this be?

This is not to say there aren’t successful project teams.  There are plenty but we certainly do a good job of making success painfully difficult for them.  In an industry where billion dollar projects are shelved in an instant, where ideas are outdated before they see the light of day, we have got to dismantle the barriers and build teams.

Demming said quality can’t be put in after the fact.  It must be built in from the beginning.  I say the only way to be successful at it is for all members of the team to recognize quality as a goal and the role they each play in realizing this goal.  Quality is not for heroes.  Quality takes a team.

Comments (0)

By Rich, December 3, 2009 8:00 am

In a previous post I talked about how empowerment is one of the most overworked words in management today. Right near the top of that same list is “accountability.” I shudder every time I hear someone in management say “We need greater accountability in our team!” The reason I shudder is because it implies that accountability is a one way street, when in fact for accountability to work it must be a circle.

What do I mean by that?

I want to discuss with you accountability at Menlo around estimating. When people first learn about our weekly estimating practice, the question invariably arises, “What do you do when people don’t hit their estimates?” The answer I give is not what they expect.

I first talk about how we teach accountability around estimating to our team members, and it always occurs in the setting of a public class where Menlonians and clients are both present.

I start with my accountability as a CEO to my team. I do this by declaring to my developers that we will never punish anyone for missing an estimate.

Ever.

I then turn to our project managers and tell them they are never to punish, cajole, or intimidate any of our developers about missed estimates.

I then turn to our clients and say, “By the way, if we go over our estimates, you will pay for the additional hours logged against that story card.” You can imagine the burning question on the client’s mind is either “Why am I here?” or “What’s in it for me?”

This is where the circle must be completed to make accountability work.

I then turn back to my developers and say to them, “There’s one thing I need from you, and only one thing. As soon as you think you’re going to exceed your estimate, raise your hand and declare it to your project manager.” We have actually taught our project managers to say, “Thank you.” (No, really. They say it!) I tell them that it’s okay to ask about their revised estimate, and discuss its implications, but at no point in this conversation is anyone allowed to say, “No. You just need to meet your estimates.”

Armed with the understanding of why the new estimate is now more accurate, the project manager is then taught they must call the client and deliver the news. We don’t assume that the client wants the story card completed at any cost, so we ask them, “What would you like to do?” There are many choices here, including: 1) just keep going and we’ll pull something off the end of the iteration, 2) stop working on the card because the new cost for that story card is not in line with the value it would produce, 3) we review alternative approaches (i.e. new story cards) that may reduce the effort while producing a similar amount of value in a different way than originally planned, or 4) something else. This approach affirms one of our most common statements about agile: Agile doesn’t solve problems, it exposes them sooner so that we can deal with them while there is still time and budget to do so.

So what does the customer get out of this?

In a trusted system of estimating our developers will estimate more aggressively with no padding, and human nature says that our developers will strive to meet or beat an estimate they had a hand in creating. People do miss estimates, and when they do we deal with it in a healthy, professional way. Ultimately the client will get more work done in the same amount of time, which is what every client wants.

I teach this system wherever I go. I can recall a rather tense moment in a class I was teaching in Atlanta, where a VP of Marketing silenced a room by declaring, “This is bullsh*t. Here our people are expected to meet or beat their estimates every time.” I asked him, “And if they don’t, what happens?” He said, “Then they stay late. They come in on the weekend. They forgo holidays. They are responsible for making it work.”

I then asked him the magical question, “What do you think the effect of your system is?” I literally watched his face change from anger to understanding. He said, “Quality will suffer. Morale will drop. People will quit. Those that don’t quit have quit in their minds, but are still on the payroll.”

I caught up with members of his team years later and they said to me, he literally changed that day. He was a different manager from that day forward. I believe estimating, and how it is handled, is one of the most vexing problems of our industry. At the heart of this problem is how we as managers view accountability.

We seldom consider that accountability must begin with us for it to work.

Comments (0)

By Tracy, November 25, 2009 8:00 am

In my first post talking about the 18 steps of quality, I talked about the first 7 steps we use to ensure quality. Today I’m going to talk about the final eleven items.

8.  Iteration Kickoff
9.  Estimation

At Menlo both of these exercises happen during each weeklong iteration.  Every week the team has two opportunities to come together and discuss the big picture.  Unless everyone on the team is focused on a common goal it will be impossible to build a quality product.  Spending the time to communicate up front to make sure the team is on the same path, prevents many defects from ever making their way into the system.

10. Continuous Code Review
11. Test First/Unit Testing
12. Continuous Integration
13. Refactoring

We have a tremendously rigorous set of development practices.  These are not practices we use sometimes or when we feel like it or remember to.  These are part of the code of ethics we live by.  An application written without unit tests, continuous code review, continuous integration, and fearless refactoring is an application written to be thrown away.  Where there is rigor there is quality.

14. Green Dotting

At Menlo no one is allowed to declare themselves done with a story card.  Instead they have to ask their teammates to verify if they are done with the work.  We call this green dotting.  A simple way to increase the quality of your work is to have someone else check it before you move on to something new.

15. Show & Tell

Every week our client comes in for show and tell. This is a chance for the client to see the working product to make sure it is everything they imagined it to be.  If something isn’t quite right, it is only a week spent off course rather than months or even years.  Quality is so much more than answering the question of whether or not the application meets the specifications.  The earlier you can get someone actually using the software being built, the better.

16. Build Testing

Every iteration we make a build.  Every iteration we run a build test.  For this we use exploratory testing.  The objective is for the build testing team to put their end user hats on and use the application as a user would.  There is no list of instructions for them to follow.  On the contrary we want them to explore.  We want them to be creative and most importantly we want them to run the test differently from the week before.

17. Client Testing
18. Beta Testing

We encourage our clients to also test the application.  Since we do not typically have a domain expert on staff, we encourage our clients to designate one to testing the application whenever possible.  We also encourage them to find a small group of beta testers within their clients.  The earlier you can acquire feedback from real users, the more time you have to make the appropriate changes to the product.

Now you know our 18 steps to quality and why our phones don’t ring with support calls and why we don’t have a bug database full of thousands of bugs.  Now you know why the end users of the products we build find them to be easy to use and why so many of our clients find their products quickly gain widespread adoption.  Use our 18 steps.  Make them your own and believe me when I say, it is fun to build something packed full of quality.

Comments (3)

By Rich, November 16, 2009 12:23 pm

I’m going to reveal a truth to you that many in business would prefer you not know: Fixed price bids are a lie, especially in IT.

A few years ago I had the opportunity to explore the world of fixed price bids with an architect (a real architect, someone who designs buildings). I told him I was intrigued about “fixed bids” on construction projects as I am constantly challenged by people, particularly those critical of agile, that business requires fixed price bids for software projects. So I asked him, “How does fixed price work in construction?” What he described fascinated me, particularly for government projects.

He said the process is quite simple and straight-forward. An RFP is issued, sealed fixed bids are collected, the sealed bids are opened and the lowest price wins.

Puzzled, I said, “It couldn’t possibly work this way.” He said, “That’s exactly the way it works.”

Applying my engineering mindset, I said, “Then the specs in the RFP must be incredibly detailed.” He smiled and said, “No. In fact, the more ambiguous the spec, the lower the bid.”

I was incredulous, how could it possibly work this way? He went on to explain by simple example: “Let’s say the spec called for toilets on every floor. It didn’t say flush toilets. So we lower the price.” Thinking this through, I said, “That must mean lawyers get involved every step of the way.” He said, “Absolutely. We change order them to death.”

Thinking about this I realized why fixed bids do not work in the software industry. We don’t have the stomach for such conflict. If the spec called for toilets, we’d put in electronic toilets that give us health reports every time we use them.

Herein lies the power of agile: fixed budget projects that focus on scope management in order to achieve the highest possible business value within a budget and time frame. What does it take for this to work? A real and authentic relationship between the technical team and the business team. No longer do spec documents, stage gates, and committee meetings give both teams places to hide while projects spin out of control.

The lie of fixed price bids for software projects starts at the very beginning. A business sponsor approaches a technical team and begins to describe how simple the project is going to be. The technical team does just the opposite. Somewhere in the middle lies the truth, but the clever negotiator carries the day and believes they’ve gotten away with something. Once the negotiation is complete, the sponsor walks away believing they have successfully contained all of the risk of the project. Sadly we have watched this play out over and over again in our industry to the tune of billions and billions of dollars spent on failed software initiatives.

Most people want to believe that a firm and fixed price can be established for an innovative new software effort at the beginning of the project when we know the least. The advent of inexpensive off-shore labor made this problem worse rather than better. Business sponsors, armed with a new, inexpensive tool for software development, paid even less attention to the intermediate artifacts of a project. Let me describe an example.

Menlo was approached to respond to an RFP for the rebuild of an existing system. Our first response was to tell them that we do not respond to RFPs, which intrigued them.  They knew enough about us to implore us to respond. Before we invested too much into a response, we provided them an estimate of effort for the project of between 8,000 and 20,000 hours, based on what they had described. (We were able to do this because we track all actuals on every project we work on. We have 8 years of data we can use to establish comparable projects.) They assured us they had done their own internal estimate and had a prominent offshore firm confirm their internal estimate of 4,000 hours for this project.

We declined to bid.

That project was supposed to complete in six months. I have spoken with them recently and it still isn’t finished four years later. They have invested thousands of hours of their own time doing just the quality assurance on the work performed offshore. In personal and painful discussions with their CEO, he has commented to me, “Rich, I will never choose the lowest bidder again.”

Our experience tells us that our best clients are ones who have experienced this pain somewhere in their careers, often at a former employer who is no longer in business. Designing and building software requires full spectrum engagement and relationship-building that typically does not exist in business. When properly applied, agile gives us that opportunity.

Comments (2)

By Lisamarie, November 12, 2009 2:35 pm

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.