I ended a previous post on code quality and development speed by suggesting that the outlook on which of them is more important is heavily driven by the business environment in which a manager or programmer works. Let us consider some of these situations (this list is neither exhaustive or mutually exclusive)
- A startup trying to deliver its first release.
- A successful new startup with a product threatened by new entrants, including some large companies.
- A B2B software product company operating in a special niche.
- A software company that sells shrink-wrapped software in BestBuy for $20 per copy.
- A large software corporation with regular releases of a product used by 30,000 people.
- A consulting software company that bids on government RFPs for software needs.
- A software company that does consulting work on a T&M (time-and-material) basis for clients.
I can go on and on, but I hope you get the picture. Each of these companies and the managers and employees in those companies are under different constraints. These include the size of the company, the market (limited customers, open to everyone), price of the product, type of customers, external constraints placed by the customer before development starts, and so on. Given any set of constraints, usually less than 10 companies or as few as one company would be operating under them. For example, take the browser market. You can count the major vendors on the fingers of one hand.
The advice that is very relevant for one company need not be meaningful for another. In fact, it may be entirely useless or, worse, harmful to the interests of the other company. This means that you have to evaluate every piece from someone outside your company very carefully, even if that person and her organization are very successful. What works for them may not work for you and/or lead you in a different direction.
As an example, let us compare a software development manager in a startup with one in a stable, mature organization. The startup has no revenue. It operates on sweat equity or the investments of the founders or venture capitalists. The immediate goal for the startup is to achieve enough cash flow to sustain its operations so that it can continue to operate, attract more investment and perhaps sell itself to a larger organization. This means that it has to deliver its product(s) to its customers as quickly as possible, without which it has no way of earning any revenue.
It would be too simplistic to say that a startup can release a very elementary, buggy product and gain customers, and start fixing bugs. The biggest problem with that approach is that the product invites too much bad publicity, and also turns off early adopters who are essential in gaining early momentum for the product. Therefore, the first release has to be consequential, or it has to be a closed-invite (or limited rollout) product (perhaps under NDA) to avoid irreparable PR disaster.
For the software development manager of a startup, speed of development and aggressive schedules are important, while maintaining a hygiene quality factor. The best way to accomplish this is with experienced or talented software programmers who can write good code with less overhead processes, such as big upfront design, micro-management and frequent code reviews. Most people would perhaps agree with me about the first two and look askance at the third item. My point is that with an average/poor programmer, you have to spend more time in code reviews to avoid serious errors creeping in. With more capable developers, you can trust them more and verify less often.
What the startup manager cannot do is get bogged down in something that does not materially advance the development of the product. If programmers are idling for days while everyone is having a philosophical discussion on a particular design choice, it may hurt the startup because they are burning cash they are not earning, and the likelihood of a competitor releasing a similar product earlier than them increases. Risk of startup failure and job loss for the employees also increases. This is not an acceptable situation. Hence, a startup manager has to make quick decisions that may be costlier in the long run, but increases development speed immediately. [See my earlier post on more analysis of startup software managers.]
In companies with mature products, there is a revenue stream which pays for development needs. The manager there has an obligation to protect the existing revenue stream by maintaining the quality of the product, especially not introducing regression bugs, i.e., breaking what was not broken. She also has a responsibility to avoid practices that would increase total development costs for product feature. By total costs, I mean the cost of initial development and later maintenance.
Maintenance does not bring any revenue. Yes, there are service contracts, but if the company actually spends those hours in maintenance, it is reducing overall profit. Having faster releases may bring more revenue, but not necessarily. If it is a stable market, the frequency of releases will not be a major selling point. On the other hand, if attention to quality is missed out in these releases, there is the risk of angering and losing existing customers.
So the software manager in a stable company has to spend greater effort in addressing quality and risks, while reducing the urgency of releasing software. Also, because of its stability and (hence) slow growth, this kind of software company may find it difficult to attract the best talent, especially if it is a smaller organization operating in a niche or outside the major software hubs. The company has to complement the people with the necessary processes to ensure quality. We can have a separate discussion about the best methodology for achieving this, but what methodology is chosen, it will emphasize greater quality above other factors.
There is always the possibility that managers can get it wrong. For example, the startup manager can make too many risks and assumptions, and the other kind of manager may be too rigid and bureaucratic. But regardless, it is important to realize that one size does not fit all. The conditions and business goals of the different types of organizations make it extremely difficult for them to operate in the same way. I would be very surprised to see any evidence that what works for startups works in regular companies and vice versa. It just doesn’t happen.