24 karma · joined May 15, 2019
Poor design quality increases the chance of poor build quality. That's why it's important to measure both.
As an aside, I've always felt that 'Defect' is a more useful term than 'Bug'. 'Bug' seems to be too open to interpretation (i.e. one persons bug is another persons feature). 'Defect' however, has a useful definition:
'An operation is defective if it doesn't conform to the specification.'
This provides a solid basis for identifying Defects. Once you can formally and accurately establish what a Defect (i.e. Bug) is, you can use the following two simple formulas as KPIs.
1. Design Quality Change Requests/Requirement Specification (DQ = CR/RS) 2. Build Quality Defect Reports/Requirement Specification (BQ = DR/RS)
The ideal is zero. In other words, zero Change Requests per Requirement Specification and zero Defect Reports per Requirement Specification. However, I suspect that no project in history has ever achieved that. Nevertheless, it's the quality target to aim for. Once you start treating these values as KPIs you can start to monitor the two numbers over time and steadily work to reduce them, thus improving quality in a measurable way. For instance, you may find that the project you're working on has a DQ of 2.5 and a BQ of 3.6. Your mission (if you choose to accept it) is to steadily increase quality so that those two numbers reduce over time.
By viewing the results across a date rand you can start to see quality trends.
Design Quality is an important metric to monitor because that's often where the weakness lies in software projects. Managers love to offload design to developers in an ad-hoc way, largely because design is hard and time consuming (and no-one likes to write specs).
If you're concerned about build quality, first check the design quality. If you're building a product from poor, incomplete, inaccurate specifications, you're going to find it much harder to achieve decent build quality.
We'd all like to be a filthy rich pragmatist but I wonder just how much the 'low-quality standards' enabled you to achieve that. Seriously, I would love to be a millionaire with regrets about low quality code instead of being broke with junior developers pointing out my code smells and technical debt.
I've always felt we've misunderstood technical debt. It seems to be regarded as a problem with a lot of negativity surrounding it. Developers seem to fear being accused of introducing technical debt - like it's the worst kind of developer crime. But in reality, there is value in embracing it in early stage projects. As thinkingkong mentions below; 'Its only debt if it sticks around long enough to need to be dealt with.'
The software industry is still growing up and best practices still have to be formally established. All the articles and books written about best practices in software - they're just the beginning - and most are probably wrong to some extent. Where does the intellectual posturing come from in the software industry? It's largely because of a lack of provably reliable practices and processes. The ones we have, are sold to us as 'the best thing' but they will eventually be found wanting. Ron Jefferies recent article about software estimating is a classic example (https://ronjeffries.com/articles/019-01ff/estimation-again/I...). Some people are so fed up with how unworkable estimating is that they're willing to ditch it entirely.
And so, in the absence of mature, provably reliable practices and processes the way is open to 'who's ego is the biggest' because those with big egos (but not necessarily a lot of experience) often think they know best (Dunning-Kruger). Their proposals (which are just as likely to be wrong as anyone else's) tend to be adopted simply by force of ego. For instance, you wont hear terms like 'code smells' in the hardware world (I worked as a software developer in oil and gas and rail transport for 30 years and never once heard it mentioned). To say "that's a code smell" is a kind of intellectual put down. It's intended to insult a developer into doing something differently and thereby elevate the speaker as someone who 'knows the right way'. Eventually, these things will disappear and the software world will have reliable, accurate processes, practices and rules and the 'code gurus' will be consigned to history.
And that's when the intellectual posturing will end.
Our industry (software dev specifically) is inclined to use put downs in this way. I've often thought the phrase 'code smell' is used as a 'put down', a way of diminishing someone's work in order to make them change what they do (i.e. to be more like some perceived standard). I think the use of that (and other similar derogatory phrases) is unprofessional - which is a tad ironic.
To me, this seems like a productivity question. The software industry has the misguided notion that productivity can't be measured and until that changes, it's very easy to argue that mob programming is efficient - because it's impossible to disprove (i.e. it's 'not even wrong'). In fact, because we don't have a concrete definition of what 'efficient' means, it's easy to argue any kind of programming is efficient. Big teams, small teams, work alone, OOP, FP, MVC, Java, Ruby - take your pick. We can all argue the merits of any pet methodology, language etc. In the end, what we really need is a way to measure individual productivity against a set of criteria relevant to a project.
I think this issue should be discussed a lot more.
> Cultural imprinting = shallow emotional inception + common knowledge → inception into consensus reality
And again, I'm reminded of the fact that I would never have come across this excellent article if it wasn't for HN.
> If you take one idea away from this blog post, let it be this: store a raw copy of your data in S3. I would have been happier if the 'one idea' was this: First get your customers informed consent before you collect their data.