what the big company got wrong

The opinions expressed here are the author’s own. He is not the mouthpiece of some big company.

Back when I joined Big company in the silicon valley of India, I had certain outrageous assumptions about the way a big companies operate. Lately I realized that most of my assumptions are falsified. I wanted to take stock of that stark realization and capture the moment/thoughts. Hence this post.

When you dig deep as to why Big Co fails to perform as good as it used to do as a small co, you will have no surprise in your findings. They make blunders, not mistakes. Why would anybody make blunders, knowing that the consequence is going to be undo-able and the repair costly? Because they do it over a period of years, very slowly, without realizing that they’re erring. Reason #2, if mistakes are distributed across people, nobody owes responsibility, nobody feels guilty and nobody acts. I can’t blame a single person for inflation or price hike. If on the other hand, I feel bad about inflation, and instead of kicking around I start being conservative on resources, start using public transport for commuting to work etc. I act as if I am also contributing to the price hike otherwise(which is sadly true). On to Big Co’s blunders now.

1.substandard products

The most basic thing Big Co. gets wrong is product quality. If you are delivering a product to the next layer(it can be your customer or the quality team), you make sure that you get things done right the first time. At least strive to do so. Big Co. thrives on hope, numbers and hype. It always ends up succumbing to market pressure, hence deadlines dominate all business proceedings. They take this as an excuse and deliver products which actually suck. There is no distinction between production quality code and code written by college freshmen in Big Co., barring a few instances.

2. Premature optimization

Optimization bug bites Big Co’s employees at the wrong time, always. They spend a lot of developer time is squeezing out CPU cycles out of hardly used code. The reason they give: Give users an edge over competitor’s products. Correctness of code is more important than speed.

3. Poor planning

I agree that market decides Big Co’s plans. But the deadlines should be scheduled optimally so that there is a win-win situation for both the developers and customers. Afterall, that’s what managers are paid for. But Big Co. plans dates without even consulting a single developer, and impose it on them. Most deadlines are not enough for delivering a complete product, resulting in delivering a sub-optimal solution which is not fully functional. I call it a half-bake. The reason Big Co. fails in this aspect: The take the “release early, release often” idea too literally. Would you be happy if the the pizza guy gives you a pizza in 3 minutes, provided its just half-cooked? I wouldn’t.

All the developers must be consulted before agreeing for deadlines. There should be no room for compromise here.

4. Bad perception of development

Big Co. runs its code through all sort of static analysis tools, leak detectors, profilers and what nots, in the hope that tools are going to fish out bugs early. That is a very nice strategy. But what Big Co. fails to understand is that all code advisory tools are just supplementary to sound code. No tool can substitute clear thinking and a taste for programming. Coding experience is a perk but not compulsory. Why can’t Big Co. trust tools entirely? Because the tools themselves are written by Big Co. stereotypes. I bet that if a tool(lets call it MagicWand) comes out in the market which pumps out code for a given requirement, Big Co. would do a mass downsizing, leaving only managers trained in using “MagicWand“. Their only budget allocation would be buying of “MagicWand” licenses. Lesson learnt: there is no silver bullet.

5. Hypothetical targets

Big Co’s managers badly need a crash course in statistics or programming, or in most cases both. They set a very low defect goal, and they estimate code size like 12 yr old kids do. To enrich their much needed estimation know-how, they study books on code estimation(if a book teaches them how to swim, they’d read it as well and dive into the waters!). The importance given to numbers like defect count is blown out of proportion. Statistics are like bikinis, they show everything, except what one would actually want to see.

Adding to the fact is poor measurement techniques. Metrics and timesheets are crappy in Big Co. Developers play their part by filling it with junk, in most cases. Folks bank on these numbers and take cut-offs, the result is evident. rescuetime and ididwork are good  a good cure to the metrics problem.

6. Hiring bad people

If Big Co. hires good people, problem #4 would be solved to a great extent. What does “good” people mean? It exactly means people who get things done. If I was hiring for Big Co, I would not go for buzz words or college pedigrees or by asking tweaky questions for which you can find out answers in minutes by googling around. Things which would count are projects worked on(at least one open source), expertise in one programming language, knowing many programming languages and communication. Communication strictly means the ability to document stuff. Code must be written for humans to understand and only incidentally for computers to execute. Big Co.’s managers are tempted to hire more people if the project is running a tight deadline. I would recommend them to read “the mythical man month” by Fred Brooks. No excuses here.

Even if Big Co hires people on a needy basis, their mentoring program sucks. There is no concrete material or approach. Both the mentor and mentee fill a lot of documents and end up doing nothing. No company gets a second chance to impress their employees.

Software development is an iterative process. It is one of the most creative jobs. Developers burn the midnight oil, eat junk food, lose sleep, in some cases, marriage and develop software. They invest more than time in their products. A little encouragement is always great. Big Co must develop a broader perspective on this, failing which we will continue delivering substandard solutions, and getting substandard solutions.