Dan North

> Luckily the industry doesn’t really use this term [OOP] any more so we can ignore the changed meaning.

OOP is still a widely used term today.

> It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks”.

That doesn't sound waterfall-y at all.

> If you can hire a “DevOps engineer” to fulfil a specific role on a software team then we have all lost at using the phrase DevOps.

DevOps was never about eliminating all operations roles. It is about better cooperation between dev and ops.

> This one used to mean “psychologist/neuroscientist developing computer models to understand how intelligence works” and now means “an algorithm pushed to production by a programmer who doesn’t understand it”.

No, that's never what it meant. It was always a branch of computer science, going as far back as Alan Turing.[0]

> Previously something very specific used in the context of financial technology development.

Not at all. It was coined by Ward Cunningham[1] who happened to be working on financial software. The metaphor was never meant to be restricted to financial software. The fact he was working on financial software is largely irrelevant other than possibly having given him inspiration for the metaphor.

> Was originally the idea that maybe the things your software does should depend on the things the customers want it to do. Now means automated tests with some particular syntax.

Again, completely wrong. The…

I shouldn’t post this.

It’s hard for me to single out specific patterns because it feels like the things I’m doing today (taking an idea from a written description, PowerPoint presentation or flowchart and converting it to run in an operating system with a C-based language) are the same things I was doing 25 years ago. It might be easier to identify changes.

If there’s one change that stands out, it’s that we’ve gone from imperative programming to somewhat declarative programming. However, where imperative languages like C, Java, Perl, Python etc (for all their warts) were written by a handful of experts, today we have standards designed by committee. So for example, compiling a shell script in C++ that spins up something like Qt to display “Hello, world!” is orders of magnitude more complicated than typing an index.html and opening it in a browser, and that’s fantastic. But what I didn’t see coming is that the standards have gotten so convoluted that a typical HTML5/CSS/Javascript/PHP/MySQL website is so difficult to get right across browsers that it’s an open problem. Building a browser that can reliably display those standards responsively is nontrivial to say the least.

That affects everyone, because when the standards are perceived as being so poor, they are ignored. So now we have the iOS/Android mobile bubble employing millions of software engineers, when really these devices should have just been browsers on the existing internet. There was no need to…

Due to the sheer volume of responses to this article the author posted a rebuttal to many complaints here:

On craftsmanship
http://dannorth.net/2011/01/15/on-craftsmanship/

His rebuttal is, as the author admits, better edited and more pithy. Some key parts are:

"If I gave the impression that I wanted the cheapest or quickest cobbled-together solution then I certainly didn’t mean to. I want the best value software, something that’s fit for purpose in this specific context, to solve this specific need."

...

"I used the metaphor of negative space to illustrate that the point of programming isn’t the software - it’s the information flow or utility that the software enables. Programming is not fine art."

...

"People want software because they want to solve a problem, not because they like the notion of software. Some software practitioners risk losing sight of that. That’s all."

...

"Some people self-identify as 'rock stars' or 'software' 'craftsmen' in an unfortunate attempt to differentiate themselves from regular jobbing professionals, whom they regard as less talented or valuable than themselves. I don’t have much time for these people."

Dan North lives from speaking at conferences, corporate events and tutoring classes, so coming up with novel, memorable terms is his trade mark. I attended such a class ("software, faster" [2] or something like that) around 2016. It was very entertaining, a much needed escape from corporate reality and full of great insights and "aha" moments, but none of that had a lasting impact on me. Dan's way is to reduce complex topics into simple categories - like in the OP post, he speaks about the "Dreyfus model of clinically acquired skills" [1], or pulls out a complexity-impact diagram etc. This reduction of complex topics to simple categories greatly impresses upper management with simple messages and gave us, the foot folk, hopes that we finally found the lever with which we'd make things better. But the category choices and reduction procedure seem arbitrary and I've found the messages imparted of little value in work life and corporate reality.

[1] https://dannorth.net/tags/dreyfus/

[2] https://dannorth.net/courses/software-faster/

I do find “BDD” a frustrating term.

It was coined by Dan North [0] to refer to a coherent set of sensible TDD practices — give tests expressive names, say “behaviour” not “test”, write executable “given/when/then” acceptance criteria — but in the intervening 16 years (!) it’s mutated into… I don’t even know what.

There’s a community of “BDD” practitioners who talk about all sorts of ideas that aren’t necessarily even specific to software engineering. Which is fine and good, but it’s rendered the term essentially meaningless in a software context.

These days I usually say “double-loop TDD” or “outside-in TDD” when I want to emphasise the use of executable acceptance tests; it’s impossible to predict what (if anything) “BDD” will mean to anyone.

[0] https://dannorth.net/introducing-bdd/

Programming is not a profession.

"It would be great if programming were a proper profession, but it isn’t. A profession has a structured model for advancing through levels of skill and ability, be it studying for a law degree and articles (working for a legal practise) or the years of undergraduate and medical training a doctor undertakes before specialising. The latter has clearly-delineated ranks, from junior doctor, via a brutal regime of 80-hour weeks, to consultant."
http://dannorth.net/2011/01/11/programming-is-not-a-craft/