Not really, not at all. Software architecture is a lot about wisdom - how to anticipate future changes. Often user interfaces need to be carefully and gently designed so that the user has no surprises. Diligence from the user should not be assumed, the user interface must emphasize tricky parts and make choices less onerous, etc. Scalability is preferrably achieved by simple code + hardware/vms rather than overoptimized code which depends on "irreplaceable" programmers - what if they fall sick, or leave the company? etc. I think all of this is experience accrued over many years, and with facing many failures.

I have found that the data structures that you need are often simple trees and hashes. Database design is probably more important. I often shake my head at students doing hours of dynamic programming to crack interviews. In the past year, how many problems in your company have you solved through dynamic programming? I suspect, not many.

In the real world software architecture is rarely about “data structures”. Software architecture is about teasing out the needs of the customer - whether that be internal or external - and knowing how to design systems that are maintainable, scalable, fault tolerant, etc.

Scalable, fault tolerant systems is a distributed systems problem, which is a harder form of data structures problem.

Yes but unless you are actually working on creating the system that other people implement, you are just using work made by others. You don’t need to know the ins and outs of various gossip protocols.

Potentially two things here:

1) Gathering requirements.

2) Turning those requirements into data structures.

I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way.

When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different).

Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up.

I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.

But still “data structures” in the context of most businesses are more Domain Driven Design “Domain Contexts”, “Aggregate Roots”, type structures than any type of complicated CS type data structures.

Parent was discussing not being interested in algo design, rather than not knowing data structures.

That depends on what is meant by software architecture. If you mean the structuring of a system to achieve good or (particularly) consistent worst-case performance, maybe you are right. But if architecture is used to mean the design of a system to satisfy users (and present a clean, extensible, meaningful interface) then it's really a conceptual job that has more to do with design skills than optimized algorithms.

Being able to make a clean interface, as in a clean API, or useful one, is a data structures/algorithms problem and often a distributed systems problem. Many API's are technically impossible to use correctly. For example they might not let you do two things atomically that need to be. Or they might suffer enormously because they don't version their information properly, resulting in client/server disagreements over the nature of reality that are impossible to avoid. Or you get components that are impossible to interrupt cleanly or shut down safely.

It's not the same thing as some piddly twenty minute problem -- it's harder, requires some experience, and it has the same kind of aptitude. Consider it a rule that people that can't handle data structures problems are going to create systems architecture problems.

In my experience, architecture requires broad but not deep knowledge of data structures and algorithms. The best architects have both, but even very good architects struggle to remember algorithmic tricks on the spot and write detailed code without tools or references. People who can do that easily are often the last to think of things like fault tolerance.

You don't have to be some string algorithms weenie, but the kind of people who "absolutely hated" algorithms problems in my experience, some of it personal and some of it vicarious, are bad at making architectural decisions with far-reaching consequences. It's overlapping subject matter which uses the same kind of aptitude. It's not that to be good at architectural decision-making you need to be prepped for an emergency Google Code Jam.

A more charitable interpretation is that they absolutely hated "constant internship interviews".

In my experience, algorithm interviews aren't even very good at measuring aptitude for algorithms. Recent study and aptitude for the format have too much influence. Asking candidates about architecture has been much better at predicting their aptitude for architecture.

I don't necessarily disagree with that -- what kicked off my reply was the statement, "Honestly, it sounds like you may be geared more towards software architecture rather than software development." (And, you know, rereading that sentence removes any doubt I had about the correctness of my initial response.)

If you can rigorously ask architecture questions, and don't let people get away with hand-waving, that sounds fine. I've been asked good architecture questions and I've been badly asked bad architecture questions too, so... it depends on the question, and how you ask.

Designing something on an architectural level really isn't always a data structures and algorithms problem. Take the web, for example. REST isn't complicated, but it does the job and it opened up more possibilities than any other invention since timesharing.

As other commenters have noted, choosing an architecture for a system may have more to do with vision, common sense, and even imagination. And the web is such a great example of this, maybe the classic example. As you probably know, it's possible to write a webserver without having a clue about fancy data structures or algorithms. It's the imaginative composition of pre-existing features that creates the architecture.

Another example would be the extensibility of Emacs through elisp. Consider the notion of hooks which essentially allow utility functions to be customized by the user. It's a purely architectural concept.

Or the Unix philosophy: small utilities that read and write text, linked by pipes. Really no algorithmic complexity to it at all.

It feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems.

Vision and a perspective that differs from the norm are a lot rarer and potentially more valuable than the ability to apply software engineering principles. Architecture, in the broadest sense, is precisely the area where these "outside the box" contributions are likely to be valuable. Consider the invention of the Wiki. It came out of the pattern language world, it was a hugely beneficial innovation, and it has almost zero data structures/algorithms complexity behind it.

I'd even argue that the examples of pitfalls that you list are more clerical matters of systems programming than cases where architectural design principles are lacking.

(And even the professionals who can reliably grind out working code for large systems can get the architecture spectacularly wrong, as the case of the X window system: http://web.archive.org/web/20170920104011/https://minnie.tuh... )

>t feels problematic to me that you are saying to someone that they "need to stay far, far away" from some aspect of computing. It's a kind of gatekeeping. Sure, an outfit like NASA needs to make sure that they don't have amateurs writing their systems software. But in the industry more broadly, people have to be given permission to pursue whatever interests them. It's important, for diversity and the invention of new applications, that "differently able" coders aren't told, by intimidating stereotypical computer science types, that they don't have the aptitude to architect a useful system, or that it's "a rule" that people with their skills will just create problems.

I really needed to hear this thanks.

Calling an idea problematic is a tell that he's not really concerned by matters like whether it's correct or not.

Web servers and clients, for example, are a case where I've seen bad architecting cause months of damage. An Emacs function hook or advice system, likewise, requires care in terms of when the hook is called, and what the rules for their scoping are. It's a bad software architect that thinks they can just slap callbacks on something.