If you like good, easy-reading and free knowledge like me, you will surely find taking a look at 97 Things Every Software Architect Should Know worthwhile.
“I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively there are no ideals. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.”
“But alas, ceci n’est pas une pipe.”
I also believe that software engineering projects do share some common issues (or at least I hope for this, any morale booster is welcomed: software engineering is such a challenging discipline that despair is frequent !).
“97 Things” points out some topics and solutions that should probably be applicable for any software engineering endeavor.
There are some big names and many years of experience behind these tidbits of wisdom, and in my short career so far, I have found many of the described issues in “97 Things” in past and present projects.
Because 97 things are too much for my short term memory, these are the top 3 things to know that I strive to remember:
1. Choose the most adequate technology
Very often, the technology chosen to solve a certain problem is not the optimal solution.
As stated in Don’t put your resume ahead of the requirements, sometimes technologies are chosen just because they are “newer than” or “cooler than” other technologies that would be more adequate.
In other cases, the same technology is used over and over again. There is no one-size-fits-all solution. In most cases this is caused by one of the greater dangers in software engineering: prioritizing component/architecture/code/design reuse over any other criteria. In many cases, the business case is adapted to use an existing solution, when it should be the other way around. I have not seen worse evil than corporate frameworks !
We should probably ”think outside the stack” more often, and choose the best solution for each problem: Heterogeneity Wins.
In Simplify essential complexity; diminish accidental complexity Neal Ford’s explains this error (in a developer context) perfectly:
“Developers are drawn to complexity like moths to flame, frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn’t like the rush of solving some incredibly complex problem? In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging”
He also adds:
“Look at the percentage of code you have in a solution that directly addresses the business problem vs. code that merely services the boundary between the application and the users”
Know when to stop (“Perfect” is the Enemy of “Good Enough”), Don’t Be Clever, Make sure the simple stuff is simple and remember that You can’t future-proof solutions, that Application architecture determines performance and that Scope is the enemy of success !
3. Know the business case
If you Understand The Business Domain and realize that Context is King, you should be able to challenge client-requested system-constraining unneeded requirements and Seek the value in requested capabilities and Quantify fuzzy demands.
And everything else…
Online and free…so there really is no excuse not to take a look !
Related posts:Knowledge Source, Michael Nygard, Neal Ford