Actually, our approach is not that different in principle, to most architecture guides.
This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.
You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.
> They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The idea that other companies are all sheep following some clearly-defined, but wrong, practices is getting old. At this point, I’m extra cautious about working with people who insist that they are “not like the other companies” as a point of pride, because it nearly always means that they value being different for the sake of being different.
It’s one thing to evaluate different practices and adapt them to what works best for you and your company. However, when people take it too far and adopt a mindset that they must be different than others because they don’t believe anyone else can do things as well as they can, it becomes an exercise in arrogance.
Completely agree. You don't even have to go much further than reading the title with some more intent; How is having a "Clear and Simple Design" not a way of architecting a project?
It might be less arrogant and clickbaity if they had framed it this way: design patterns and architecture methodologies are training wheels for understanding how to design and build systems at scale.
Folks commenting that this is obvious are overlooking the way that architecture and patterns are often explained to junior-level engineers -- especially new engineers who aren't working for a company with strong engineering cultures.
When I started out, I thought the way to become a senior engineer was to increase the number of patterns I knew off the top of my head. It was by speaking with more senior folks that I learned that wasn't how to grow, but that was far from obvious.
When I was in software engineering school, we had a tongue in cheek word for this: patternitis.
Many undergrads who took the software architecture class ended up catching this strange disease that compelled them to write abstract singleton factory builders and other silly things. The cure is basically to write enough software to figure out where these patterns make things more understandable and where they detect from what's being written.
Maybe the GOF book needs a content warning for that. :-)
Fooflation - Avoiding descriptive names of methods/variables in favor of "result1, result2, goOn"
All fixed with a little TLC and experience :)
There's a funny overcompensation that greenhorns have when improving their code. Someone will ask them to use better names, then you get a few months of `let loopIndex = 0` when `let i = 0` would have been just fine.
from the article:
> it took me a lot of time to understand what this pattern does and had my "aha!" moment
The patterns are shorthand to discuss a set of concepts that can be useful in considering solutions to certain problems. Once the designer encounters those problems, and understands how the patterns can be used, the value is apparent.
It doesn't seem too different than many areas of mathematics, where the jargon burden is real.
Can the concepts be explained to a lay user? Yes.
Can the lay user then apply those concepts to solve problems? Likely not except in the most superficial of cases - the lay explanation ignores much detail that is required to get an effective solution in non-trivial cases.
Everything seems to work that way. Pick up a martial art, auto racing, music, rock climbing, new language, whatever. At first most people focus on all the new concepts in the hopes it'll help them progress. It's only later they realize it was the mistakes they made along the way that led to real knowledge, not the technical stuff.
This reads as something obvious. Of course between choosing a simple solution and a complex over-architected solution, you would choose the simple one.
The key word here is “over-architected”. The author is nitpicking academic and bureaucratic architecture design that happens at large (arguably inefficient) companies. But they evolved that way to protect themselves, probably before testing was widely understood or implemented.
Regardless, it tries to make a sensationalist topic when in fact it’s trying to say “architecture is common sense” + don’t prematurely optimize.
Overall not the worst article but its incendiary nature rubs me the wrong way.
- Let's first start with the false dichotomy. Software Architecture is not orthogonal to clear and simple design, and clear and simple design is not orthogonal to software architecture.
- Let's assume the dichotomy exists. I used to think this way too, as well. I was vehemently against the architecture astronauts. As I got older, and worked on more projects, and gained more experience, I learned that I was simply in a position where my architecture decisions didn't have a drastic negative impact, at least certainly not in the near term, nor mid term in most cases, only in the long run. I could get by with, well pretty much anything, so long as it "just worked" (TM), and we had the ability to debug and diagnose quickly when issues came up.
- Apps, Web development and the such can afford to get by with some questionable architecture, because they are mostly standing on the shoulders of giants, starting with the architecture of the internet itself all the way to most databases, libraries, frameworks and tools, and even some languages, that make common web-based development tasks like parsing JSON, performing RPCs, or working with DateTimes pieces of cake compared to yesteryear. If you work with distributed systems, you use some sort of well architected consensus solution, with likely a well architected software package or library to use it with, that likely will cover up a lot of your mistakes and misuses.
- Working at a major bank now, with friends at other major banks, there are some outright fallacies described in the article. Maybe that was the case when this person worked there, but it isn't the case today.
> All of these systems were large at scale: hundreds of developers build them - or on top of them - and they power systems used by millions of people per day.
But it's still likely that you simply leveraged existing libraries and tools built on solid architecture. In fact, I have a little inside baseball at Uber to know as much.
Bottom line is, you can't get to "clean and simple design" without being good at writing software and having a wide, diverse array of experience. I would say that is almost the essence of software architecture.
If you are already an experienced architect/engineer, then you don't need to follow standard models and processes, similar to how an experienced woodworker doesn't need to use a tape measure, or how ancient people with centuries of experience built amazing wonders of the world without fancy diagrams.
But most companies do not have a lot of experienced architects building products. A lot of companies can barely keep a handle on their dev teams, and worry a lot more about regulation and herding cats than building a decent product, so their Architecture Teams are actually Cover-Your-Ass Teams. Dev teams often don't even know that other teams exist, much less have any way to circulate a single diagram to them all, or talk about what the hell it's even for.
If all you've ever worked in is a tech company in San Francisco/Seattle, let me tell you... It's ugly out here in the land of normal businesses.
So software architecture is really for the average people working in average companies who could use a hand figuring out how to design and implement their product. They have never even heard of C4 or ADR. But those simple models and processes would absolutely transform their work from barely-functioning balls of shit, into the gloriously robust design the author's company came up with. Nobody else is helping them figure out how to do it; best practice is what they've got to work with. If they even know about it.
Reading through and wondering for perspective, this caught me:
>No IT architects or enterprise architects. True, neither Uber nor Skype/Microsoft have hands-off software architect positions. Engineers at higher levels, like staff engineers, are expected to still regularly code.
That statement says that EA is not commonly coding. Is that true? I don't know that I've met many architects that aren't engineers by another name (possibly cross departmental/enterprise).
Depends on the type of organization, and especially for titles like enterprise architect. Most people I know with enterprise architect titles don't code. They're mostly at non tech companies like banks, telcos etc. Even the standard software architects at many non tech companies don't code, or at least don't code much.
My wife shared a house for a short period of time with an architect who was fairly new out of uni and did not know how to code, or have any real tech skills.
At the same time I was working for large companies in digital transformation trying to teach them to let developers make decisions.
It's common EA is about PowerPoint and talking to vendors with checklists, and doesn't require strong or sometimes any tech chops.
Enterprise Architecture is a very different discipline from software development (and even solution architecture), and are usually found in non-tech organizations (i.e. banks, insurance companies, etc).
EA is focussed on evaluating the business processes and technical solutions that make up the operations of a large scale organization. They try to identify and remove redundancy (e.g. multiple billing systems) and ensure the solutions in place (custom internal, or vendor purchases) are fit-for-purpose from technical, business, and strategic standpoints.
It’s very far removed from the practice of software development (since the correct solution, from an EA standpoint, might just be to stitch together a handful of vendor systems and do away with custom development completely).
Much higher level than a System Analyst. Enterprise Architects often work directly with the CIO/CTO to shape an organization’s long term technology strategy (i.e. 5+ year time horizons).
The idea being, they are supposed to be “architecting the enterprise”.
> an architect who was fairly new out of uni and did not know how to code, or have any real tech skills.
This sounds more like a sales-adjacent role that pitches a company’s tech product lineup to the likes of product managers and other non-technical people at potential clients companies. For these roles, having someone who isn’t too deep into the details of the technology can actually help connect with other non-technical customers. You quickly remove this person from leading meetings and insert someone with tech skills if the other side shows up with actual engineers, though.
No actual engineering team is going to have an “architect” fresh out of college who doesn’t code or otherwise understand the tech. Having someone architect a system without understanding it doesn’t make any sense.
Neither software architecture nor design matters. The only thing that matters is whether you deployed your code to production. Code in production that solves customers’ problems right here and right now beats any architecture and design.
what about the poor sap who has to fix the muck you JustShipIt'd. are you selling to the public? that's bad for the brand. are you selling to a corporate? if so, you WILL have service agreements.
Of course it matters. If your code is an unmaintainable mess it now costs a million to add a bunch of features instead of $10k. That matters to someone. Maybe not the customers though.
Actually, our approach is not that different in principle, to most architecture guides.
This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.
You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.