Ashutosh Nilkanth's Blog

Recently I read about the yet unbuilt 2011 Ford Fiesta that attracted more than a thousand online pre-orders within the first 6 days of the launch of its reservation program. It made me wonder not only about the marketing hype associated with such campaigns, but also about the fact that pre-orders from such campaigns help dealers gauge interest in the vehicle and what accessories consumers find most appealing.

I found it interesting that the same thought can be applied in the context of technology startups. Pre-release expressions of interest can immensely help Lean Startups gauge interest in the (yet unbuilt) product and what features consumers may find most appealing. It can also help startups ascertain the actual scope, perspective demand and real-world audience of the product, all of which are very important factors for effective monetization. After all, the first goal of a startup is to find those first 50 paying customers.

A big part of the problem is that no one knows what will work with the consumers and what won’t. No amount of market research, case studies or investment will ever substitute a real-world trial. So you start with a bare bones product that requires minimum efforts to build & release for a “preview product”, and hence reduce the time to market.

Building this “preview product”, or a Minimum Viable Product (MVP) as Eric Ries likes to call it, is essentially based on minimizing total time through the Lean Startup feedback loop:

Bootstrapping, rapid prototyping, customer driven development, iterative improvement, eliminating waste (muda), unit testing and continuous deployment are all essential components for building a MVP. Much of this paradigm is also derived from the Toyota Production System.

For example, having a paid account availability notification in your application is a tiny yet nifty approach to a MVP. You build a smaller product, or rather, you build a single feature. You incrementally improve it based on early feedback from interested users. And during this lean startup loop, you measure the actual value of the product by inviting users to pre-order your lean product.

In the field of human-computer interaction, a Wizard of Oz experiment is a research experiment in which subjects interact with a computer system that subjects believe to be autonomous, but which is actually being operated or partially operated by an unseen human being. A related true story I read about an ad-hoc approach, similar to what an MVP can often employ, goes like this:

There was a guy who wanted to sell cars online. But it was a huge system to write from end-to-end, and moreover he didn’t know if it would work or not. So he made a simple website with basic content and forms etc., but he processed the entire back-end work by hand. There was no real automated backend, but the customers got the impression that the entire thing is pretty much automated. This experiment provided him the feedback he needed for expanding his business processes and automating only the essential components.

The best way to predict the future is to invent it.

At one of the company stand-ups I attended recently, the topic of discussion was ‘Good Communication’. As simple and ordinary it may sound, it did make me think about an interesting hypothesis.

Research tells us that only 7% of all communication is impacted by the content or the words used. The rest is all non-verbal — body language and tone. At the stand-up, we did a few basic exercises to highlight the basis of good communication, why we communicate (the way we do), with whom we communicate (internal and external parties), how we communicate (the modes and tools) and a few case studies of good and bad communications in the real-world.

From that discussion it made me wonder if most poor communication or mis-communication occurs when things go wrong, and most good communication occurs when things are going well. So essentially, communication is driven by the environment.

In chaotic situations, specially those which are life-threatening or time-sensitive, communication becomes harder by multitudes. When the Black Saturday bushfires (as many as 400 individual fires) were burning across the Australian state of Victoria in February 2009, millions of SMS messages warning of extreme fire danger conditions were sent by the mobile phone companies, on behalf of Victoria Police. However, a lot of people in the affected area didn’t receive the SMS messages, and a lot of people in the unaffected areas received the SMS messages. Some were spooked by the SMS messages and considered them an over-reaction. Others, mostly who were around the impact zone, felt the SMS messages were not relayed in a timely fashion.

A month later, amid global economic worries, the Australian Prime Minister announced a cash bonus for more than 8 million Australians as a way to stimulate the economy. Because this “desirable” action was communicated well, pretty much everyone who I talked to knew about the payment, who was eligible and even how & when the bonus would be paid.

Communication is effective when it’s intentful and well-guided, and communication is ineffective when it’s mostly unintentful or mis-guided. At some level, we are all likely to boost the success, achievements and pleasing actions, but put the failures and shortcomings under the carpet or atleast delay their communication. I guess the important thing, specially for businesses and government agencies, is to communicate consistently and become more open.

Joel Spolsky recently wrote about the “Duct Tape Programmer“:

Duct tape programmers are pragmatic. Zawinski popularized Richard Gabriel’s precept of Worse is Better. A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.

Joel’s views triggered a series of rants and responses on the pros and cons of the “release early, release often” pattern and the “analysis paralysis” anti-pattern, a phrase that describes exceedingly long timeframe to solution delivery. While I personally prefer the “quick ship” approach, I do utilize the benefits of iterating analysis. Maybe it makes me a diplomatic drone, but I care more about an uncomplicated outcome.

The debacle around the “duct tape” approach to programming led me to a different question. What if the duct tape is red, or more precisely, how does patent-driven red-tapism affect software and technology development? Essentially, why do some programmers patent their work?

Kas Thomas described the concept of a role-based favicon, and why Novell patented it:

I was granted a patent (U.S. Patent No. 7,594,193, “Visual indication of user role in an address bar”) on something that I whimsically call the rolicon.

Okay, but why do this patent? The answer is simpler than you think (and will brand me as a whore in some people’s eyes). I did it for the money. Novell has a liberal bonus program for employees who contribute patent ideas. We’re not talking a few hundreds bucks. We’re talking contribute ten patents, put a child through one year of college.

I have two kids, by the way. One is in college, using my patent bonuses to buy pepperoni pizzas as we speak.

It was a bit unsettling for me, because Novell has been continually contributing to open source projects, and most marginally good programmers I know don’t believe in patents.

