Starting this blog with a book review, and what a book, probably one that influences greatly my career path ahead of me in years to come.
In a nutshell, ๐ฅ
Enlightening โก book
Gary takes us in a journey through the seas of patterns and practices that helps us build quality software because it means with them we can write adaptable, maintainable, testable and even, readable code, go figure! We all could use some of that.
He explains with enough deepness, behavioral and architectural patterns (and anti-patterns) and demystifies SOLID principles to achieve all of this, and explains what Test Driven Development is all about and how to leverage it to write quality tests which leads to less technical debt.
At the end, he shows how to put all things together with Dependency Injection. And also some guidance of metrics like Coupling, Cohesion, and Connascence, which I wish we could get more of it, because I believe the more we measure, the better we can see progress in our performance.
He even dedicates and entire part of the book to Agile and Kanban because without proper execution, simply there is little you can do as developer when projects struggle to find proper management of work items, that however may deserve a deeper understanding and overall, practice, that more often than not, is not in control of the developers, but is our responsibility we are ready to use them and to encourage the use of proper Agile practices.
It is all about how we deliver value and with how much quality.
But also, ๐คทโโ๏ธ
Leaves me with more questions or adds more to all time questions I have had no answers in my 10+ years of experience as developer.
It left me wanting more!
First of all, ๐
Is this some kind of forbidden knowledge?
Maybe, because too many people have tried to debunk these patterns and practices in order to do their own over or under engineered ideas?
I mean, this is not new at all, even though I think Gary makes an excellent job at demystifying the core of the principles and patterns and have clear words on explaining a lot that otherwise may appear too abstract, the way most likely you find on the web.
And, honestly you don't hear many co-workers talking about in the daily coding drill, I guess I've heard more of it in interviews ๐ค
Are we experienced enough? ๐ด
One thing is clear though, you don't get enlightenment out of this book if you are not an experienced developer who have gone through a lot.
And by experience I don't mean doing the same way of years of crafting software over and over with the same company, same technology or architecture, or the same project, nor I mean you need 20+ years of experience; at least, 5 years involved in diverse projects for sure, small and large, with different approaches, with multi-cultural and interdisciplinary teams, small and large; facing the problems of, and not limited to, not testing, not properly abstracting, not using interfaces and patterns properly and constantly battling the technical debt left behind affecting the project health.
That is the only way you can appreciate what is exposed here.
Then we all have a story on failed projects ๐ฉ
Why the struggle of having to go through failed projects that have accumulated to much reckless technical debt that there is no recover from it? Too many broken windows that lead to unrecoverable trend downwards as explained in The Pragmatic Programmer
Decision makers and leaders have to step up and take responsibility.
But how do you reverse this trend? Meanwhile we wander around with our own "good enough" implementations of code, not leaning towards an Agile ever changing environment, but heck, even Agile is more often than not an incomprehensible abstract, if that's what we got in the process, what can we expect from the ever hidden humble code only visible to the developers.
Far too many projects and for far too long, Software Entropy in projects is still a constant.
Why is it hard to come together and craft quality software? And who is held accountable for it?
Why is this even relevant? โฐ๏ผโตโกโฒ๏ผโฏ
While these software practices may have been forgotten for some, new to others, or misunderstood by the majority, and as new trends of creating software arise like Power apps, 0-code builders, or AI powered magic; we still have to build the systems that interact with or extend these abstractions for generations to come, and how you build it and how you execute it, still matters.
Tightly coupled is the way you manage or execute a project being Agile or otherwise, and how you code it through software practices that drive your craft.
As engineering mindset or IT community have we really agreed upon a set of practices before moving on or try to avoid them?
Have priorities got in our way, or time to market, or deadlines, or the process itself to deliver fast while compromising quality?
So, what are we missing? ๐
Is this science? ๐งช well yes Software Engineering is a branch of Computer Science right? but perhaps is just too hard to prove several practices usefulness until you really practice it, and put effort in understanding.
Perhaps there are too little too few examples of success or real-world validation.
Perhaps success stories exist in the world and in the knowledge of teams that will be archived or left out for others to learn their experience.
Perhaps too much is left to each one of our egos and theoretical interpretation instead of relying on hard evidence, maturity or metrics.
Is it a change of paradigm? pretty much like Reactive and Functional programming is to TPL and Imperative programming, why people will not invest on trying things out?
Maybe what is lacking is how we communicate it all in a efficient way, maybe we need more examples, or improve guidance and understanding of the advantages. Pretty much like everything else in software engineering.
I'm willing to seek answers to these questions, even if it is the purpose or my entire career.
I have seen enough, I'm done catching up and dealing with acquiring technical debt, being too many times close to failure due this, I want to change how things work for the better, even for a little, and I'll take the first of many steps with hopes of many to follow and learn with me, but I'm also open to join whoever share the same values; moreover, the same questions seeking answers.
Thank you for reading my review but overall, I guess sharing with you the frustration I think many of us share. If you are interested, I am working on a humble open source effort regarding architecture and software practices using .NET in my GitHub to help me understand more about all of this, and hopefully help others:
At the very least, I want to have some good examples of good design :)
Top comments (0)