I'm completely on the same page with you on that one.

I understand though the marketing needs. IT has this steady influx of beginners that don't have the insight yet. Since there are so many of them, at any given time, it's reasonable (or maybe it actually works) to use standard advertising techniques at them. "Secret sauce", "The missing puzzle piece", "10 things that make you a better dev", "Dev done correctly".

Developers are kind of a dream target group: lots of disposable income, technically adept (i.e. at the cost of social skills), excited to experience a latest unicorn.

I'm seeing this whole "hype cycle" thing as a competition among more senior, adept in marketing, developers. Since there is such a high demand, the supply is also rich.

Could/should there be a 'wikipedia for software development practices'?

What about https://wiki.c2.com

Something along exactly those same kind of lines of intent, yep.

A wiki-like reference guide that can assist architectural and technology selection recommendations.

Potentially with support for argument mapping[1] and decision trees[2] to deal with contentious or context-sensitive topics.

[1] - https://en.arguman.org/

[2] - https://en.wikipedia.org/wiki/Decision_tree

it's been read only since ~forever

Genuine question: whats wrong with wikipedia itself?

I have often wondered this.

For some reason, important information isn't making it there. There's no page for Chain Replication. Maybe nobody has tried to add it? Chain Replication has been around for so long that it seems unlikely nobody would have tried to add it.

Wikipedia also seems to fall apart at the seams. It's great at giving you the answer to questions for which there is an unambiguous answer, but it doesn't do a good job of answering all the other questions you might have. Why is Prolog not very popular, what seems to be holding it back? Any answer to this is mostly speculation, something which is not allowed on Wikipedia.

The problem is that way many aren't able to sponsor conferences, do talks about "how we rewrote X in Y", write blogs about best practices and sell books.

Yes I am being cynical as well, but have a quite filled up bookshelf to prove my point.

> DDD promotes (...) test driven development.

It does not, nor does the blog post say so. The two are completely orthogonal, and while TDD is a rather questionable development method, DDD is a widely accepted design principle.

> TDD is a rather questionable development method, DDD is a widely accepted design principle

These claims are orthogonal, so the "while" construction is misleading.

TDD and DDD are both arguably questionable and both undoubtedly widely accepted.

> I might be a bit cynical / neckbeard, but the tech industry tends to go in circles with good engineering principles sold as the newest fads / hype.

Not cynical at all — this is well observed and I wish more people saw it. I think software engineering is more susceptible (permissive cause) to fads because so much of the work is more craft than science and the actual catalyst (proximate cause) for the faddishness is the economic incentives driving the posturing for "thought leadership".

Consultancies need to compensate for generally not having a long-term stake in the projects they work on in order to overcome skepticism from clients so they have to invest in content marketing via thought leadership. The principles of marketing don't change -- convince people they have a problem, sell them the solution.

In a similar fashion every developer has various incentives to either consume and propagate or create this kind of content as well.

The only check on faddishness is well-grounded technical leadership.

I think you're missing the point. They're not fads. They solved a problem for certain people in a certain generation. Technologies and trends rarely make it beyond 10 years and every 10 years we come up with new technologies, new abstractions, for new generations.

I agree with some of the other older hands in here, much of technology 'changes' are rarely anything new, just new names and tweaked implementations of much the same core elements. New generations like new names, worded in terms they become familiar with. Doesn't make them less valid, but often not as new as perceived. Much like the music business, new bands put out covers of old music, new audience thinks it's a great new sound, but underneath it may be very much the same old song.

This is really not true. While every industry, and especially Software Engineering, is prone to hype, the reason things become popular is that they deliver real value.

REST API's and microservices are a design that originated when software teams started growing in size and didn't want to lose the agility they observed when having control of their complete stack. It was enabled by a fundamental shift in infrastructure: previously, everything was managed by dedicated infra teams, but Containers and Container Orchestrators gave development teams control of their deployments. The old model of monolithic services stood in the way of developers who had access to this new power, and hence microservices were invented to address that.

I could give you similar reasons for the rise of Big Data, Infra as Code etc. Every one of these changes are driven by changes in fundamental technologies. They aren't fads.

When I read the article and looked at the e-commerce diagram, all I could think was "hmm, this seems to be pretty much exactly how we implemented the early versions of amazon.com, except without any of the this technology or terminology".

Don't forget cohesion. Microservices achieve the highest cohesion usually since the microservice does just one thing. It's reasonable to combine services together, as long as cohesion is maintained.

You've just plotted a course for SPONCS using TEO and WGD