MAD, the only winning move...
As in Mutually Assured Destruction? Or do I misunderstand? I'd love to know more...
Readit NewsUK: 30 minutes before work and 30 minutes at lunch
I've read Liars Poker - a real eye opener. I'd recommend Dreaming in Code by Scott Rosenberg. It's a look at 'how not to build systems'.
s188 commented on Ask HN: Do you write tests before the implementation? · Posted by u/MichaelMoser123
I don't do TDD on the first version. For me, the first version is a throwaway version. If it turns out to be commercially viable, that's when I start with a brand new codebase incorporating all the lessons from the first version, but this time using TDD. TDD has it's place. I just don't think it's cost effective on the first version.
It's helpful to measure design quality and build quality - not just build quality. Software developers are mostly concerned about build quality. Software development should always proceed from complete and accurate specifications and the specification process is a key design process - not a build process.
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.
Could this be regarded as false advertising? It's not really free if you have to hand over PII. Problem is, no-one seems to know how much PII is worth.
s188 commented on Solving the Wrong Problem (2011) azarask.in/blog/post/the-... · Posted by u/dedalus
>Nobody reading this thread is doing that, and the few that are know who they are.
That's the false dichotomy which earned me my stripes.
I used to think I am the former guy, then I realised I am the latter guy. The only thing that changed is that some time passed.
The hind-sight of my mistaken identity is that the systems I have been working on for 15 years became less, not more maintainable as a result of tolerating technical debt.
They also became Google-scale (which is what we were hoping for, but didn't believe at first).
I am the furthest thing from a purist. I am a filthy rich pragmatist who regrets having low-quality standards.
Perhaps it's the fact that you tolerated the technical debt that got you to google scale. I've seen a few projects where developers aim for (as swatcoder so eloquently put it above) the intellectual purity of clean systems and then watch these projects fail to be delivered.
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.
s188 commented on Solving the Wrong Problem (2011) azarask.in/blog/post/the-... · Posted by u/dedalus
> if your system is meant to endure the test of time (think Google-scale)
While some exceedingly few products have that destiny, it’s precisely the naive bias towards thinking that your project does that leads to wasteful over-engineering.
Products and projects are not the same thing. Most of the Google-scale products that you see leveraged tons of technical debt on projects along the way, some critically valuable and some certainly wasteful.
If you’re adding a feature to one of these products that are already at that scale, then your attitude toward technical debt will be different.
But effectively nobody reading this thread is doing that, and the few that are know who they are.
Most readers here are working on projects with near-term deadlines and development lifetimes measured in a few months or years. As much as judicious exercise of technical debt enables those projects to deliver on their requirements more quickly and for less cost, more is better.
Many of us come into the industry thinking otherwise because we’re drawn to the intellectual purity of clean systems, but that purity just isn’t what actually matters most of the time. It can take a while to accept and internalize that.
Wow, that last paragraph is spot on. I found both your comments to not only be accurate and clear but also rather eloquent.
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.'
How do the GDPR popups work if you don't have JavaScript enabled? Are the sites still GDPR compliant if they track you using cookies because you disabled the JS which should have disabled the cookies?