The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.
AWS services don't mesh nice with each other, and the reason "software architecture" exists in the first place is so that disparate teams and technologies play nice with each other.
The disparity within AWS is the result of common inevitability that arises with managing technology built on over a decade of scaffolding. For sure there is a central planner within the company trying his best to put everything together into a cohesive whole. Technical debt is the most common name for this issue.
An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt because neither person can see the future. It's like pointing at everything wrong with a piece of technology and saying an "Architect" could've fixed that in hindsight.
"Architects" are not the solution to technical design and technical debt.
An engineering manager can place all engineers in a room and ask them to come up with an "architecture" that is the same if not better than anything a single "Architect" can come up with, and this "Architecture" will never solve the problem of technical debt for the same reason why we can't predict stock prices.
> In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones.
Yup. In that context, it is usually called Second System Syndrome (when discussing the person that is laboring under it's influence while in the act of designing) or Second System Effect (when discussing the resulting system):
I think if you ask, most anecdotal evidence from people who have worked with architects shows that companies with "software architects" don't necessarily have less "technical debt" then companies without.
Theoretically, those "software architects" would put a stop to "over-engineered" solutions, but why do these companies still have technical debt?
Most likely because technical debt is not solely just "over engineered" solutions.
But you can. The separation is critical to the entire computing industry. The entire reason why higher level programming languages exist is to separate the form (assembly) from function.
Usually there are "costs" to doing this and much engineering work is done to reduce this cost as much as possible. Either way, what you say is categorically wrong. Separating form and function is not a "mistake" given that it is so fundamental to the entire industry.
Ah, but I would argue those are better described as form and function being part of the designs. Done wholistic, it is why the new apple hardware is able to take some very impressive gains.
You can argue that some interfaces are separate products from the services. I agree with that. But each has its design and each is targeted on form and function to something.
That is, you don't separate them. You make a new product, that has its own form and function.
My remark is based on what you said. You called the separation of form and function a "mistake" and I said this is categorically wrong. My statement still stands, you have not addressed it.
I neither agree or disagree with your remark about "Wholistic" designs but your example is extremely inapt.
The entire MacOS is programmed using a an interface separate from function. If they didn't program the Operating system in a higher level language that can be compiled into separate architectures then the move to ARM would be an even more complex engineering maneuver. The entire reason why Apple was able to move to new hardware without completely rewriting the software is because Form and Function are separated.
My address of it is that things don't separate to distinct things, often. They, instead, made new forms that have their functions. Or vice versa, if you want.
This is true for content as much as services. In simplistic cases, you can point at something and say "there is the content." Often, though, you cannot. The distinction between the two is a huge blur.
You are bringing up, essentially, that abstractions can be layered. I agree with that, with each layer having is own forms for its functions.
Applied to the example here. I am not saying they are identical. I'm saying that they are best considered together. Such that our industry typically passes the buck on UI and UX, to the detriment of everything.
No. I am bringing up the fact that form and function are always separated in our industry and that this is fundamental to the entire industry making your initial statement categorically wrong.
It's obvious that abstractions have costs and it's obvious that sometimes things are designed holistically. But these obvious things are off topic. The point here is that your initial statement is completely and utterly wrong wrong wrong.
Please stay on topic. Are you still claiming your initial statement is right? or are you now claiming it's wrong? Don't change the topic into the industry "passing the buck to UI and UX" this is not your initial statement.
My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :)
Are they separate things? I mean, yeah. But they interplay with each other such that near every attempt to force them apart is full of ugly edge cases such that I assert we would benefit from people seeing that form and function typically work together in building things that work.
>My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :)
Ok, so you are basically implying that your opening statement is wrong and what you meant to say is that abstractions do not have zero costs and that the industry is unaware of this. Just admit you're wrong instead of relying on the political stratagems used by "architects" to stay relevant.
I would argue that everyone is fully aware of this concept. It's a necessary evil done to reduce complexity otherwise we would all be programming in assembly language. As for AWS specifically, isn't it proof of what you say? The technical details are leaking into the interface showing that function and form can't be fully separated.
If you're saying the architecture of AWS should have been holistically designed to support a more intuitive interface, I would say you're describing another problem all together. A holistic design is a synonym for "waterfall," and there's a good reason why it's avoided in the industry.
The problem with waterfall is that the current needs of the market is always a moving target. No architect or even UI/UX designer can predict the needs of the market in the future thus things are continuously put together agile style (aka ad hoc). This produces technical debt which is something neither Architect nor the UX/UI designer can solve. AWS definitely suffers from some debt and the UI reflects this, but again, this is NOT because they lack "architects" as every company has this problem whether or not the company has "architects."
With my statement following the claim that UI/UX is not an architectural issue, I'm not sure how you are getting this reading.
I maintain that separating the ui/ux from the architecture is a fools' errand. Any other reading of my statements, while almost certainly my fault, don't make sense here.
The way I took it is that you said your original statement in a broader context along the lines of "in computer science form and function should never be separated." And you used that statement to apply it to UI/UX and architecture.
This statement is patently false, especially for UI/UX. Even at the lowest level there are platform agnostic API's (opengl) that are divorced from CPU/computer architecture. At even higher levels, javascript/css/html is a graphics API that is divorced from even the operating system. Separation of form and function is the foundation of software. It cannot be a "fools errand" when all of UI/UX is designed with the separation of form and function in mind.
It is therefore fundamentally impossible for you to stand by a notion that is completely false. More than likely your statement is just a mistake and you didn't think it through. Such is one of the downfalls of "Architects"... they are so concerned with high level truthisms that they fail to even build the correct high level picture of the computing world.
For software systems, the devil is, unfortunately, in the details.
You still seem to be taking a very non charitable read. I aluded to the browser, specifically because of the hard split between content markup and stylistic markup that is of very arguable benefits.
It is alluring. And when it works, it feels magical. Yet I still prefer TeX over many of the document systems I have been subjected to use. Markdown being a strong modern contender that embraced the ascii art nature of plain text files. Throw in the modern resurgence of jsx and the hard won separation of scripting from content is not even fought anymore.
To the ui/ux point, directly, I'm not even sure what you are arguing. The APIs that you list are all notorious for being bad leaking abstractions. And is why people make products over them, introducing new forms and functions for a different set of users. Just look at how you shoe horn shaders into those low level APIs.
But again, in the context of this story, I meant that you can't separate out the ui/ux concerns of a product completely from who owns that product. So, for AWS, they own both service and console. If one is bad, it is almost certainly from lack of prioritization in the team that owns the whole product. Often behind the guise of "this is not the architecture's concerns, but the front end."
Jumping to another metaphor to try and say it differently. In a bike, you can separate the drive train from the steering, but it will be a largely perspective based separation. Such that the entire bike is ultimately part of the steering and the power distribution. Yes, this is a simplistic look at it, but no more so than thinking you can fully isolate one from the other.
(Now, I do have to confess that Tufte is finally really resonating with me. And I fully agree that much of this is as useful as so many platitudes. Ask me about front end versus back end, someday. :) )
> To the ui/ux point, directly, I'm not even sure what you are arguing.
Yeah I can see that given how off the point you are in your posts. Your initial response is that the separation of form and function is a mistake.
I’m saying it’s not a mistake, separating form and function via abstraction is intrinsic to the industry and I use UI/UX as an example. Your retort is that UI/UX abstractions are notoriously leaky.
How does a leaky abstraction move the conversation in any direction? Most abstractions are leaky, everyone know this, but despite this we still need to program our computers via a high level language designed to separate form from function. Otherwise everyone would use assembly language. The leaky ness is known but to manage complexity we have to separate form and function.
So your statement is completely and utterly wrong. Your responses fail to prove your point and go off topic into unrelated metaphors, tufte and Tex. Stay on topic.
UI can only show stuff in different place, with different colors and fonts, but it won't solve the problem. Explaining architectural purpose of a tool is an architectural job, neither UI designer nor salesman can do it, especially salesman.
There’s a concept in CS called an abstraction layer and the UI can literally change the thing underneath. I can create a UI with one button that when you press the button it triggers 50 actions to happen. It is not just about moving fonts and colors. This the exact same thing that a programming language does. A programming language abstracts away assembly language by having one programming expression execute several assembly commands. This is the job of abstraction layers and also the job of UI/UX.
Second explaining architecture is not solely an architectural job. It’s mainly the job of the person who writes documentation. The “architects” job is pretending he knows some “theory” of architecture more then the engineers actually coding the “architecture” when no such “theory” even exists.
Then architect should tell the purpose of the tool to the documentation writer, otherwise the documentation will read "press Ok button to install %toolname%" that tells nothing how to decide what the tool is and does and whether the user needs this tool. That's the problem at hand.
This isn't specifically the job of the architect. Any idiot can explain how the tool they built works. So the software engineer or the product manager can do this as well. Explaining how something works is not a magical skill reserved for software architects.
What is a skill reserved for architects? If you find yourself spending 100% of your time creating a powerpoint to explain things in a way that makes you sound smart and takes all the credit away from engineers then what you did there is a skill exclusive to architects.
The architect is the only idiot, who knows the tool as a whole and, more importantly, its role in the bigger world. Other idiots know only how bits are fiddled in a small corner of the tool on which they worked during their probation, they don't know the big picture, at all. In any case documentation in big companies today is outsourced to people with zero programming experience, and they obviously can generate only absolutely vapid text with traces of fuzzy associative connections with the topic.
So literally you’re saying the architect is the only person who can write good documentation.
Also the architect is the only person who did not write a line of code yet understands the tool better than engineers who work, code and solve problems across the entire stack.
He doesn't know how local variables are named, but what's needed for documentation is purpose and nature of the tool, and that's what engineers often don't know, because it doesn't help with bit fiddling. And a coding architect is an architect too.
Agreed. Only Software Architects have the special ability of naming things. Engineers and managers don't have this special knowledge.
When I went to Standford to get my PhD is Software Architecture I was required to take at least 2 semesters of classes on the theory of naming things in software. The biggest point the class made was proving mathematically how one should never name anything after a plant, Greek/Roman god, gemstone, animal or molecular structure.
I hate with a passion services that have cute clever names. It makes it impossible guess what they do. It makes it easy to overload the service with things that don’t belong.... if the service was named “OrderService”, if somebody wanted to add a “spell check” endpoint people would start asking questions if that service was the right place. But since the service was named “CaptainCrunch”, who knows if spell check belongs...
Same goes for team names too... clever team names are obfuscation.
Agreed, the post you replied to had a sort of different point though. I took two semesters of naming things as part of my PhD in software architecture. Do you know anyone with such a PhD? Do you know of any course in any university that teaches people how to name stuff? Did you need to take such courses to arrive at your philosophy on naming things?
The post was sarcasm that flew over your head. You can’t even get a PhD in software architecture because the entire field is a sham title created by industry. There is no theory or science behind “software architecture”
Either way you are wrong about math. All decisions can be mathematically modeled. It’s called a conditional expression, and you use it to model/calculate decisions when you program.
Different conditional expressions make different choice in the same situation, then you need to choose what conditional expression should be in the program.
Naw. The term "mere" was to de-emphasize the importance of the term "architect" which doesn't apply to other AWS services.
The parent poster declared that AWS needed some "architects" which I think is kind of arrogant given the fact that most "architects" don't even have the ability to engineer the tools built by AWS. They are just "mere" users of the tools.
