If I had to pick one flaw in the geek culture, it’s the lack of respect for the effort it takes to get people to use your software. Take any geek, point them at a successful product with lots of users like Facebook and they will talk about its limitations and how they could code up a better product over the weekend. It is not the technology that makes products like Facebook a success but rather the endless effort to get people to use them. Even if they could code up a better Facebook over the weekend, who would use it?

When business people talk about distribution they are referring to not only how many stores the product is in but, as in the case of software, how many users are actually using the product. The greater the distribution the more valuable the business. Make no mistake, try to sell a business that has no distribution and there will be surprisingly little interest.

And much to the frustration of the software purest, most products with distribution tend to be technically inferior. A widely cited example among the tech community is Microsoft Windows—which is generally seen as technically inferior to Linux. Although this can be debated, what everyone can agree on is Windows has distribution and Linux doesn‘t.

Ever stand behind some rental car place and peer over the counter to take a peak at the software only to be greeted by a blue screen running some DOS app and while the poor employee struggles to enter your information into line 64, your mind starts thinking about how you could create an awesome WPF application and make millions selling it to these poor technology illiterate people. Surely they wouldn’t say no.

But then they say no.

Recently, I tried a little experiment. I noticed the forum software my Home Owners Association was using was lacking. I explored other HOA forums and noticed that not only did my HOA forum need help but other neighborhoods as well. They were using software that looked years outdated like FUDForum and the notorious phpBB and like the rental car DOS app experience above, I thought I could do better and over a couple months in my spare time I coded one up in ASP.NET MVC. It included features like an HOA corner where HOA members could post events, topic and response voting, a hot section that ranked active topics, and a snappy design.

I had confidence my neighborhood would adopt it so I fired off an email to the HOA members with a link to the demo site. Not known for their promptness, I wasn’t initially worried by the long delayed response but when the response finally came I became concerned. There in front of my eyes was a response I was not anticipating. It simply stated that the HOA had a forum already—as if I didn’t know—and they hadn’t received any complaints about it. They closed by thanking me for the thought and as quickly as the email began it was over.

Not completely dejected—and still thinking someone out there must want to use it—I tried other local neighborhoods. If my own HOA response was unexpected the others proved to be also. No interest even though it was free.

What I had failed to anticipate was not the failure of adoption due to lack of features but rather the total lack of interest. No one would even try the thing out and as I began to think about why that was, I began to see that my software failed to solve any real problems the HOA was having. What I thought were problems turned out to be non issues. It was as if I was trying to sell pay-off-your-debt software to multi billionaires.

And the more I thought about the lack of adoption the more I came to the conclusion that I didn’t even know what HOA organizations did. I just saw some issues I thought were problems and coded some software that solved those problems and then expected everyone to jump on board.

It turns out, the real secret to getting adoption and hence distribution is to find real business problems that can be solved by software. As I have demonstrated above and the number of failed startups can attest to, finding a problem and solving it well enough that someone desperate enough for a solution will take a change on your unknown software and try it out is extremely hard.

It is better to be a person that knows of a problem that can be solved by software than a software engineer with skills to create a program that solves no problems.

Few things frustrate more than driving that shiny new sports car home from the car lot with a sinking feeling of knowing you didn’t get the best deal. If there is one mistake we make, it is not respecting the salesman ability to influence our decisions.

To the trained, these techniques are well known and used not just by shady car salesman but by business leaders as well. Unlike harsh techniques like yelling, these play on our natural human instincts. Instincts as basic as to fit in and be liked. Used effectively, they can cause us to make decisions that we might not otherwise make.

The book Influence: The Psychology of Persuasion outlines these techniques. It is important to learn not only how to recognize when we are being put under the magic spell but also to cast it.

Contrast Principle

In a world of constant competition we learn to compare. We compare our houses, academic grades, athletic ability, and professional success to others. These comparisons—although sometimes unfair—allow us to measure where we stand relative to others.

But while these comparisons help gauge our progress they can also work against us. What salesman and others know that we don’t is when comparing two different things presented one after another and the difference between them is large we tend to perceive them as more different than they really are.

This weakness becomes more apparent with some examples. A study was done where college students were asked to rank average looking members of the opposite sex after looking through ads in some popular magazines. Their attractiveness was ranked lower by the ones who first looked through the magazine of models than by others who didn’t.

Placing a subjects two hands in buckets of water, one of which is hot and the other which is cold and then putting both hands into lukewarm water makes the lukewarm water feel cold by the warm hand and warm by the cold hand.

What both these examples make clear is the second comparison can be drastically affected by the first. But what is more frightening than these harmless studies is what can be accomplished in the hands of those with more sinister intentions. Retail stores, for example, are taught to show the most expensive item first and then move to less expensive items. This makes the later items seem cheaper than they may be. Some realtors keep overpriced run down homes—that they have no intention to sell—to show first thus making later average looking homes seem like glorious mansions.

Car dealerships understand that once you are committed to buying a car, little add on accessories that might otherwise seem very expensive on their own are now less so. After spending $15 grand on a car, what is $500 more for window tinting or that flashy racing spoiler.

Reciprocation

Who doesn’t like a nice gift. But that innocent little gift comes with a steep price. Those who want the law of reciprocity to work for them understand that humans who receive something for nothing have a desire to repay the gift sometimes by giving more in return.

