Not too long ago, a few years back, I started building a perception I've had for a very long time, 25 years (of professional career), which sounds quick to say. I've built a mental model that allows me to approach software projects with an extremely high degree of confidence. Extrapolating from the wonderful Cynefin framework, I could say that in most cases, I can move from the domain of the complex to the domain of the complicated, and from there, to the domain of the simple. I'm going to try an unprecedented communication exercise to convey this somewhat abstract mental model and see what comes out.
A Developer’s Reality
If you've been working for a few years in the wonderful field of software development, you'll have realized a great truth:
Formal training (college degree, bootcamp, etc.) is rarely enough. In fact, I can confirm something that might be a great fear or a great motivation: You're going to be studying and adapting for the rest of your professional career. This is how it is; survival without continuous learning leads to frustration.
Learn to identify complexity
One of the biggest errors I've seen repeated countless times is related to the vague interpretation of many so-called best practices, principles, and methodologies. But it's not a common mistake for nothing; I myself have committed this error hundreds of times, and often this misinterpretation ends up manifesting in a very serious problem: Over-engineering, or as Fred Brooks brilliantly exposed in his paper "No Silver Bullet": Accidental complexity.
On Over-engineering
My mistake was failing to assess the complexity of the problem or misjudging the domain of complexity I was operating in, which inevitably led to over-engineering.. You can only realize how much pain it causes when you have to maintain your own creation and start worrying about things like delivery performance or your team's health (development experience).
I'll give you an example that was on everyone's lips for a while (until ChatGPT diverted all our attention). Microservices!! But what madness has everyone gotten into with microservices architecture! No, microservices architecture is not bad. Yes, your experience with this architecture is horrific because probably the essential complexity of the problem you wanted to solve did not justify using this architecture. And yes, microservices architecture adds a great deal of complexity, and is crushing you because you fail to evaluate your domain of complexity.
Another example. Yes, Domain-Driven Design is truly a before and after in how we build Product in the industry. But Eric Evans himself says it explicitly, even in the title of his extremely boring book: "Tackling Complexity in the Heart of Software". You don't need to implement each and every tactical pattern Evans proposes if what you're going to do is CRUD where you can tell me from memory how many tables you'll use. In fact, you don't even need to decouple Domain from Infrastructure! You have 1000 lines of business code, Juan!. The cognitive load is minimal!, you don't need to pay for another abstraction, it's only adding extra complexity. Remember, all indirections have a cost.
Keep learning
There's something even worst and more perverse, though, and I'm going to be very clear and somewhat harsh:
- If you don't know how to separate responsibilities
- You ignore the benefits of writing readable code
- You are unaware of architectures that allow you to test your software without severely affecting your mental health
- You name variables with the first thing that comes to your mind
- You are not aware of the consequences of coupling or low cohesion
- You are not able to articulate a coherent testing strategy
- You are unfamiliar with basic design patterns
- You make decisions without being guided by data
- You don't talk to your Domain experts
- You create proof of concepts that extend for months and then, of course, then complain about things like "the code isn't ready for Production! Stakeholder don't allow me to build it from scratch!". Juan! Wake up! Your team just spent four months’ worth of salaries
I'm sorry, but complexity is going to eat you alive. Every professional programmer who wants to have a successful career should arm themselves with all the knowledge at their disposal to fight against complexity. In fact, if you ask me, I would say that software engineering is precisely about keeping accidental complexity under control, and to fight against it, you need knowledge. Don't skip the introduction chapters of the top technical books, almost all of them refer precisely to complexity, because it's important, because it determines everything. Otherwise be prepared for frustration, stress... survival. Well, this isn't a guarantee either, okay? Paraphrasing once more, if you'll allow me, the illustrious Frederick Brooks: "No Silver Bullet". But with this arsenal of knowledge at your disposal, you will have maximized your chances of enjoying a much more pleasant and successful professional career experience.
On Agile
One last thing I really need to talk to you about how my epic journey towards discovering new ways to fight complexity, from a technical leadership role, has led me back to the world of Agile. Yes, I denied it for a long time, and I think I wasn't wrong back then, but now? Now it makes a lot of sense. And a personal reflection, along with a prediction. My intuition regarding why Agile is not the default option in most projects today is because 15 years ago, the Rock Star Developa' would save your ass every single time, and today, you need several teams to support your business. It's now where Agile shines, it's now where it makes sense. The prediction, evident at this point, is that Agile will return, whether people like it or not, and I believe this is good news.
Radical Simplicity
I'm finalizing. There will come a point in your professional career where you will correctly identify the domain of complexity in which you move, you will start using all that acquired knowledge when necessary, and you'll see how everything starts to flow in a marvelous rhythmic harmony... okay, sorry, it's not that beautiful, there are many other things that will escape your control, but even so, it doesn't matter, you will know how to react and adapt accordingly. It will be at that point where you'll realize that all the principles and concepts you learned, will be eclipsed by this one one: Radical simplicity. Honor it, and you will enjoy your profession much more.
I finish. Master complexity, embrace simplicity, and thrive in your career
Top comments (0)