Building high-quality software
I have interviewed many people (both engineers and managers) lately, and one of the standard questions I ask is how to build high-quality software. Of course, I provide more context and explanations, but the gist is the same.
I heard all kinds of answers. However, I was puzzled that almost none were systematic, and people immediately went into a specific pet peeve.
Let me start with high-level thoughts (specifically to make it systematic). First of all, I want to concentrate on software code quality (vs. larger topics, including documentation, UX, design, etc.).
High-quality software is software that has fewer bugs (and a shorter tail of fixing remaining issues). There are a bunch of other things like code readability, maintainability, debugability, and so on which can easily be swept under the quality umbrella. Let’s concentrate on the core that the product operates as expected.
I visualize the software development process as a pipeline going from idea to the product used by customers. There are other ways to imagine it. However, the bottom line is that it goes through multiple steps to get to the usable/delivered product.
