| How good your code is depends entirely on context and priority. Context and priority should be defined for a project, not just left to the decision of each developer. I am building code for a startup right now. The context and priority is to "get the damn thing working". Thus code quality is largely irrelevant - this codebase is flat out garbage - it is full of commented out code, duplication, files that were obviated ages ago. It is unstructured, disorganised, uses different approaches to solving the same problem all over the place - there are ZERO tests, no CI/CD, the code is uploaded directly to production. This is exactly the right way to build this because none of those "terrible sins" matter when you have no customers and your only goal is to get something working as fast as possible and every secong spent making things nice is a waste of time and money because if the business fails then every second spent making things nice was wasted. If however I was working for Nasa on code that was running a rocket launch system, then hopefully it is stated to all programmers working on the system that reliability is priority one. This informs every about how the code is written from that point. It means few lines of code, alot more eyes on the code, must more rigorous quality control and much lower overall output. If however I was working in an ordinary business making a CRM system then the stated priority I imagine would be something like "we want a balance between productivity, reliability, maintainability" etc. This explicit definition of the context and priority sets the scene for how the code will be written. I've never worked anywhere that is was explicitly stated across a range of parameters what the code should prioritise in terms of security/reliability/performance/maintainability/time to market/quality etc. |
I'd also add that in contexts where there are hard safety/quality/reliability requirements, having individuals or teams or project team leads responsible for a bunch of conflicting objectives and constraints often produces situations where there will be pressure to make visible short-term progress, at the expense of increasing longer-term risks of issues that are less visible and difficult to measure.
> If however I was working for Nasa on code that was running a rocket launch system, then hopefully it is stated to all programmers working on the system that reliability is priority one.
To avoid this, responsibilities should be structured so there's a different team responsible for QA whose review and approval is necessary to proceed for go / no-go decisions. The QA team responsible for the QA function should be independent from and isolated from the delivery team doing the work, and the pressures and influence of the delivery team's management chain.
In contexts where there's a lot of potential for harm, ideally the QA team shouldn't even be part of the same org (e.g. QA by an external public-sector industry regulator with the power to withhold or retract licenses to do business from companies that cannot demonstrate their products and services are safe), to make the QA team less susceptible to pressure.