Hacker News Reader

7 years and 4 different companies is why your perspective is skewed. You’ve never seen a system mature at that job change rate. Therefore you have never really had to deal with decisions that impact long term which is where architecture matters.

Everyone is their own worst critic. I frequently am editing production code I wrote 15+ years ago. I also have to deal with the unintended consequences or side effects from my code that were not thought out at the time. It certainly is hard to teach this kind of thing and, more importantly, find a way to get people who haven’t experienced it to find the value in doing so.

Pretty accurate. And if you ever get asked "why do we have to do that useless thing you said?" and you reply using expressions like "futureproofing" or "anticipation", eyes might get rolled at you and you might even get management to disagree for the sake of tight deadlines or yagni.

Firstly, he said he has never worked with an effective architect: you have changed his meaning completely to imply he doesn't think architecture matters.

Secondly, you can't know he hasn't worked on mature systems (he didn't say). Most people learn by working with a variety of systems that are at different stages (greenfield to twilight), and more importantly with different quality (poor versus good architecture/systems/teams).

A long period working on one good system may help a few people learn, but from what I have seen, it often doesn't (I have worked with crap programmers on mature systems).

Hopefully GP answers for themselves.

> How can "Principal Systems Engineer" meaningfully talk about such complex matters of system design and architecture, when they fail at much easier task of handling web page availability with a slightly non-trivial load?

1. Are you sure that the person writing the blog post is the person in charge of webhosting?

2. I have pet projects running on some small virtual private servers. I have no idea if they could handle the load from HN. Does it make me a worse software engineer that I can't justify paying more for a beefier dedicated server right now?

PS: does someone have an estimate of how much traffic (hits per minute/hour) the HN front page can bring?

Idk if traffic per minute is relevant. Depends a lot on what sits behind hn to figure out how many servers are needed.

This guy knows https://thehftguy.com/2017/09/26/hitting-hacker-news-front-p...

(he got 20K/day, which for all intent equals zero in my experience)

> As yet another data point, the website cannot handle Saturday HN front page traffic. How can "Principal Systems Engineer" meaningfully talk about such complex matters of system design and architecture, when they fail at much easier task of handling web page availability with a slightly non-trivial load?

You do understand that this is cmu.edu, and the blog post is probably written by a CS prof who has nothing to do with CMU's basic IT operations.

You do understand that this is "The SEI: The Leader in Software Engineering and Cybersecurity", and the blog post is written by the SEI tech staff?

If our "Software engineering leaders" cannot handle simple tasks, what does it say about our profession?

Do you really think the engineering leaders are the ones who maintain the web servers?

The point is: "If the leaders cannot lead the people under to do what seems like a trivial thing, then mby they should not be called leaders at all?"

What makes you think the webmasters at a large university are "under" the CS professors? They probably never met each other and work in completely different departments.

> If our "Software engineering leaders" cannot handle simple tasks, what does it say about our profession?

It says that they have more important problems to be working on than managing their university's web-servers, which a CS undergrad could do.

But working on “more important” problems, particularly abstract ones, while the basics fail is precisely the complaint about architects:

They’re so busy with their “more important” issues, that the whole thing fails in practice.

If they truly had organizational wisdom we could utilize, why don’t they deploy it themselves, to keep their website online during small spikes in traffic?

If their work can’t even be applied to their own organization successfully, why should we believe it will be successful elsewhere?

How is that even relevant though? She is commenting on that software should be involved earlier in huge military projects that have previously been dominated by hardware and you are nitpicking that the university web server cannot handle the traffic?

Yes — their engineering development principles can’t be (or haven’t been) used to successfully design and deploy a well understood technology like a website that can handle small spikes in traffic; why should we believe they have useful advice for more difficult projects?

“Physician, heal thyself.”

> Yes — their engineering development principles can’t be (or haven’t been) used to successfully design and deploy a well understood technology like a website that can handle small spikes in traffic; why should we believe they have useful advice for more difficult projects?

This is such a weak argument. Where did you hear that their principles were not being applied in real life? Why do you automatically assume the university's website is built on their principles? This entire discussion is trivial.

What it says about the managers and architects if they cannot lead the CS devs to do what they were supposed to do ?

I find it hilarious.

Even within the same organization, software architecture can be a radically different practice from person to person. There are some like those you mention: they're aloof, they don't engage deeply with the business requirements and their deliverables range from useless to actively harmful. They set incorrect expectations with the stakeholders — often systematically underestimating the complexity of components they deem less important, like user interfaces, and they provide a rigid framework for the developers that ends up being implemented with more by-exception than by-the-rules.

A _good_ software architect is almost the exact opposite. She's a minesweeper, finding obstacles that would have caused re-work and scope change. She untangles the business requirements so that expectations can be clearly set and communicated. She does research on existing approaches to the problem, becomes acquainted with the relevant open source work and thereby serves as a check against "not invented here" syndrome. If this some of this ends up being best delivered in a document or a diagram, so be it, but the point is to enable the developers, not a masturbatory exercise in self-indulgence.

The positive example sounds like.. a good engineer.

Right. So, architecture is a role a very senior engineer holds with a specialized set of skills.

Who is responsible for understanding the interconnections of a system when there are over 100 engineers? That's the architect.

> As yet another data point, the website cannot handle Saturday HN front page traffic. How can "Principal Systems Engineer" meaningfully talk about such complex matters of system design and architecture, when they fail at much easier task of handling web page availability with a slightly non-trivial load?

C'mon, this is a university's website, and the author of the original piece is just a user of that website's CMS, not its architect.

Many folks would likely say they've had similar experience with software/system architects. IMHO their primary role is to act as tradewinds to gently nudge the organization into a cohesive direction within their domain of expertise. So while an engineering team may not (and probably should not) accept the details of a recommendation by an architect, the likelihood is that 50 teams operating n collaboration with small team of architects are likely to encounter less friction with interoperability and tooling than 50 teams operating independently.

My challenge with software architects is that the one's I've worked with aren't strong communicators. I've yet to find an architect has both the time and inclination to break things down for the devs in manner that makes sense. That might reflect my lack of experience on building systems large enough at a company that a architecture communicator would find attractive, and no judgements are intended. I'm just saying I have yet to work an architect that could "break it down for me".

> All meaningful decisions and choices are made by the developers themselves

Depends on a type of project and many other factors. If you're say building a business app for a client delegating architecture decisions to individual devs on "as-needed" bases means either that all members of team need to be equally capable, have an excellent understanding of client's business and very clear and uniform vision of bigger picture where project is going - or more commonly that you'll end up with a terrible, suboptimal mess of different approaches and interpretations of requirements. Also you usually don't want to pay 10 expensive devs to study the client's business and specifications for days or weeks, when you can have just one do it and propose the solutions to others. So you need a person in charge, and you need that person to know how to do it good, because not everyone, even senior devs, is equally capable of tracking all the moving parts and envisioning the optimal solution. It's a job for someone who's good at it, and you can call them architect or tech lead or whatever, title doesn't matter, but letting them be focused on global picture instead of doing little isolated tasks with everyone else will save you a lot of headache.

However, I totally agree with you that often people hired to do that are not really good at it, just like a lot of managers are not very good in managing projects (and many devs are not very good in programming I guess). The problem there is not with the role itself, but HR and the organization.

> All meaningful decisions and choices are made by the developers themselves, with little to no account for architect's mumblings.

You're describing a problem caused by developers, who for some reason ignore the architecture that they are supposed to adhere to.

Unfortunately, the only type of architects I've worked with have been "architecture astronauts", and they've only created excessive complexity in their designs.