A simple experiment shows the power of reciprocity. In the experiment two individuals were part of a study about rating paintings, however, the study was not about paintings but the effects of reciprocity. One of the participates after a short break bought himself and the other participant a Coke and when the session was over asked a favor of the other. He was selling tickets for a raffle at 25 cents a piece and if he sold the most he would win a 50 dollar prize. The participants who received a Coke bought twice as many tickets as those that didn’t with some buying as many as seven. With Coke costing just 10 cents, the deal was well worth it.

While pushing Coke and raffle tickets shows that reciprocation works, a little known variant called rejection-than-retreat can be just as effective. It combines reciprocation with the contrast principle to produce a surprisingly potent rule.

Rejection-than-retreat starts by proposing an offer that will most likely be rejected and then immediately offering a smaller offer. The smaller offer is a concession that in some weird psychotic way we want to reciprocate. If the reciprocate rule doesn’t do us in, the contrast rule quickly will because the second offer is smaller than the first thus making it look much smaller that it really is.

Of all the ways the rejection-then-retreat rule is deployed none is more effective than the selling of extended warranties. If the salesman is any good the rule is played by offering you some overly expensive warranty plan that most reject off hand. After the rejection, a second more reasonable offer is made. The reciprocation and contrast rule are both in play making the offer hard to resist. Very high success rates of 70% or more have been achieved by using this tactic alone. 

Commitment

It is human nature that once we commit to a plan of action we are very likely to follow through. The principle multiplies in effectiveness if the commitment is made in writing or publicly.

During the Korean war many Americans found themselves prisoners or war in the communist China camps. The Chinese knew about the power of commitment and got the Americans to first admit little things like: America isn’t perfect. Then they were pushed to elaborate reasons why and asked to make a list and sign their name. The commitment starts little and expands until the Americans start to defend their commitment to others.

Tactics used by the Chinese are also used by companies to gain better customer loyalty. Many companies like Proctor and Gamble have product praising essay writing contests—which to the untrained eye looked cheesy—that have proven effective in increasing customer loyalty.

Yet of all the ways to get a commitment, none are more effective than the well known low ball technique. Auto sales are masters of this technique which starts with a low price. The customer than becomes committed to buying the car as time passes. When the deal is ready to close, however, some error is discovered that raises the price a couple hundred dollars. You have already made the decision to buy the car and it takes Herculean effort to walk away from the deal.

Social Proof

The universal law of human behavior is if lots of people are doing something it tends to be the right thing. Salesman often recount endless tails of happy customers who have purchased the same product you are considering buying. Restaurants have been known to limit seating so long lines form outside giving passer-byers the proof of its popularity. Online forums and communities are often seeded with topics to give the impression of importance.

Scarcity

Of all the laws presented above, the law of scarcity is perhaps the most effective. There is no greater draw then to be told you can’t have something.

The game is typically played by retailers by first noticing that a customer is interested in a particular item. Then the salesman—to increase interest in the item—informs them the item is a great item but unfortunately the last one was just sold. The scarcity of the item increases the desire to buy. Miraculously, upon seeing intensified interested from the customer further investigation reveals one is located in stock after all.

The best technique, however, I have heard for utilizing the law of scarcity effectively is from a guy trying to sell his used car. To make the item appear scarce, he double books appointments to show off the car. When the second person arrives on scene to find another looking over the car he is informed to wait his turn while the first person looks it over. The first person seeing the second, becomes more interested in the car. The car becomes a scarce resource and competition increases. Between the two of them they have no hope and quickly cave to the law of scarcity.

Few companies could compete with Bucyrus Erie in the early half of the twentieth century. Their cable pulley excavators powered by gas engines—capable of holding up to 5 cubic yards in their massive steal jaws—where vital to the mining, canal digging, sewer and piping industries. Ironically, their biggest competition threat would not come from other ambitions pulley excavators but from a little company called Sherman which was pushing a small hydraulic shovel that moved a puny ¼ cubic yards and attached to a farm tracker. They named it the backhoe.

The backhoe began innocently enough with the invention of hydraulic technology in the late 1940’s. Lacking the earth moving capacity and distribution of Bucyrus, companies like Sherman designed their backhoes to be compatible with popular farm tractors of the day like John Deere. Unexpectedly, the backhoes found a devoted following with residential contractors who appreciated their maneuverability allowing them to squeeze between houses to dig water and sewage lines. Without the machines, the trenches had to be dug by hand which made even the most devoted ditch digger want to beat themselves senseless with their own shovel.

If Bucyrus was afraid of the hydraulic threat, it didn’t show it. Bucyrus viewed the cute backhoes as too wimpy for their customers needs. Their customers, after all, were demanding bigger bucket sizes that hydraulics couldn’t match so Bucyrus continued investing in cable technology to meet existing customer needs.

And while Bucyrus was putting their best engineers minds to work squeezing more tension out of those steal cables, other smaller companies like Caterpillar took notice. With Caterpillar and others pushing hydraulics they improved at an astonishing rate. In 1955 bucket size was 3/8 cubic yards, ½ cubic yards by 1960, and 2 cubic yards by 1965. Only 9 years later in 1974 bucket size reached 10 cubic yards and continued to climb skyward. It was as if Caterpillar showed up one day in front of Bucyrus headquarters with a 10 cubic yard hydraulic machine and offered to dig their sewage lines.

