The JavaScript ones simply don't appear - which is nice. And yes, I believe they're in breach of GDPR if they use cookies and tracking pixels to track me without giving me the opportunity to deny consent. Please note I'm not a lawyer but I don't think there is a legal obligation for me to use their sites with JavaScript enabled.
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.
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.
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.
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.'
The hardware engineering world (oil and gas, aerospace, civil) is less about ego and more about well established processes, practices and rules. These are much more mature industries than the software industry. In my experience intellectual posturing is much more a software industry thing than a hardware industry thing. Software developers are still struggling to figure out what's the best way to do things. SOLID, YAGNI, Agile, RUP, RAD, Clean Code, OOP/FP - they're all just the start of a maturing process. They will no doubt be superseded in time by other, better practices, just as they have superseded others. In mature engineering industries, the engineering rules and practices are well establishes. Much of this has come about because of accidents (and death - planes crashing, bridges collapsing, oil rigs exploding) and the court cases that follow. In the early oil industry health and safety mattered little. Same goes for the aerospace industry. These are hard lessons to learn and practices had to change. The cost of not changing was uneconomical.
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.
Agreed. I think the professional/unprofessional distinction would have been much better. In this article the term 'amateur is used in a derogatory way, a sort of 'put down', such as one professional referring to another professional colleague as an 'amateur'. It's used in a sense that amateur is bad and professional is good. However it's not unusual for amateurs to be as good as professionals. For instance, major golf tournaments will often invite an amateur as a guest competitor. And so, in this case, the amateur/professional distinction isn't how good they are at playing golf (they're all equally good) - instead it's in the sense of 'is it a full-time career' and 'are earnings derived therefrom'.
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.
This is a good thing. And there's probably still some way to go with this. A step-by-step approach makes sense to me. Sure it's a nuisance for developers (although I'm certainly not complaining about the extra work) but it's better for users to see regular progress regarding their privacy. Surveillance capitalism has gone a bit crazy over the last decade and lawmakers are steadily reeling it back in. I fully support the ICO's recommendations
I agree. I've always felt that an individual may be more efficient (productive) than a team. Of course, that depends entirely on the individuals - their experience, motivation, domain knowledge, work environment etc. One efficient, motivated programmer working alone may be more productive than ten inefficient, unmotivated ones working in a team.
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.
I agree with your point entirely but I wonder if more people outside of tech would care if only they understood what these companies were doing with their personal data.
This was a real eye-opener. As a software developer I've had my fair share of startup failures (and no successes - so far). Advertising and marketing have always been a closed book to me. This is the best explanation on ads I've ever read. So many takeaways but this one really appealed to me:
> 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.
Yep. That's my experience too. But ‘burn and churn’ thrives in the absence of decent human resource management. Is it possible to link 'problem complexity' to 'concentration demands'? And from that, derive a metric that will enable better management of the human resource?
Exhaustion leads to serious problems and, in the airline industry, that often leads to disasters (https://en.wikipedia.org/wiki/Colgan_Air_Flight_3407). Hence the legislation for limiting the number of hours a pilot can fly in a month. There's a lot of science behind that decision - for good reason. It's a mature approach to managing the human resource (pilots) that seems to be absent in other industries. I really wish there were more studies regarding the level of concentration needed to solve software problems and how long that level of concentration can be maintained (weeks? months?) before exhaustion sets in - swiftly followed by burnout.
Airline pilots have a legal limit to the number of hours they can work per month. I think this is mostly to avoid the consequences of mental exhaustion (rather than emotional exhaustion) such as in the Colgan Air Disaster: https://en.wikipedia.org/wiki/Colgan_Air_Flight_3407
An interesting quote in that article is:
"NTSB Chairman Deborah Hersman, while concurring, made it clear that she considered fatigue to be a contributing factor."
I've often wondered if there should be a similar rule for software developers. We're required to maintain high levels of concentration for extended periods, day in, day out, month after month. I'm sure this leads to a kind of burnout that goes undiagnosed and which must, at some level, be detrimental to an employer. Is there value in limiting time spent on solving difficult software problems? Say, 30 hours a week for problem solving and 10 for training?
I find it odd that the words 'consent' and 'permission' don't appear anywhere in this article. I realise it is a purely technical article but is it off topic to include consent in an article about collecting customer data? It seems to me that sitting above all the various architectural layers, there should be a 'consent layer'.
> 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.