Twitter Thread: Ranting about “right” and “wrong” architecture

I just posted a Twitter thread (a short rant, really) about software architecture, patterns and practices, and the “right” and “wrong” way.

You can find it at https://twitter.com/GDayJason/status/1359409433521004547.

But here it is in it’s entirety as well. Double-line spaces show the break between each Tweet.


I’m doing some .NET Core training on Pluralsight and along the way diving into REST API architecture and other related topics.

The thing that really shits be about architecture discussion and training is all the “you should do X” but no one EVER explains WHY!

 

 

If you’re going to write a document or build a training course that states a right way and wrong way, then explain why.

Why should I listen to you otherwise?

Give me pros and cons and concrete examples I can learn from. Help me “understand” to make good decisions.

 

 

But once again, I come back to a point I often make: “Most patterns and practices in software development are just MARKETING.”

They’re the opinion of one or a handful of people who decided how something should be done and wrote a book (or thesis) on it.

 

 

Oh, the ideas might have merit, but don’t been fooled by a flashy cover or title known to all.

These ideas are conceived and written by people just like you and me.

The danger we then face is new and good ideas are poo-pooed with “that’s not how it’s done according to X”.

 

 

Here’s the thing: “Today’s best practise is often tomorrow’s anti-pattern”.

Or it might still be a good practise, but other ideas have come to play as technology evolves.

 

Here’s the thing: “Today’s best practise is often tomorrow’s anti-pattern”.

Or it might still be a good practise, but other better practices have come to play that reflect the evolving technology.

 

 

There’s space enough for different ideas. Including ideas the CHERRY PICK from multiple practices to best fit the situation.

 

 

There’s space enough for different ideas.

Including ideas that can be picked from multiple practices to best fit the situation.

 

 

At the end of the day there is one, and only one, thing that truly matters:

The software solves a business problem.

Yes – maintenance, testing, readability, etc. But none of that matters if the product isn’t solving a problem AND being used.

 

 

But this is just my opinion.

I don’t do conference talks. I haven’t written a book.

I just have 20 years working with a lot of projects and solutions – some mine, many inherited.

And if I had a dollar for every time I saw something done the “wrong” I’d be well retired now.

 

 

And the #1 thing every single “wrong” solution I worked with did right?

It solved a real business need.

(And most developers could happily keep it running.)