In reality, Bucyrus knew all about hydraulics they just didn’t care. Only after hydraulics capacity reached 2 cubic yards did things began to go south. At that size, sewer and pipe contractors became interested for the first time and with sewer and pipe contractors representing a good chunk of their business they began to lose revenue. Even worse, at 5 cubic yards hydraulics started to dig into their prime business of general excavators. How did this happen?

To outside observers the Bucyrus dilemma seems easily preventable. For starters, they could have invested in hydraulics technology earlier allowing them to build up their expertise. With this expertise they would be better able to compete in the new hydraulic market when hydraulics reached sizes their customers cared about.

This criticism is justified but the answers are not clear cut. When hydraulics first came out their usefulness was unclear. At ¼ cubic yards their functionality was limited to small markets. After years of doing business, Bucyrus had built up a cost structure that needed certain revenues to sustain. The hydraulic market initially was not big enough to justify significant investment from them. The revenue generated would be small at best when compared to their cost structure so Bucyrus felt their resources would be better spent improving their existing products. After all, no one knew if hydraulics would continue to improve.

The uncertainly around how disruptive technology will improve and whether established businesses should invest is a hard decision to make. In the book Innovator’s Dilemma, Clayton Christensen describes the struggles business leaders face when confronting disruptive technology like Bucyrus faced with hydraulics. In one part, Clayton describes that during the 80’s established computer disk drive companies where being attacked by disruptive upstarts sporting sexy smaller drives. One of those established companies, Seagate, was struggling in 1985 with whether to make 3.5-inch drives when they were already the leader in 5.25-inch drives.

Seagate was confronted with this decision when overly ambitious engineers developed working 3.5-inch prototype drives. Seagate marketing showed the drives to IBM PC division even though the capacity was clearly lacking compared to the existing 5.25-inch drives. IBM was not interested as their computers were designed for 5.25-inch drives and they were looking for greater capacity not less. As a former Seagate manager put it: “We needed a new model which could become the next ST412—a very successful product generating $300 million sales annually in the desktop market that was near the end of its life cycle. Our forecasts for the 3.5-inch drives were under $50 million because the laptop market was just emerging, and the 3.5-inch product just didn’t fit the bill.”

Seagate scrapped the 3.5-inch drive and paid dearly for it later as the drives got more popular. But here lies the crux of the dilemma. As firms get bigger their cost structures get bigger thus making it harder to innovate. Disruptive technologies have uncertain markets with low margins which established firms don’t like because they are liable to their share holders to grow and make more money. It is hard to justify dabbling in low margin uncertain markets when existing products with known markets and large margins can be improved.

So ironically, as companies get bigger they become more vulnerable to being attacked from below by small innovative firms. Lower cost structures allow startups to experiment with new technology. This is why innovation typically comes from small firms. If the technology improves, it finds new markets and can—as we saw with Bucyrus—began to steal away customers from established firms. If enough customers are stolen, the established firm will go out of business. This often happens and why we see large companies fail.

Even today, a glance at Bucyrus website reveals it still hasn’t penetrated the hydraulic market. Caterpillar has that covered.

In my family—in laws included—I am the engineer weirdo performing voodoo magic to make computers do things. The majority work in business related fields and tout MBA degrees with years of experience to back them up but somehow still think that no matter where I work the company must be creating some kind of operating system. In this type of family environment discussions consist not only of how are the kids or pass the mashed potatoes but things like calculating percents—like say 35% of 60—or calculating how much money will appreciate at 8% over 30 years. If there is one thing I have learned it’s that nothing will bring quicker looks of disdain then to trip up calculating percents to the exact number. Close enough doesn’t cut it.

At first, I didn’t know whether to feel disturbed or envious at the speed at which these calculations came spewing out of their mouths like hungry bats emerging for a night feed. The disturbed part of me felt they had spent way too much time practicing the skill; after all, anyone could grab a calculator to do the same thing. The envious part of me couldn’t help but admire it for a computer program would be hard pressed to beat them. Still, I couldn’t pinpoint why this was so important.

Years later, while reading business books, it dawned on me that in the world of understanding how businesses work calculating percentages is essential. Not knowing them would be like coming across a program without for loops causing the intelligence of the author to be questioned.

And like for loops in programs, percents are everywhere in business. What percent of revenue is spent on R&D vs. Sales vs. Marketing? How do those percents compare to our competitors? What percent is our revenue going to increase? Every thought and comparison is expressed as a percent. Spend any time studying financial statements and there is no way to escape them.

Despite this, it took me—who took many courses in calculus and physics—years before I understood how to calculate a 15% tip in my head. Shamefully, I have found that many engineers also struggle with this skill. It is time we stop being shown up by our business associates and learn how to calculate percents and value appreciation in our heads without the help of our favorite programming language.

Percent calculation

Remember Chunk from the 80’s movie "The Goonies". His name not his character—the paranoid husky kid who would rather be eating rocky road ice cream than contributing to the goal of finding the treasure of one-eyed Willie—holds the secret to calculating percents in your head. The technique that resembles his name, called chunking, is commonly applied to memorizing numbers by breaking the problem into groups. Like numbers, percent calculation can be broken down into groups to simplify things.

First rule of percent chunking is 10%. 10% is easy to calculate because you move the decimal one place to the left. To reach 1% you simple do the 10% calculation twice in your head resulting in the decimal place moving two times to the left.  Calculating 5% is easy once you have the 10% number because you just divide it in half.

