Should Is A Four Letter Word? Or Should Be.

It's easy for people outside of a thing to criticize it. It's so easy that people often aren't even aware of doing it.

One form of criticism is indirect, the statement of how a thing aught to be. How it should be.

It is considered politically correct for the most part so it is insidious even in many environments that outwardly foster a positive work culture.

In a technical environment, especially in small companies with limited resources, many expediences need to be taken. The current state of the union is the result of conscious decisions in the past - the best decisions that could be made at the time.

It should be just the way it is. Think about it.

It isn't appropriate to look at the current state of things and say that it should be different.

It's perfectly fine to say that we want it to be different. It's even fine to say that we should make improvements. Both of those statements are forward looking.

The problem is the fine line between a proactive stance on the future and a complaint about work done in the past. Assuming everyone is operating in good faith, the problem is that the context is ambiguous. That some usage is critical taints other usage.

It's safest just avoid using it.

There's an idea that relates should to another similar sounding four letter word. It is a pertinent comparison and thinking of it that way helps to avoid its use.

Don't should on people's work.

Quality Is Bottom Up, Not A Spice You Can Add

All firmware/software product engineering companies struggle with quality.

All companies. 

Quality costs money and takes time. When time to market is important, it is often more important than quality. Successful innovators must be able to go boldly into the market and make tough decisions to go fast and worry about quality, if necessary, later.

Lack of quality also costs money. Some customers will turn away from a purchase or return a purchase if quality is perceived poorly for the price. If a product is under warranty, returns can be very expensive, especially if it is a software/firmware problem that must be addressed.

Startups can be fast to market by being very time focused and accepting quality risk. A successful start up is often forced to mature quickly. Once it has products in the market place, quality problems can threaten their market position and strangle a small engineering department with maintenance.

How does a small company make the transition from time to market to quality over a product's lifetime?

Most don't.

Some keep blasting aggressively forward, damning the torpedoes, risking losing their customer base and being overwhelmed by maintenance. Some look to the industry for best practices, hire consultants, create processes that address symptoms but not the root cause, etc., at the risk of being overwhelmed by constraints and losing their innovative edge.

Where is the middle ground? How does a small company mitigate quality risk while avoiding being handcuffed by introspection, finger pointing and red tape.

The answer is shockingly simple. Quality has to be built in. It's not a feature that can be added in. It's not a spice. There is no magic quality dust that you can sprinkle on your product. Improving quality takes calendar time which in turn takes patience. Management often cannot get its head around this fact. They want a quick fix - "We need better quality now!".

The best advice I can give a growing small company is to be very wary of anyone that promises a silver bullet. There aren't any. Don't trust anyone that tries to sell you anything that sounds either fast or easy.

Quality is everywhere. In a software product, it is quite literally everywhere. Every line, function, library contributes to quality. When there is a quality problem, the root cause is also everywhere, every line, function and library. It is inside out, bottom up. 

The only way to raise quality is to patiently raise the quality of the entire code base. Priority can be focused in areas that are either more essential or problematic but the solution requires a patient, disciplined approach.

The process is also shockingly simple. Testing. While software development best practices can help mitigate quality risks for new or updated software, ultimately, it comes down to testing. All kinds of testing. Unit tests, functional tests, stress tests. Testing.

Small company management hates to hear about testing. "That would take a lot of time and effort. We need something now". Exactly! Denial is very costly. The longer a company hedges on testing the longer it will waste time and money and continue to risk credibility in the market.

Rather than believe that it is a bottom up maturation of the entire product code base and invest in a rational bootstrapping of testing infrastructure, companies often waste precious time with internal reviews, finger pointing and whining about their plight. Then they may hire consultants, install tools and processes, make changes in mid management and waste further time.

Denial is also why there is so much snake oil in the market. Consultants make a lot of money on denial. Tool vendors also share in the bounty. But, there's no money to be made in the hard truth that quality is a long term bottom up journey.

Companies that make a successful transition are the ones that get over the whining quickly and accept what has to be done. Only then can they look objectively at their product and start to prioritize a test driven quality agenda.

The problem is that the damn the torpedoes Type A personalities that were essential to the company's early success can have a very difficult time embracing an agenda requiring patience and ongoing investment.