People who are really serious about software should make their own hardware.
That is no different from people who call themselves “software architects”. You can’t build great software architectures if you don’t know how to build and optimize the underlying architecture it runs on and how to build the pipelines that put the code on those systems.
Alan Kay said that “Everyone who is serious about software should make their own hardware.” How can you be a good developer if you don’t understand the architectural limitations and choices?
When I design a backend system, I need to think about how the front end developers are going to interact with it. My data storage characteristics and scaling. I need to know am I designing anything that’s hard to deploy. How will logging work and be aggregated. I have to be able to think about the entire system.
It’s not just “cost cutting” at a certain point in your career you are expected to know more than just “how to code”. I’m not saying learn AWS. But I would expect any senior developer to know about what their code runs on top of .
> Engineers make dozens of architectural decisions every day.
> Two really key fundamental knowledge areas if you're goal is to build actually reliable and relatively efficient software.
I would challenge you on this, and suspect that you're looking at a relatively thin slice of developers: can you clarify why you believe this to be the case. As a counter-example, a lot of modern web development is building frontends (mobile or JS), where good code organization matters, but systems architecture doesn't matter so much.
The principles of architecting code and system design are timeless.
That I emphatically agree with. Some of my favorite programming books are decades old.
There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system.
There are?
I can't say that I've ever met one.
The problem is that people don't know what they don't know. A non-programmer can know exactly the business problem to solve and exactly how they want to solve it. But they can't tell the difference between what is easy for a programmer and what is hard.
They don't have to learn a ton of programming to fill that bit in. But if they never fill it in, that limitation will keep them from being able to be a good software architect.
>His key insight is that buildings should be designed around what makes humans feel more alive in them. Applying that to software, you'd end up thinking more about projects and teams than about iterators or singletons.
No - I think you would end up thinking more about the end users of your applications.
> But you rarely start by choosing a specific architecture. Unless you already know a lot about your solution.
That's how it probably should be, but in my experience it rarely is.
Generally, businesses decide that they need to re-/implement x, then the enterprise architect shows up and decides on the pattern and then the developers are required to somehow make it work, even if it objectively doesn't.
Now I am conflicted. I agree with this article just as much as I agree with this one that says "Architecture has no place in software", also posted today: http://hhgttg.de/blog/?p=352
I'm giving interviews with system design, I'd say that the majority of programmers who are decent cannot actually architecture anything well enough. And it doesn't matter if they're given more time, they don't have the training/experience for it. (They'll only learn the impact of their decisions later, eventually painfully).
On the other hand, they may be able to develop it if handed and led through a proper architecture.
I think the article is saying: people who are making architectural decisions (whatever their job title) should spend some time coding the system they make decisions for.
I think this quote from Alan Kay is rather illuminating:
"The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."
> The disadvantage is obviously that creating such's a 'perfect architecture' is hard to do because of different concerns by different parties within the company/organisation.
I think you get at two very good points. One is that realistically you will never have enough time to actually get it really right. The other is that once you take real-world tradeoffs into account, you'll have to make compromises that make things messier.
But I'd respond that most organizations I see leave a lot of room for improvement on the table before time/tradeoff limitations really become the limiting factor. I've seen architects unable to resolve arguments, engineers getting distracted by sexy technologies/methodologies (microservices), bad requirements gathering, business team originated feature thrashing, technical decisions with obvious anticipated problems...
My feeling is that people who understand maintainability or other architectural concerns are worth more than people who master algorithmic underpinnings.
I thought the point of this discussion was how to change the industry emphasis rather than how to get good at it.
I'm struck by the parallel between architecture in your example and software engineering. You could say the same about the engineers who don't ever consider the humans who will be using their software.
People who are really serious about software should make their own hardware.
That is no different from people who call themselves “software architects”. You can’t build great software architectures if you don’t know how to build and optimize the underlying architecture it runs on and how to build the pipelines that put the code on those systems.
reply