I take the following view:
Software patterns and “best practice” are just the opinions of people who managed to get published.
Who says they are right?
Why are they right?
Are they right?
Because in my considerable experience there is no such thing as “best practice”:
You do the best you can, with what you have, under the circumstances at the time.
As for software patterns…. pfft!
I’ve tried reading “Design Patterns: Elements of Reusable Object-Oriented Software” and “Patterns of Enterprise Application Architecture” and never made it more than a quarter of the way through. (I think I made it further in War and Peace when I was a teenager.)
Then there’s SOLID and REST APIs.
(REST was a f**king thesis for goodness sake!)
Some people blindly follow the so-call best practices of software but forget they are just the opinions of a handful – literally a handful – of people who manage to get noticed or get a book deal.
And in no way do they reflect reality.
Reality is “average” people try to figure out the best, fastest and easiest way to implement software for business requirements that won’t get them fired.
It’s 2019 and today we’re all supposed to be doing DevOps, Agile, writing unit tests, performing automated testing, using non-SQL databases, in the Cloud, following OWASP Top 10, logging and auditing everything and making no mistakes.
(There are major companies in my city with names on the top of skyscrapers asking university students to teach them about DevOps pipelines.)
The reality is it’s no better than 15 years ago.
We still haven’t solved the “low hanging fruit” problems.
Every day brings a new data breach. Automated or unit testing is not in the budget. Agile just means standing in a circle telling your team what your working on each morning (if your team lead gets their shit together). Many businesses are still running Exchange, Active Directory and databases on-site. Windows 7 is still live in Enterprise. Testing is more of a pain-in-the-ass than ever, Selenium still sucks, and SQL databases still rules.
(Also jQuery isn’t going anywhere, and if Google or Facebook were really ‘that good’, why are there so many versions of React and Angular where they’re still trying to get it right?)
Plus there is still someone running a PC under their desk in a small-to-mid sized business with the all important Excel file/Access database/ASP website that the business lives-or-dies on.
Just because the most vocal people in the industry say “it should be” doesn’t make it so.
Businesses still pays the bills, and the priorities of businesses are not the “best practice” of software development.
Businesses don’t give a shit about “software best practice”.
That doesn’t make it right – but it is reality.
Right now I can’t recite to you a single definition of SOLID, or tell you definitively how any software pattern is supposed to work.
But I’ve dedicated over 50,000 hours of my life to creating software and solving business problems with software, and I can tell you this for certain: it doesn’t matter.
What really matters is simple:
- Keep solutions and code simple.
- Always think about security before anything else. (Then actually make your fucking systems secure!)
- Make software usable and understandable for users.
- Create readable code for yourself and your fellow software developers (if it can be read by a junior developer you’ve done your job).
- Write documentation. Code is NOT self-documenting – it requires documentation and comments.
- Make sure the software can be maintained and changed easily.
- Log changes and events. It doesn’t matter how – just make sure you start logging from day 1.
- Watch and monitor the systems you build.
- Remember: You are not the user. How you think it will be used is almost certainly wrong or not enough.
- If you find yourself fighting your tools or swearing at your screen, you’re doing it wrong.
- Bonus: Command-line requires you to remember command, and more manual work. GUIs do not. Create GUIs. Command-line sucks.
And any estimate you give, multiply it by 3 first.
Finally, consider this:
The only times I’ve ever discussed or had to describe software patterns is in highly technical job interviews.
What does that tell you?
I talk to a lot of developers, on a lot of topics, so why haven’t we had “software pattern” conversations in passing?
I would welcome it! If only to learn how other developers have implemented different software patterns (successfully or otherwise).
In reality I think we all work with different patters, we just don’t think about it at the time, and frankly who gives a shit – we’re doing our job. Do we really need to say “hey, I just implemented the observer patter”? (I had to look that up to give you an example).
I’ve spent almost 20 years reading and and modifying other people’s code. I’m an expert debugger in my field (CSS is my favourite, and raw JavaScript is my friend).
I don’t care what patterns people use (because what’s the “right” or “wrong” pattern anyway?)
What I care about is being able to quickly and easily read and understand code when I have to fix a problem that is causing difficulties for a customer or employer.
Software patterns and “best practice” don’t mean shit.
What matters are:
- Business continuity
- Security
- Usability
- Readability and Maintenance
- Extensibility
Everything else is a side issue.