8 ms·
These seem like totally different roles. And the hours I've spent staring at the AWS console trying to figure whether I need "Elastic Beanball3" says to me that
by sjburt 6y ago
These seem like totally different roles. And the hours I've spent staring at the AWS console trying to figure whether I need "Elastic Beanball3" says to me that Amazon could use maybe just a little architecture. But I'm sure the Beanball Principal Engineer is quite proud of their resounding impact.
- Geminidog 6y agoThe 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.
- otabdeveloper4 6y agoAWS 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.
- Geminidog 6y agoThe 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.
- otabdeveloper4 6y agoTechnical debt isn't the root or even the most common cause of software components not playing nice with each other. In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones. (And really much of what we call "technical debt" is just the scaffolding we put together over the years to make stuff be compatible.)
- Geminidog 6y agoI 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.
- webmaven 6y ago> 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): https://en.m.wikipedia.org/wiki/Second-system_effect https://en.m.wikipedia.org/wiki/Second-system_effect
- taeric 6y agoHard disagree. Thinking you can separate form from function is the evergreen mistake of our industry.
- Geminidog 6y agoBut 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.
- taeric 6y agoAh, 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.
- Geminidog 6y agoMy 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.
- 6y ago
- BillinghamJ 6y agoTo be fair, most of AWS's services are also mere users of other AWS services
- Geminidog 6y agoNaw. 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.
- perlgeek 6y agoI would argue that naming very high-level things (like your top-level services) is very much an architectural decision.
- Geminidog 6y agoAgreed. 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.
- spookthesunset 6y agoI 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.
- Geminidog 6y agoAgreed, 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?
- GoblinSlayer 6y agoMathematics does calculations, not decisions.
- deleted 6y ago
- GoblinSlayer 6y agoUI 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.
- Geminidog 6y agoThere’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.
- GoblinSlayer 6y agoThen 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.
- Geminidog 6y agoThis 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.
- commandlinefan 6y ago> trying to figure whether I need "Elastic Beanball3" Just wait until you have to try to figure out how much that's going to cost you...
- sokoloff 6y agoAs far as I can tell, the state of the art is to run it for a month and see what the bill is.