In our example above of taking 35% of 60 we first take 10% which is 6—simply move the decimal place of 60.0 one to the left. Now, we multiply that number by 3 to get to the 30% number of 18. We know that 5% is just half of 10% which is 3 in our case. Add that to 18 and we get the final answer of 21. So mathematically this can be chunked like: .35x = .30x + .05x = (.10*3*x) + (.10*(½)*x) = [(.10*x)*3] + [(.10*x)*(½)]. Substituting 60 in for x using the last equation gives us the same thought process previously worked through. The key is to master this chunking technique in your mind.

You can use subtraction as well. Say we want to calculate 18% of 95—which I just made up and figured to be 17.10. Here is the chunking equation: .18x = .20x - .02x = [[(.10*2)*x] - [(.10*.10)*2*x] = [(.10*x)*2] - [(.10*x)*.10*2] = (9.5*2) - [(9.5)*.10*2] = 19 – (.95*2) = 19 – 1.9 = 17.10.

Practice doing random problems in the shower every morning and at the very least you will amaze the helpless Gap employee who can’t seem to calculate 20% of anything without the register.

Value Appreciation

Calculating how your principle will grow after x years at y percent is easy if you know the secret Rule of 72. After discovering it on my own I would be lying if I didn’t admit I was angry at my family for not informing me of it.

The rule, which is surprisingly accurate and powerful, is simply: take 72 and divide it by the interested rate to get the number of years it will take to double. So back to our example of 30 years at 8% which is a common retirement account calculation. The rule of 72 says that at 8% your retirement money will double every 9 years—72 / 8 = 9. So if you have 20k in your account, in 27 years you should have 160k—3 doubles: 40k, 80k, and finally 160k. If the calculation is done manually—20k*1.08^27—it gives 159,761.

Thinking more about the rule will reveal some interesting facts beyond retirement appreciation. For example if inflation is 4% a year, how long will it take before prices double? The rule of 72 says 18 years; so in 18 years if your money just sits in an account somewhere earning meagerly interest its purchasing power will be cut in half. Even more depressing, that sweet little baby you hold in your arms now will grow up and when they are 18 years old and ready to go to college everything will be twice as expensive.

Bonus - Multiplication

Cost per month is a common price scheme; like a car payment of $250 per month. To calculate the price per year effectively in your head, it is important to move in chunks of 10. To do this, factor 250 into tens like 100*2.5 and then multiply by 12 to get final chunks of 12*100*2.5. Taking 12*100 gives 1200. We need 2 and a half of those. A half is 600 and 2x is 2400. Add them together to get 3000.

A better approach to the same problem is to rearrange the numbers like 100*(12*2.5). This allows the more complicated math to be done on small numbers which becomes more important as the numbers get larger. Thinking 2.5 times 12 is 30—[2*12]+[(½)*12]—then multiplying by 100 (or equivalently 10 two times) to get 3000 is easier than multiplying 12 by 100 and taking 2.5 of that.

A third option is to use elementary algebra and the distributive law like 12*250 = (10 + 2)*250 = (10*250) + (2*250). This gives us the nice number 10 in one factor and the low number of 2 in the other. The math from here is easy to do in your head. 2500+500 = 3000.

The three methods above were given not to show which one is better but to give three different methods for attacking multiplication. For certain numbers, a particular method may work better which makes knowing as many methods as possible essential for doing fast multiplication in your head.

One more example. Employees get paid $1500 a month and there are 550 of them. What is the expense per month? 100*15*100*5.5 = 100*10*10(15*5.5) = 1,000*10[(15*5) + (15*(½)] = 1000*10*82.5 = 10*82,500 = 825,000.

For years I made the same dull walk from my college apartment to campus and the only part of the walk that perked my interest was the daily charade that occurred outside the business building. Business students with their laptops, mochas, and Wall Street Journals hurried around as though they were late for an important board meeting obviously too busy to look up from their paper to make eye contact or smile. So pervasive was the attitude that even humble freshman couldn’t prevent their egos from tripling after spending an hour inside the business building with its huge foyer complete with fancy water fountains, nice leather lounge chairs, and offices engrained with titles on the doors.

I couldn’t help but feel slighted. The computer science building was a homely looking square building no doubt designed by an engineer trying to maximize space. The computer labs were located in the basement down a lonely stair case and no matter how hard I looked I was never able to find the leather chairs.

I spent many hours down in that basement banging on the keyboard coding quicksorts, binary trees, huffman codes, and traveling salesman. Sometimes when it got quiet and the hum of the many CPUs seemed to be playing the prelude from Bach’s Cello Suite No.1, I would think: What do those business students study all day anyways?

It was a few years into my career before I became curious enough to investigate. During the process, I became enamored with Joel Spolsky and found his recommended business books page which I quickly devoured. Of all those books none explained marketing concepts more concretely than 22 Immutable Laws of Marketing. Reading this book gave me more perspective than all those years walking by the business building. I will not go through all the laws just the ones I feel are most important.

The Law of Perception

Software engineers think the best code will win. This law says the real battle is not between code but how people perceive your product. Once someone develops an opinion of your product it’s impossible to change it. Take Honda for instance. In Japan, Honda is viewed as a motorcycle company and their cars do not sell well; however, in the US they do fine. Forget the product, the battle begins in the minds of customers.

The Law of Focus

The most important thing a product can do is own a single word in the mind of the customer. When they think of your product what word comes to mind? Prego spaghetti sauce got the upper hand on Ragu when Prego became synonymous with the word thicker which implies quality ingredients. Once thicker was owned by Prego, no other brand could use it because everyone knew thicker meant Prego. You cannot change the mind of the customer.

The Law of the Ladder

There is a natural ranking of products that all customers know. Knowing where your brand stands on the ladder should dictate the marketing strategy. Don’t claim to be #1 when everyone knows your not. This can only backfire. Interestingly, admitting your rank on the ladder can help as was the case with Avis. Their slogan—Avis is #2 and we try harder—greatly increases sales.

The Law of the Opposite

In the long run, the race becomes a battle between two brands. Think Coke/Pepsi, Scope/Listerine, and McDonalds/Burger King. The second place brand must not mimic the first but be opposite in some way. Some people don’t want to buy from the market leader so having a value proposition that is different attracts those types.

The Law of the Division

Every category over time splits into different vertical segments. Computers, for example, have developed many divisions like: mainframes, personal computers, laptops, tablets, netbooks, and now smart phones. Each separate computer division has its own market leader. This is a very powerful concept to understand because if a brand cannot compete with the market leader simply invent a new division of that category and plow ahead.

No industry understands this concept better than the beer industry. There is light beer, best imported beer, best domestic beer, and more recently low calorie beer. They even combine divisions to make best light imported beer or best light domestic beer. If there is one thing the beer industry has proven it's there is no limit to how a category can be sliced and diced.

The Law of Line Extension

Line extension is taking a successful product and introducing a new product around that same brand. Take A-1 steak sauce. The chicken market was growing and so A-1 poultry sauce was introduced with the thought that A-1 is so well known in the steak market people will want to use it for chicken. It was a complete disaster. Everyone knows A-1 is for steaks. 7-up also tried this same approach with Cherry 7-up. Same disastrous result. Line extensions don’t work. Instead, a new identity and brand must be created from scratch.

The Law of the Sacrifice

This law is similar to the previous one except it doesn’t apply to creating a new product but rather extending a brand beyond its identity. Federal Express was once known for overnight delivery but expanded their focus when they tried to capture more of the international market. The result was a company that lost its once strong identity of overnight delivery to become a company without one and lost a lot of money in the process.

Interestingly, Philip Morris did the opposite with Marlboro. It narrowed the focus from a general campaign to target both men and women to one that targets men only with a cowboy as the center piece no less. The result was a strong identity that helped Marlboro became the best selling cigarette for both men and women. A brand that stands for everything doesn’t work. In this law, less really is more.

Behind the sounds of keyboards clanging out lines of code and second hand Aeron chairs brushing against the floor lies the passion of a dedicated few bringing to market a product they believe customers will actually give them money for. Like a bird working feverishly to build its nest, they dig for ideas and scavenge for employees while carefully constructing their business plan. If they execute well and build the product they envision the market will reward them because the path is laid before them and all it takes is enough determination to navigate it.

Unfortunately, the path can fork and the very skills that entrepreneurs must have like self confidence and egotism can make it hard to recognize forks. Many get so emotionally invested in their idea that when sales fail to materialize they rationalize it away by thinking the next feature or sales pitch will make the difference. Their mind can become so clouded that they come to expect the market to care about their shiny new product as much as they do. In reality, the market is not interested in shiny objects but rather in how those shiny things solve their problems. Much to the dismay of the entrepreneur, the market’s needs could be down the dodgy path, the one that nobody likes to walk down because it is covered with mud, weeds, and crabgrass.

Of all the ingredients that make a product a success, none are more vital than matching a product to what the market wants. Few have observed this process with more first hand experience than Eric Ries who was involved with a business which failed badly—blowing through 40 million in five years—and a later one which he started that was very successful. The failed first experience encouraged him to try something new with the second. A process he calls the Lean Startup.

The unintuitive first step of the lean process is to start with the assumption that you don’t know what the market wants but you are willing to learn. In order to learn what the market wants, you start with a small hypothesis of what you think it may want and then create what he calls the minimal viable product. The minimal viable product should be created with as little effort as possible and he goes so far as to suggest that it is commonly overridden with bugs. If that weren’t enough, he mandates you charge for it as well.

When I first heard the concept of a minimal viable product, I felt violated as a software engineer because a software engineer creates well designed low bug products not quick and dirty buggy ones. The thought of releasing something to the public that is buggy and worse expected to be buggy is nothing short of shameful. How could any self respecting engineer even consider shipping a buggy thing that will bring embarrassment to themselves?

What most engineers fail to understand, however, is the more time you put into a product without showing it to the market—what is commonly called stealth mode—the harder it is to change direction. Code that has lots of time, money, and reputation invested in it is hard to throw away and is often the source of emotional attachment which can ultimately drive a product into the depths of failure. This is precisely what happened in Eric’s first startup experience.

The real strength then of the minimal viable product is not just low emotional attachment but the ability to rapidly try different products ideas by releasing, getting feedback, and repeating until the market clearly signals what they want. The ability to change directions quickly and keep the burn rate low before a product/market fit is found is essential to the process of founding a successful business.

But how can one know when a product/market fit is found? No one has a better acid test for this problem than Sean Ellis. His method is shockingly simple. Survey the customers with one simple important question: if the product was discontinued would you be severely disappointed?

According to Sean’s experience with various startups, if 40% or more of the users say they would be severely disappointed if the product went away, the product has a fit and thus a market. So vital is the number that even Sean himself thinks twice about working with a company with a number less than 40% because the fate of the startup is still in question. Marketing a product is hard enough but marketing a product that no one wants is a losing situation anyone with smarts will thankfully leave to others.

Software Developers build things. Not physical things that people can admire from afar but rather invisible instructions that travel along wires as pulses of electrons. These instructional bursts can move data around from one place to another, add subtract multiply and divide numbers, and even draw complicated objects on the screen. A computer is like a piano; by itself it just sits there. It takes someone with enough persistence to sit and learn the thing to make it do something.

Persistence is a rare quality but one that is sorely needed when programming a computer. After all, programmers must painstakingly assemble instruction after instruction. Never was this more true than in the old days when programmers had to think in terms of ones and zeros. 10010101 could mean store a number, for example, while 10111010 might mean add two numbers. Programming this way was the only way to get things done and it drove many to the point of insanity. It is the equivalent of building a house by molding your own nails and milling your own two by fours. In other words, it took a lot of grunt work to get anything useful done.

Programmers understood this and in time became determined to make programming more time efficient by introducing what they like to call abstractions. Abstractions increase productivity by abstracting away the details of how something works. For example, compilers were introduced that would take high level languages like the C programming language and compile it into ones and zeros that the CPU understood. Now you could program with nails and two by fours already cut which was a fantastic performance boost.

Taking the idea of abstractions further, libraries were developed. A library consists of many routines—commonly called functions—that a programmer can call to get something done. Want to draw a circle on the screen or do a FFT; chances are some other programmer already created a library to do that and all you really have to do is call it with the right parameters. Forget about ones and zeros, programming became a task of calling a bunch of libraries.

Today there are hundreds of programming languages in addition to C and many more libraries that do everything from request a web page to move a robot some determined distance forward. Programming these days has become a game of how well you know a given set of libraries—typically called frameworks—and what programming languages you know to call those libraries. It’s a world of abstraction upon abstraction designed to make life better.

Before you get the idea that programming today is easy because there are all these cushy libraries to call and high level languages to do your every bidding, think again. Although things are generally easier, the shear amount of frameworks available makes it very hard to know what is going on under the hood. Most of the time you don’t care and frankly don‘t have to. However, every so often you will undoubtedly encounter a library that is not doing what you would expect. A kind of bad behaving library if you will. This is were the trouble usually starts.

During these times, the questions come flooding into your mind. What is causing the issue? Are you calling it correctly? Does it just not work? Should you try to use something else? A road block has presented itself in the otherwise smooth journey of programming bliss and you must get around it and continue on the journey. Spend any time next to a group of developers deeply concentrated in coding work, and it will become painfully clear that navigating road blocks happen on a daily basis. The clues come in the form of expressions like: “That doesn’t make any sense” or “What were they thinking” to more colorful expressions of the four letter kind.

Call it what you want but road blocks are a fact of life and developers have a similar set of terms for there solutions. Some issues will often have a well know solution called a “workaround”. A workaround is like an official response from the library creator in effect saying we screwed up and this is how you get around the issue. If the problem is less known it becomes the task of the developer to creatively implement a way around the problem in what may, depending on the degree of elegance, be referred to as a “kludge”—a kind of less elegant quick and dirty solution. Regardless of how the issue is solved, in the end the developer must make a choice. Economics have a term for this called opportunity cost. By choosing one thing you forgo the potential benefit of choosing the other.

What makes this so fascinating is after lots of workarounds or kludges you could look back at the web of decisions made and wonder if you made the most optimal path. The shear amount of paths through the web of choices is what I call the developer decision space. Two programmers may achieve the same result through different paths but one will be more efficient. The new game becomes navigate through all the pitfalls and landmines with the most optimal path possible.

To get a feel for how this plays out, I have a recent example. For work, I have been tasked with trying to get some of my code to run on the new Microsoft framework called Azure. Azure is a cloud platform that allows you to host your code on Microsoft servers rather than buying your own.

Everything was going smoothly until I hit an issue with uploading my app to the cloud. Staying as light as possible on the technical jargon, I had some loose .NET assemblies in a folder under the root application that were not getting included into the Azure package.

My first attempt to resolve the issue fell into the kludge category. I had found out about a way to create the Azure package unencrypted that would allow me to manually put my assemblies there. This turned out to not work as I received an error when uploading it to the Azure cloud—I contributed this to some check sum they must have in the Azure package. With this part of the decision space blocked, I focused my attention on other ideas. I decided to included the assemblies into the ASP.NET project which solved the issue but caused a new problem—my included assemblies were Silverlight ones and ASP.NET was trying to load them on startup. That forced me to try a different idea of copying the assemblies into the Azure local storage on startup which ultimately worked.

I shared this experience not to show that I am some technical genius who solved a problem but rather to illustrate the complex interplays of the decision space because an interesting thing happened when I uploaded my final solution to the Azure cloud. I got an error; an eerily familiar error about an invalid package similar to the error I received when uploading my first attempt with the unencrypted package. It turns out the reason for the error is a bug in Azure where you have to delete your entire Azure project and re-add it rather that upgrading it. After I did that my final solution worked but I couldn’t shake the feeling that I had missed the most optimal path.

The pestering feeling was the result of discovering new information that I didn’t posses at the time of my first failed attempt. It wasn’t until I was down other paths, trying new things, that this new information came to light which had the potential to open up other paths that I had previously closed.

In my case, I wondered if the error I got on the unencrypted package, my first attempt, was related to the bug in Azure that I discovered later and not a checksum thing after all. If that was the case my first attempt, which was a couple of branches higher in the decision space, was most optimal.

This is what makes programming more of an art than a dull mindless practice most chalk it up to be. It requires the ability to make seemingly unconnected insights and connect them. It is like solving some kind of big puzzle with limited information. As you start to solve the puzzle you learn more and that new information has the potential to unlock a number of issues you thought were previously hopeless.

I am convinced the great programmers have a heightened ability to see these connections. Not only a couple of layers above, like mere mortals, but through most of the decision space. This is even more remarkable when you consider that each decision has an opportunity cost and keeping track of all those decisions that effect other decisions is hard if not close to impossible. But the better these can be tracked mentally the greater the potential breakthrough insight; like Niels Bohr unlocking the secrets of the atom that others failed to see.

Unfortunately, there are only so many Niels Bohrs in the world. However, I believe more developers should put greater effort into understanding the developer decision space. Too often developers make their way through the space by making a decision then immediately relieving their tired brains of the circumstances and implications that justified that decision and move on to the next one. Continuing this pattern a couple more times and it becomes blatantly clear that they have no hope of applying new insights to old decisions and breakthroughs will never happen. Instead what commonly happens is they find themselves wondering in strange roads and thinking to themselves: How did I get here?

I don’t know if this is from pure laziness or simple unawareness. Software development experience tends to help some because after a couple of times traveling strange roads one starts to remember how they got there so they can find their way out. But experience alone doesn’t mean the skill will automatically develop since some experienced developers don’t seem to possess it. If it is unawareness, consider yourself informed. If it is laziness, then you probably haven’t made if this far in the article anyways.

During my later college years in Utah, each year around Halloween people became enamored with corn mazes. The most popular time to go was at night and during one of those nights I found myself staring at a dark corn field entrance illuminated by flood lights.

To the scientific thinker a corn maze can be an incredibly frustrating experience. One must navigate through endless corridors to somehow arrive at the one opening on the far end. I didn’t have any strategy in mind–after all my wife told me this was supposed to be fun–so I went with the flow.

After some time in the maze, I was hopelessly lost and not having much fun. I was seeing the same people over and over again. I remembered hearing my dad say once that when lost in a maze just put your hand on a wall and follow it until you eventually arrive at the end. I followed that strategy for a time–not really thinking it through in my head to verify if it really works–until I got bored and did what every corn maze zealot would shrink with disdain at: I walked through the walls until I was outside the maze and made my way to the entrance lights.

Some years later I found myself in my first programming gig writing graphs, meters and knob components for scientific applications in .NET/C# and Windows Forms. My first assignment was to develop a program to benchmark how fast an early prototyped .NET graph would run. I took the assignment in stride–not knowing much about the .NET framework–and implemented an application that worked. My boss on the UI team, to which I belonged, sat down and had a code review with me. It was my first official code review and it didn‘t go well.

I was crushed. However, as the code review went on I began to see where I could improve. After all, I had never developed a professional application before and had honestly never seriously studied one. Most of my projects in school were little in scope designed to prove I knew how to create a linked list, code a quick sort, or create Huffman code trees. They were not designed to be extended or maintained by someone down the road.

In the months that followed, I worked double hard to prove I belonged. I studied the code base and learned all kinds of code patterns I didn’t know existed. Visitor, Observer, and other patterns–that oddly were never mentioned in school–that I would later read about in the famous Design Patterns book. Over time my code got better.

Which brings me back to the corn maze. Like someone navigating a corn maze, when you are starting out as a programmer you tend to make decisions one at a time without any greater context to guide you. Function A throws an exception so that means it must not work so use Function B instead. These decisions are made one by one, in isolation, until a program is assembled into some kind of greater whole that runs. A more senior programmer–who hopefully has the ability to look at the maze from high above–might wonder why you took the long route or worse never arrived at the finish.

If the goal is to become a more effective programmer by seeing the maze from above, how does one get there? Before we explore that goal, we should become comfortable with a sometimes not understood secret in the programming field. Not everyone with experience can see the corn maze from above. Some, try as they might, can never seem to get their heads above the corn. Others find they can get their heads a few feet above the maze which delights them to no end. Fewer still are able to successfully position themselves effectively over the maze.

To reach the programming pinnacle of understanding above the maze, you must position yourself in a work environment with others who are able to at least get a glimpse into the maze. Learn how they think, how they code, and why they make the decisions they do. As you progress in your career it will become vital to learn from those who possess greater powers of levitation. Finding these types are hard, but once you find one–like finding traces of gold–the chances of finding other high performers is high. Good programmers like to work with other good programmers and its in these pockets of intellect where you will make the greatest strides.

If you ever find yourself driving along US 20 just Northeast of Idaho Falls, Idaho be sure to look to the South at the small rolling hills because if you look closely, you might be able to pick out some small brown buildings huddled together amidst all the potato farms. It was in those buildings, early into my CS degree, where I learned my first valuable lesson in debugging.

I was sitting in the small Computer Science lab agonizing over a CGI Perl script. I had a problem. My variable was losing its value and I had no idea why. I would print out the value and then print it out again and the value was lost. I checked the code between the printings and nothing was doing anything suspicious to the value. As the hours passed, I was falling deeper and deeper into frustration. I had a depressing thought: How could I possible succeed at this profession when my variables can’t keep their values.

Looking for ideas, I did what every self respecting programmer did before Google existed and looked for some human help. No one was in the lab so I sheepishly made my way over to the professor’s office which was conveniently located just off the computer lab. This, after all, was a small college where professors weren’t self absorbed in their own research and actually talked to students.

Luckily, he was there and willing to help. We pulled up my program—which was a very busy thing with lots of variables. I jumped in trying to explain things to gain credibility. He immediately began to pull out chucks of my program and put them into a new Perl program to run. Then we would verify the piece ran as it should. We continued to do this until the problem was discovered; my variable was misspelled ever so slightly. Perl, of course, is a dynamic language and had simply created a new variable instead of using the one I wanted.

I was embarrassed—especially considering the problem was discovered in under 5 minutes—but I learned a lesson. When something is not working and the program or function has lots of working parts you must simplify. Creating a new program from scratch and pulling over code to run eliminates all the noise from the surrounding code.

I have used this technique effectively countless times since. Still, I am surprised sometimes by professional programmers not using this technique when trouble shooting issues. They will toil with the whole beast of a program trying to fix the issue but it is hopeless because there is just too much noise. Simplify.

Unit tests are all the rage today. Talk to anyone who has been reading the unit test literature and they will talk with such passion you might for a split second think you were sitting in a town hall health care meeting.

To understand the arguments for unit tests, we must first understand how code is typically tested. Code is usually tested by an integration test. Integration tests run against the entire stack of dependencies when testing your code. Integration tests are hard to set up because all dependencies must be installed correctly for the test to run. They are associated with long test times. This can be especially bad for continuous integration systems which are brought to their knees by running them on every check in. If a test fails, the bug might be in a dependency or in the component under test making it hard to tell where the issue really is.

Unit tests aim to fix these issues. A unit test is written to test one specific unit of code and differ from integration tests in one critical way; unit tests do not test dependant code. To eliminate the dependencies, they are mocked—often with mock frameworks—to return certain hard coded values to your code. Your code is tested to function properly given the mocked implementation of the dependencies. The tests run fast and if a test fails it is guaranteed to be in your code.

Let’s say I have a library that is responsible for storing data. It stores the data in the cloud by calling a web service. Unit test advocates want the web service dependency eliminated for testing purposes. To accomplish this, the web service dependency is made into an interface—or what is typically called a seam—allowing me to plug in a mock implementation. Something like:

public interface IStorage
{
    public void SaveAsync(string name, Stream stream, Action<Boolean> callback);
} 

Now, I can mock up an implementation of the IStorage interface for my tests without having to go to the actual network. If the behavior of different parameter values into the function are well defined, I can write many unit tests for all combinations of input. Technically, with all combination of inputs covered, when the code goes into production with the real web service implementation it should just work.

This seems splendid. In reality, chances are the real web service has a bug in it because the author doesn’t believe in unit testing or the API behavior was not well defined because you thought passing a null name was ok but apparently it isn’t because the server barfed when it couldn’t find the name in the XML. This brings me to my first negative about unit tests.

Unit tests desperately depend on strong API contracts

There are two types of API contracts: compile time and runtime behavior. The first, compile time, is self explanatory. The second, runtime behavior, simply means the function has well defined behavior for certain values that are passed in. For example, if a function returns 0 for errors and then is changed to return negative numbers for errors it is a behavior change and will break code that uses it.

Behavior changes are devastating for unit tests. Remember, a mock simply mimics what the dependency is supposed to do. If behavior is changing in the dependencies, a unit test is essentially worthless until the mocks are updated with the changed behavior. Worse still, if communication is poor between API owners about behavior changes, out of date mocks can remain in unit tests creating false negatives (tests don’t fail when they should).

When false negatives exist in unit tests—hiding like an explosive IED alongside an Iraqi roadway—there might be 100% unit test coverage in your code but that won’t prevent your boss from hunting your butt down when your code doesn’t work with the product as a whole. Even the slightest behavior changes in an API can bring an entire product down.

Mocking up dependencies is not always trivial

It is possible to mock every external dependency to your component if you have a lot of time. Many components have not just one but many dependencies with large API footprints. To make matters worse, many external components are not easily mocked.

If developers simply apply a brute force approach to mock all dependencies and create wrappers for ones that aren’t easily mocked, weeks will go by without much to show. Meanwhile your boss is in his office looking at budget numbers scratching his head wondering how you are creating customer value.

Unit tests don’t catch funky issues

Because unit tests run against a fake implementation of the dependencies, real product integration issues are never found. I am talking about those hard core issues that everyone pretends don’t exist like having 10 concurrent threads running in God knows what through 15 different API layers implemented in 15 different programming languages.

So what’s a time deprived developer to do?

This is not an easy question to answer. For reasons stated above, even if you have extensive unit tests you will still need integration tests. I believe the balance between the two depends heavily on stability of dependant APIs and how well they are tested. Developing against unstable buggy APIs, cover your butt with integration tests. Stable well tested API’s like the .NET framework, unit test away.