Quality or Quantity

Quality always trumps quantity. Lot of companies have embraced the idea of move fast and break things which was pioneered by facebook. But it is important to realize that does not automatically means reduction in quality in favor of speed. Quality is different to different people. For a guy interested in UX, he will be interested in how efficient the user experience is. For someone interested in performance, he will measure quality on the bases of speed of operations in software. Hence, for someone who is owning the quality of deliverable produced (be it CTO, CPO or whatever), it is important to establish the baseline of quality. Good companies which follow move fast and break things methodology make sure that their employees produce software which maintain the quality above that defined baseline.

Any company, not establishing that baseline and trying to adopt the move fast methodology will end up producing software of inferior quality. When I say inferior, it typically means relative to standard market quality because there is no baseline established in the company itself. In such companies, timelines are the cake and quality is usually the icing, which in fact should be the reverse. Quality should be the cake and speed should be the icing. There cannot be a cake without quality. A fast delivery but with bugs should not be accepted.

Lets consider a scenario in which 2 teams estimate to build a particular product.

  1. Team one estimates 2 months. But take 3 months to deliver due to unforeseen issues.
  2. Team two estimates 4 months and deliver with 4 months.

If you look at above scenarios, Team 1 might look better due to higher speed. But in reality, team 2 is far better. Why?

  1. They have better predictability. They can predict the unforeseen issues better than team 1.
  2. A company can plan it launches and its plan will fall in place. In first scenario, a company will always need to have a buffer plan to account for delays. In case of even further delays, company might loose confidence in the amount of buffer. Who has the accountability of giving buffer?

Some companies also employ bad challenge mechanism. Such companies will give employees challenge to deliver the software within some timeframe irrespective of any quality definition. This leads to poor software building habits because of no focus to quality. There has to be a baseline definition of quality (with less than Y bugs etc). An engineer should always be challenged by the complexity of the problem solved and not by number of products or with speed of product delivered. An engineer might deliver multiple products but all with poor quality , then he is not doing properly what he is paid for. Engineers are paid to think and not code. Coding is just a mechanical activity following the thinking park. A software with bugs is mostly the result of poor thinking rather than poor coding. Bugs in code can be reduced through software tools and code review processes. But it is the thinking part which takes years to develop and enhance. And that is what an engineer should strive for, building excellent thinking skills.