This is what an architect should be doing. Too often people are made architects that never had to maintain a system more then a few years if that and aligning new tech for every problem until you end up with an unworkable, inconsistant, mess that can't be easily estimated.
"Studying a lot of books, articles, codebases and discussions on software architecture" - like what? 90% of it is "write clean code", "put in a cache", "normalize your db", "use a queue if the service is really spotty/unreliable".
"Fundamentals of Software Architecture" is 95% fluff. So is "Clean Architecture". Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect unless there is a real cause for it. 90% of the job is NOT overcomplicating.
"Trying to persuade people to avoid technical debt at all costs" - put in a linter and concrete rules (even if a rule is loose, note that in writing) or devs will get upset and think you are singling them out.
Those approaches are not “fluff” or overly complicated if the problem-space warrants them. There are of course limits.
If you want to write a script for use once or twice, worrying about coupling and cohesion is probably not worth your time. If you are building a system to last 2-5 years out, it absolutely is worthwhile.
If you have a dead simple CRUD problem with very little business rules/operations then DDD isn’t right either. But if you have a complex set of interactions, state, and policies it’s the right call. (The big red book of ddd has a great table on exactly this)
But there are problems out there that are suitable to those approaches. The devil is in the detail; unfortunately a lot of strategic design goes by the wayside to cargo-cult zeal.
But the same can be said for the other way of thinking. I’ve worked/work with engineers who think any form of abstraction is abhorrent and that they don’t need to care about quality because they’ll delete it all and start again (they’ve not tended to care about the opportunity cost of that to their employer, either). Any database interaction looks like ActiveRecord and all technology choices are immutable.
The key in all things is balance. What is simple vs overwrought is almost entirely down to what the framing of the problem is.
Also, I agree with you about over-complicating with all those patterns. But before I am able to dismiss a solution, I have to understand it. Trying to keep it simple is hard
@lexx, i think most of the things you put in your answer were very reasonable and non-controversial and probably what most good senior-ish engineers do. I think the parent comment is slightly in his "local minima" and he's generalizing his experience to everyone else
>"Trying to persuade people to avoid technical debt at all costs" - put in a linter
This for example does not make sense to me. This would mean all tech debt is just static analysis. There is no linter for figuring out the correct abstraction and using them correctly.
Eg. no linter yet will tell you "hey you should have used a state machine here!"
You need a width range of experience before you can develop "better" taste in what's good and bad in different scenarios. Some of it can be gained from years of
experience, and some from exposure to books/code.
Definitely nothing against what Lexx said. I did want to call out that most architects over-complicate in my experience. What we do just isn't as profound as people make it out to be unless you are genuinely working on some latest ML for billions of revenue or stabilizing SpaceX's landing thrusters, sequencing DNA, etc.
Having a broad and deep understanding of a range of design patterns in an otherwise banal enterprise environment is critical when the existing technologies you work with are numerous, decades old and have built up like layers of sedimentary rock.
>in my experience
Friend, you're making it clear that you don't have much.
Apart from those best seller books, the are great podcasts and articles that people discuss their experiences in depth. It helps me a lot, to compose a more holistic thinking.
Technical debt does not increase only for technological reasons but also from business expectations. You can't just "build" a new garden and leave it be. You have to maintain it also. Keeping the system clean and well oiled before building more is important. But these concepts need to be reminded everyday to survive
> "Trying to persuade people to avoid technical debt at all costs" - put in a linter and concrete rules (even if a rule is loose, note that in writing) or devs will get upset and think you are singling them out.
I went from a company with no linter or style guidelines and PRs were an absolute nightmare. Eight devs, eight completely different styles, each insisting theirs was right. I wasn't able to turn stones into loaves (i.e. I wasn't a Senior Dev at the time), so my style was categorically incorrect. I switched to a company with an aggressive linter, and all that superfluous debate over tiny patterns and "personal preference" went out the window. I no longer dreaded PRs.
I think that's the main benefit by far - avoid useless debate. The icing on the cake is that I can write code in my style (tabs instead of double spaces, parens on new line, whatever) and then have my IDE or a CLI command refactor to the team style before putting up a PR, so it's really not an issue.
I usually default to some large company's style guide so it's difficult to argue against. For example, for .NET we use Microsoft's style guide for React we use Facebook's, etc.
- Spending a lot of time trying to figure out the business better
- Studying a lot of books, articles, codebases and discussions on software architecture
- Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics
- Balancing everyday and urgent business needs while leading towards a more simple, boring and maintainable system.
- Trying to persuade people to avoid technical debt at all costs