Undoubtedly, Michael Jackson was a great performer. He had actually invented and patented the shoe design used as part of his famous Moonwalk.

It makes him a “hacker“, but his “method and means for creating anti-gravity illusion” could have had wider benefits if he would have not patented the design so that other innovators could make the most of it. I can already think how this could have improved the condition of people with arthritis for example.

An anticipated social benefit of patent law is that it creates an incentive to innovate. Ironically, the patent law severely restricts innovation and healthy competition. Patents stimulate monopolies, like Microsoft and many other self-indulgent technology companies. We need to acknowledge that patents should not be a marketing strategy, but unfortunately they are so in consumerism.

Some may suggest that we should abolish the patent system altogether, but I don’t think the big fishes would ever let that happen; otherwise they’ll lose competitive advantage in a lot of lucrative areas. But what if patents were self-expiring? A patent would auto-expire if isn’t used within a certain timeframe less than the default 20 year term of the patent. This should hopefully satisfy the corporate schemers, and all programmers regardless of the colour of their duct tape.

Not so long ago, an acquaintance who was seeking a software development job interviewed for a role at a “market leader” in the development, implementation and support of financial services software. During the interview, it was revealed that the position is concentrated around the implementation of an Enterprise scale project for a large government organization. He was told that the implementation will be based on the companies existing flagship product (a SOA based turnkey system of some sort), which will be extended and customized according to client requirements.

Just a few days before the interview, a team of representatives from the same company met with the business executive from the government organization, at their high-rise conference room overlooking the pier. RFP’s and RFQ’s were already out of the way, and so were the product specifications. The company won the tender because they already had a base solution in the form of a customizable product, and the industry-specific expertise to go with it. It was just a matter of signing the dotted line, with fingers crossed.

What my acquaintance, and the large government organization didn’t know was that there was no such flagship product in existence, at-least in a functional form. The whole proposal was a farce, filled with enough fluff to have lasted as a year’s stock of toilet-paper. In a sense of over-estimation the company did have the technical capability to develop the solution from surface, but realistically it was impossible. The fact of the matter is, almost always — things take longer than they seem, and money lasts shorter than you plan.

Fearful, but not rare. This mechanism, how so ever unethical, is not uncommon in the Enterprise landscape. Garbage-disposal giant Waste Management is still embroiled in a $100 million legal battle with SAP over an 18-month installation of its “fake” ERP software. Waste Management claimed SAP executives participated in a fraudulent sales scheme that resulted in the massive failure. What did a $400 million upgrade to Nike’s supply chain get the world-renowned shoe and athletic gear-maker? Well, for starters, $100 million in lost sales, a 20 percent stock dip and a collection of class-action lawsuits.

The problem lies in three broad facets: people, perspective, and process.

People, at all levels in an organization (large or small) need to rationally answer a question: if I were a business owner, would I invest gazillion dollars on bloated software that takes years to implement, then years to fine-tune, by when it doesn’t solve the ever-transforming problems. Perspective, in terms of the scope and scalability of a solution. “We want to build more features than our competitor”, is a very common notion. Keeping the feature-set minimal may sound like a joke to many corporate vendors and business executives. But, minimalism really promotes iterated execution; which eventually saves money, time and efforts. And finally, process — the end-to-end software engineering approach, which I think is a big factor for so many spectacular failures and huge spending nightmares. Software engineering is relatively young, hardly a few decades old. Compare it with dwelling construction, which originated from the era of the cave man, and you’ll probably understand what I mean.

So you overheard from the cubicle next to yours, “it’s not that simple“. Well, that’s right. Complex ideas result in complex software. The bigger an object, the more energy is required to change its direction. In order to finish a project on time and on budget, without reducing the level of quality, we should ideally implement less and iterate more often. Under-do, and you will make successful software that is lean and opinionated.

Sir Charles Antony Richard Hoare (best known for developing Quicksort in 1960) said:

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

What makes a programmer good at their craft? For years, organizations which hire programmers have reasoned with this question. Yet, the criteria for selection of a “good” programmer differs by the lot. As candidates, most programmers are put through tough technical interviews, grinding analytical tests, and twisted coding sessions. Employers also review attributes like past work experience, skill-set, education qualifications, references etc. With all sorts of characteristics to gauge, it becomes very difficult to recognize a good programmer, let alone to hire one.

After reading an article titled ‘Signs that you’re a bad programmer‘, I thought hard at what makes a good programmer. No wait, let me rephrase that, for the reason that everyone (including yours truly) is marginally horrible at programming. It’s a craft that takes decades to excel, if not to perfection. So the real question then is, what makes a programmer less horrible?

I have been interviewed for job roles, and I have interviewed other people on occasions. I’ve also been gracefully delegated the awkward task of firing a programmer. To my comprehension, following all these years as a programmer, the most reasonable sign that you are a less horrible programmer is your ability to build stuff during your spare time that serves a utility or solves a problem (maybe your own). When programming becomes a hobby, and as side-projects start taking shape, you’ll start getting marginally less horrible. Even better if those side-projects are collaborative.

This inherent trait shows that such programmers are passionate about the craft as they indulge in “extra-curricular” problem solving. An ad-hoc practice with a variety of small projects also improves the quality of work and estimation accuracy. This skill of utilizing time for 20% of the causes is what makes a (talented) programmer less horrible. Moreover, when you are both the teacher and the student, you’ll find it easier to surpass any illusory superiority. Programmers who strive for a process of continuous learning through self-teaching can be distinguished much easily than with conventional steps of recruitment.