A software architect that can't code or refuses to has no business architecting the system.
A software architect who doesn't show up to stand ups really shouldn't be dictating a solution to the team who have to build it.
Ideally the software architect should be as hands on as possible with the team leads as the system is built up to the point that the architecture is proven or at least to see if the assumptions around the architecture actually hold up.
Really strictly on teams leads to accurately communicate the architecture before it has been proven to hold up is risky.
I get this issue and I share the frustration but is this really a comment on the article posted?
In this case we seem to be talking about huge military projects like GPS or Drones and that there is a divide between the hardware parts and the software parts that might have made sense in the past when the interfaces between the hardware were simpler and software was mostly internal. But now when software is such a big part you need to involve software people earlier looking at the bigger picture from the beginning. It will also drive how hardware will be developed, i.e. what you can do with software will drive how you should develop your autonomous military drone fleet.
Yea I don't get a huge number of the comments in this thread. The article was pretty specific in what it was talking about, which seems to be not what people are talking about here.
The examples given are all defense projects, but the article does not ever limit its claims to defense projects. Its thesis is stated and re-stated in general terms and it consistently makes broad claims like:
> Today and into the future the best way to ensure that a new system's software architecture supports needed capabilities and also system evolvability is to involve software-knowledgeable personnel--specifically software architects--in the early system decisions about breaking up a system into acquirable parts. At this early stage, many software problems are either caused or avoided, and software architects are needed to ensure the latter.
A similar problem I've seen a few times are the consultants that participate only in the first few months of a multi-year software project as architects, so never get to experience the long-term implications of their design and the mess they prescribe. Not only is this bad for the project, but also breaks the feedback loop for their own learning.
This is something I'm afraid of at my current company.
We just used 3-5 contractors to implement Zuora, Salesforce, and Netsuite in "record time". They're gone now, along with the biz ops person leading the rollout.
As an engineer, I feel like I'm eventually going to have to deal with that flaming pile of shit.
In the world of web development, and devops etc. this is probably very true.
However there are a lots of non-web orientated systems out there; banks, emergency services as an example. I fall into the latter, and have also worked in the former. In those kind of environments we often have an architect (who is indeed quite a talented and hands on coder), but the hairy implementation details of the architect's design tend to be worked out either by dedicated designers, or some other form of implementer (systems administrators/programmers).
It's unfortunate that this off-topic, general comment has derailed what could have been an interesting discussion about specific types of architecture (large HW/SW systems). And I have a feeling that like several other commenters you have some specific architecture work in mind and are incorrectly generalizing based on it.
Taking part in stand-ups for instance would be a complete waste of time for anything except application architecture and it's only relevant in projects which are using Scrum. Even then, it's possible to do the job by being available (at the risk of missing some unofficial or ephemeral info) and taking part in the sprint review.
I prefer involving the team in design decisions and giving them freedom to implement things as they see fit, as long as the architectural requirements are being met.
The usefulness of coding skills decreases the higher one climbs the abstraction ladder. Writing production code for a project is from my POV an anti-pattern unless we're talking application architecture and the architect is only part of that one project, which sounds like title inflation for anything except bigger applications.
In my experience there were two kinds of situations where it was worth it to write code: tackling less glamorous, but useful tasks that the team didn't have time for and solving trickier problems that the team couldn't yet work out.
Otherwise I expect and prefer mature dev teams which can implement on their own, while I am available for guidance if needed and to ensure that the business reqs are correctly translated and their piece of software integrates properly in the platform.
Personally, I found domain knowledge, connections and social skills invaluable for architecture roles. Technical skills are also valuable, but they're table stakes to be honest.
Totally agree. If you don't know to code and but are an architect you pretty much live in permanent la-la land. I bet on paper I could architect a whole company within a few hours. It would look good on paper but in practice it wouldn't work because there are a ton of implementation details that make my design impossible or hard to achieve. Much better to empower the devs to be involved in architecture from the start so they can give real-world input quickly. I have seen it so many times where managers and architects decided on an unsuitable stack because all they do is listen to sales reps and read whitepapers.
Software security architect here. Senior management strongly discourages writing code on my team. But this is because we work at-scale with hundreds of products comprised of thousands of microservices.
I don’t attend product teams’ standups , but our engagements run on the order of weeks to months.
We don’t micromanage development or design choices made by product teams. Yes, we review code and make (strong) suggestions, but we leave service teams free to make choices as long as the risk is low and commensurate with the threat model. It’s our job to guide major decisions and, occasionally, advise on the “least-bad” short-term solution, pointing out where, when, and why a re-architecture will be required in the future. Generally speaking, teams want our feedback on design proposals and concepts. It’s a healthy relationship.
Occasionally we have to force teams to reimplement, or block release, but that’s a very rare occurrence.
Unlike many comments on this thread, service teams leave us with pretty positive feedback. It’s very rare that teams leave negative feedback on our design engagements.
That’s definitely the case when thinking about security in a strictly limited scope. In contrast, my team is holistic — any issue that could affect ICA (integrity, confidentiality, availability) is in our purview.
My team engages in the earliest phases of design. Holistic security is our priority, but not a limiter for our engagements.
Oddly enough, I'm an architect for a company that makes scientific equipment. Mostly hardware rather than software. The software team is its own independent entity.
I'm usually present at every stand-up. Realistically, the engineers tend to be fairly specialized, not multidisciplinary, and are not up to speed on quantitative engineering, so my role in defending and adapting the architecture is continuous throughout the project.
They should also accept most of the blame for any problems, because anything higher level than "my code won't compile because the syntax is wrong" is an architecture problem.
You want to be the architect and me just a lowly coder? Ok, I'll fix my own compile errors, all other problems are on you.
Architects shouldn't be dictating your class structure or code choices. That's a code concern and not of the system. If the system has fundamental issues around performance, scalability, extension, or security, then it's probably on the architect.
This attitude seems to be the default "holier than though" attitude about architects. I think it's more likely that you would encounter pragmatism when the company culture is healthy. Unhealthy company or engineering team and there's no way to tell whether it would be good or bad
Only issue is, a bad dev can still make mistakes that compile and run but fail at the first hint of trouble.
A friend used to say, "every line of code you write, you make at least one, if not more decisions about the architecture of the program" and I totally agree. So I can still see a really good architect being betrayed by a below mediocre engineering team even if the architecture is sound.
> A software architect that can't code or refuses to has no business architecting the system
Well, in construction, you have both architects and civil engineers that never, ever place out rebars or pour the concrete. The architects know how to design the building, while the engineers materialize those designs according to the laws of physics and economy.
So I guess one could ask, why should it be any different in software?
In fact, it's like that in pretty much every other industry. I'm an electrical engineer by trade, and even though I know how to practically do the work myself (since I worked as a electrician apprentice before college), it is something that I never touch - nor have to touch. That's what electricians are for.
> So I guess one could ask, why should it be any different in software?
Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world. The decider/implementer model might be a common organizing principle in other industries; that does not mean that it's useful to software.
Brick layers cannot manipulate more than small chunks of a building at a time. Software engineers in contrast can perform the equivalent of turning the Empire State Building on its head.
Software architecture is difficult to get right and too important to leave to one or two senior folks who may or may not have the insight required to make the right decisions.
I agree, but as an architect who does all that, it is also a constant struggle to deal with developers that don't think more than one step ahead and need to be spoon fed concept to prevent them from e.g. writing custom code instead of preparing for reuse.
When you have developers who understand how to generalise and abstract, then the interactions can often be very simple, and deferring to team leads etc. can work just fine.
The relationship between the architect of a building and its general contractor is no different than it is in software: acrimony, with each thinking the other is wrong on most fronts. General contractors believe their experience gives them superior insight into how something should be built, and that architects make impossible-to-implement plans. Architects take great care to make precise decisions on hundreds of dimensions, ranging from cost engineering to air quality, aesthetics in the context of then, now, and the life of the built environment, and scoff when plans aren't followed. Somehow, usually, through a lot of bickering and change orders, things turn out alright.
The architect absorbs vast information and designs a solution, the builder makes it into reality, often making meaningful and lasting decisions during implementation. Both are competent and valuable. Sure there are design-build people and teams, sometimes they work very well. Architects will always have more context in the realm of ideas, that is the space they occupy. Builders have the most context in implementation, and may detect issues that make the whole plan invalid. Collaboration helps. Mistrust doesn't.
Architects don't have to swing a hammer to know where the planks should go, but boy it sure does help if they have.
It helps to do building. I recently took over the ownership of a small component in our system myself. That was the first time I wrote a unit test in our project. Finally I know how our testing and coverage infrastructure is configured.
> The greatest architectures are the product of a single mind or, at least, of a very small, carefully structured team.
In a big project, I would rather relief the one or two architects from their coding duties than to have four or more architects.
While it helps to do the building, there are more important things for an architect to do. For example, I'm the one who has the overview of cross cutting concerns like logging and safety.
Disclaimer: I believe there is a big difference what "software architect" means in IT/cloud/web in contrast to embedded/safety-critical/real-time. Most of the complains I hear are about the IT ones (often called solution architects). The article and also my work is in the later category. The methods are nearly the same, but regulations in the later category force the architects to focus on much more details. Maybe that helps to stay more grounded. We do have a similar acrimony with our "system architects" though.
No the analogy is bad. The relationship between software architect and software engineer is akin to the relationship between a building engineer and a architect of a building, not the contractor.
The architect has some grand high level artistic design or dream. Engineers and contractors turn dreams into reality.
Architects have ideas. Engineers and contractors are incapable of high level thinking or having ideas of their own. It's pretty impossible it's like architects are born with it. Sort of like how a CEO is able to have a vision. Engineers don't know how to dream or have visions. It's the job of the architect and CEO to direct us.
Software Architecture is vitally important to the long term success of a software system.
Software Architects are not the only way to get software architecture. They may even be the worst way.
"Software Architects who Code" often do not suffer from this issue, depending on how much they actually get involved in production software and operations. However I would struggle to define a meaninful difference between a "Software Architect who Codes" and a sufficiently "Senior Software Developer".
I'm a Software Architect who made a progressive move to that role after being a Sr. Software Engineer for almost a decade. I see the distinction as pretty simple. We do the same things, but, we specialize in terms of time spent and breadth of awareness and contact in the business.
As far as skills go I expect to maintain my coding skills and as far as what I know more about than other SE's is not about skill as much as it is about practicality of time spent. We need the devs to be writing code/implementing every day and the architects spend more time on the, well, architecture as well as business interfacing and planning side.
So that's basically it, the difference is where we spend our time and focus. It's more about roles and needs of the group than about the skill set. At least, that's what I'd hope. Anyone thinking they are a Senior level engineer who can't understand the concepts of software architecture needs to rethink their position and maybe broaden their skill set a bit, imho.
Good Software Architects can make a huge positive impact over time. But, people often fail to live up to the role.
The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them.
It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.
I think "architect" is code for manager who is slightly technical enough to make high level decisions about a system.
You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective.
So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"
To clarify, someone with a PHD and architect title came up with a system that had 8 layers server side. The actual programmers coded up two of them on top of each other as simple 1:1 mappings using objects with different prefixes, and a third layer on top of that which was usually 1:1, but occasionally not. They did plenty of other odd stuff like stored all values as a string rather than using any database data types on the off chance they would port or a different database.
Anyway, I worked for the same company and very occasionally helped some friends on the team, but was not really directly involved day to day or even most months.
A PHD does not make you an "architect." There's no formal design theory around "layers" "patterns" or "software architecture" so a person with a PHD does not have a definitive answer to good design or bad design. It is unlikely that anything he studied in school is relevant because such a science or theory doesn't even exist. His answer could be just as good or just as terrible as an engineer. Every architecture or pattern you here about is NOT theory OR Science, it is opinion and opinion only.
I don't have context on what those programmers did, nor do I know whether the 8 layer server side design was good. But I do know that how good a design is, is not influenced by a PHD or a software architect title.
That being said, an 8 layer design points to 8 things that want to be re-used. Typically you just need 3 layers (letters represent types, arrows represent a conversion process from one type to another.):
IO input -> A
A -> B
B -> IO output
I have rarely seen a business case that necessitated 8 layers:
IO input -> A
A -> B
B -> C
C -> D
D -> E
E -> F
F -> G
G -> IO output
From my experience those 8 layers are probably garbage and unnecessary. You just need A -> G. You might break A -> G into several components but 8 is overkill.
Likely the architect and the software engineers both don't know what they are doing.
I'll go further to say that no architect will ever reason about "layers" the way I just did because my break down of the design layers above isn't some science. I made it all up, it's basically my opinion and most architects you meet will have either canned opinions from some book or have their own made up reasoning on how it all goes together. An engineer can easily come up with his own opinions and read an "architecture" book as well (which is again basically reading someones opinion). The "architect" title is a BS title that implies an "architect's" "opinions" are better than an engineers. It's not and from what I've seen in the industry an architect rarely has better design chops then an engineer. It's all relatively equal.
That being said there is some formal theory on network topology and graph theory that can say something definitive like this graph has faster output than another graph but rarely is it used or applicable in most web apps.
I was specifically using this guy as an example of someone with a job title that said “Architect” going through the motions that was terrible at his job.
I feel managers, directors, etc. who cannot code should not be managing, either.
You have two classes: management and individual contributors, when there shouldn’t be. Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.
This depends on the size and context of the organization. I'd argue that front-line managers should handle trivial, low-priority, low-glamour development, but not more than a small fraction of their time (say between 10% - 30%). If they're doing development work that is more sophisticated or requires more of their time, they aren't going to be able to do their more important job: managing. Managing, by the way, is more than just having 1:1s every week and filling in the budget spreadsheets--it's negotiating for priority, fighting for direct reports' career needs (e.g. fighting to get the team assigned the projects that ICs will be able to use in their performance reviews) and balancing that against the needs of the business, etc.
Mmm, what I was arguing for is that a manager ought to have sufficient experience that they can substitute for and work as any individual under them.
I understand that many large institutions are constructed in a mechanism you describe. In many cases, these managers are technical enough that they can substitute any individual working under them. There are also many cases where they are not sufficiently technical.
Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting for projects, and assisting ICs career growth, I am not convinced that that manager is necessary as I am not seeing his value. Prioritization ought to be intrinsic for everyone and is more a collaborative choice, no? Why does a single individual (manager) decide priority?
Because direct collaboration scales as O(N^2) in terms of person-to-person interactions which becomes rather big as N grows. Having everyone spend 80 hours a week in meetings and still only understanding 1% of the business seems a silly use of time and rather inefficient in actually getting things done. Thus you get managers who are the ones in meeting with other managers which leads to a smaller N.
Understood. Apologies, I didn’t understand what was being prioritized previously. Previous replier clarified. Agree that otherwise this reduces to a handshake problem.
Prioritization is a collaboration in many parts: between members of a team including the manager, and between managers, their managers, etc.
Often ICs don't have the context necessary to contribute much to the conversation once it leaves the sphere of influence of the team they're on--and more importantly most of them don't want to acquire that context, often because they view it as inferior work that is beneath them. They don't see value in management because they can't see past their own egos and myopia.
Got it— prioritization of say features vs prioritization of tasks in the backlog, as an example. Management is necessary— I don’t think management’s function to a company can be discounted. I am advocating for certain traits I think a manager ought to possess, one of which being they have full ownership of everything happening under their umbrella. :-) Not saying they have to code, but saying if necessary they can be a substitute for anyone under them (given some minor startup cost).
The problem is that the world is not filled with superman. People who can code, lead, manage down, manage up, do product and so on are very rare. Ones who can do all those well are even rarer. By focusing on coding you get people, who to be blunt, can't manage or lead well. Which leads to more conflicts and issues than it fixes in my experience. Even if you find such people you get into the problem of them stepping on toes because they or others don't realize which hat they're wearing at a moment (ie: are they talking as an IC or as a manager).
Plus, at the end of the data, a good manager should aim to hire people smarter and better than them. If they can step in for those people quickly then they're not hiring better or smarter people which is a problem. A first line manager should understand what people do but that is different from being able to do their job to the same level.
"I feel managers, directors, etc. who cannot code should not be managing, either."
It works if they know they are out of touch and trust their people. On the other hand if they try to give input but haven't coded in 10 years it's bad,. Last year I had a fight with a manager who insisted that we use JSON for everything. I pointed out that this is a minor decision and really not very relevant. Another guy agreed and was almost kicked out of the project.
I'm in this situation now and it's not bad. It's really important for everyone to have a nothing-personal policy about being like "Hey, this is my area and not yours, let me take over." (And it goes both ways).
It does lead to a lot of "Black Triangle" [0] situations though. Where you spend a long time with no "real" actionable results to show management, and then after an annoyingly long amount of time present what looks like an insignificant joke to a non-programmer.
> I feel managers, directors, etc. who cannot code should not be managing, either.
Somewhere, in a different forum there is a bunch of managers discussing an article where a project has completely failed because some completely naive engineers made a bunch of rookie management mistakes, pissed off half their employees and crashed the whole project.
And they are busy saying "Engineers who don't know anything about management shouldn't be managing stuff..."
:-) I am not convinced engineers cannot be trained to also be great managers. A lot of managers were devs in the past choosing to take management roles to increase salary and forsake programming to satisfy rules implemented in their environment. Forsaking dev work is a mistake.
Management is not something complex. Almost all of management is expectations management.
Some directors may have dozens, if not hundreds or even thousands, of people under them directly or indirectly. This rapidly grows beyond the scale where the director can jump in for anyone in the tree beneath them.
Your comment probably applies for a team lead with a half dozen IC reports. Add in one other layer (i.e., a half dozen team lead reports) and it might still apply in some cases. But double that number or add in another layer and things are probably far beyond the scale you were imagining. The manager’s job now requires a vastly different toolset that most developers know nothing about, have no experience with, and generally wouldn’t even know how to think about.
> Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.
I disagree with that.
If your manager has the best technical skills of anyone on the team, then they are probably a poor manager who can't hire/retain good technical people (by far the most important job of a manager).
What is the reason though? Was there some survey done that analyzes why this strategy is used (in large tech firms)? I am going to start looking into past research to see if any have delved into this question.
Could not agree more about coding. These days I am doing more architecting and code reviews with coding as time permits and the less coding I do the less I’m able to stay ahead of pathologies developing in the codebase as the codebase scales. Right now I’m trying to get the engineers I lead to be more self sufficient on code reviews among themselves and self directed in terms of what to do next so I can spend enough time coding. It’s hard to do if the team is growing and the number of inbounds demanding your attention grows.
API and system design is usually technique agnostic - but I think the biggest reason to have someone designing the system close to those doing the work is both motivation and buy in. As people get more senior they tend to code less frequently, but that’s usually okay - a doc describing all aspects of a system is very much a coding exercise.
In my time at $bigCorp, I saw the title “principal engineer” used to describe two positions simultaneously, and sometimes both in the same org;
- the good, hands-on, full-of-wisdom senior engineers, whose relevant experience and strong vision enable an entire floor of developers to build the right stuff and quickly. These guys made commits to high and low level code, from network debugging to interpreter design. Really inspiring people.
- The toxic “ideas guy” “architects” who believe it is their job to write white-papers on how everything should be, without providing any guidance on how to actually get there. They believe that all problems would be solved if only we had the right perspective, even though perspective can’t be executed on x86 architecture. These guys constantly made me wonder why they were there and what they did all day.
Sometimes the architecture is not designed by a single person. Sometimes it is a group. Sometimes it evolves from every-developer-does-it. Sometimes the role switches quickly from person to person. I don't know scientific studies to compare the approaches. Usually everbody just agrees that ideally one person should do it all.
It is usually easy to identify architectural decisions. You can then find out who made that decision and thus figure out who is the architect.
For example, in a web project: Who decided to build microservices vs a monolith? Who chose the database technology (PostgreSQL vs MySQL vs MongoDB vs ...)? Who chose the cloud platform? Who introduces external SaaS products? Who split up the big thing into pieces for different teams?
Throughout my rather limited career (~7 years, 4 different companies) I am yet to encounter an actually beneficial (to the project) architect. All they do is talk too much and draw some useless diagrams and do a random task that other team members cannot be bothered with. All meaningful decisions and choices are made by the developers themselves, with little to no account for architect's mumblings.
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?
EDIT: A few people mentioned that it would be incorrect to use `HN hug of death` as an example of author incompetence, since it was just some random university or institute. I was about to agree, but then I checked the website, which proudly stated: "The SEI: The Leader in Software Engineering and Cybersecurity". From my perspective, if you claim a thing like this, you definitely should be able to handle a minor spike in traffic.
Now, it also might be that author has nothing to do with the organization and hence not responsible for the website performance. However, this is also not true: "<AUTHOR> is a senior member of the technical staff and Principal Systems Engineer at the SEI...", as stated on their bio page. To me this either shows little ownership or little understanding of underlying resources the author relies on, which serves as another proxy of their actual architecture skills.
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).
I don't actually think that aged very well. Joel's company has been renamed after a product that's two years old, and his mature product has been fading in the market as newer alternatives like Jira and Asana and (ironically) Trello take over its market share.
Building mature software can take a long time, I agree. It depends a lot on the complexity (an operating system is obviously more complex than a solitaire game).
The part I disagree with is the idea that you get to done. Photoshop is a great example. It's over 30 years old. Would Photoshop still hold its market position if it reached maturity 20 years ago and said "we're done?" Ignore UI changes and support for new OSes for a second. Would Photoshop be the market leader without Camera RAW support? High Dynamic Range? GPU acceleration?
You don't have to agree with every change they've made, but there's a lot of serious features that got released after Year 10 that are need-to-have features. I don't think Photoshop 5.5 was the last Photoshop professionals needed.
Meanwhile, Affinity Photo is only four years old, and while if you had to choose between them Photoshop still has a lot of things Affinity doesn't, I'd pick it over Photoshop 5.5 in a heartbeat.
> But that’s just the first ten years. After that, nobody can think of a single feature that they really need. Is there anything you need that Excel 2000 or Windows 2000 doesn’t already do? With all due respect to my friends on the Office team, I can’t help but feel that there hasn’t been a useful new feature in Office since about 1995. Many of the so-called “features” added since then, like the reviled ex-paperclip and auto-document-mangling, are just annoyances and O’Reilly is doing a nice business selling books telling you how to turn them off.
> So, it takes a long time to write a good program, but when it’s done, it’s done. Oh sure, you can crank out a new version every year or two, trying to get the upgrade revenues, but eventually people will ask: “why fix what ain’t broken?”
Seriously, who works on a piece of software for 10+ years? Usually within 2-3 years one has to throw away most of the code as it was written in an obscure, low adoption language, or it is just so difficult to maintain that new features can't be added. Except for SOA or mSOA where parts can be replaced at any time.
> Usually within 2-3 years one has to throw away most of the code as it was written in an obscure, low adoption language, or it is just so difficult to maintain that new features can't be added.
Just because you've been working on shit show projects that doesn't mean all projects are mismanaged like that.
Please put in a bit of effort. Off the top of my head, Postgres, Office, Qt. In yesterday's Blender thread they discussed it and Maya, Autocad, 3DS Max. Web? Jquery, Drupal, Wordpress.
Billions of in-house apps, for companies > ten years old.
> Usually within 2-3 years one has to throw away most of the code as it was written in an obscure, low adoption language, or it is just so difficult to maintain that new features can't be added.
So you've never worked in good code, that's all. Most of the world runs on software evolved over greater than 10 years. Everything you said is wrong, because you've been surfing trendy crap that businesses mostly ignore. Good architects don't use immature languages that might not be around in 10 years, they're smarter than that.
I've come in to an "agile" (whatever that means in practice) project one year into it's life as a project manager (on the customer side), forcing it in to production after prioritizing all critical things (taking an additional year). It was an e-commerce website built on a standard platform.
Btw. The supplier was one of the leading and most hip e-commerce (consulting) companies in my country.
I've seen and been in involved with others too by all kinds of companies. They are everywhere.
Business requirements evolve. Even if you ship a working and currently-satisfactory product quickly, you don't know whether an architecture is good or not until you see how it copes with new requirements 3, 5, 10 years from inception.
People changing jobs/teams faster than that may simply never experience a feedback cycle on the real, long-term quality of their work.
Nearly all the software you actually use. Do you think things like Vault, Consul, Kubernetes, Apache, Nginx, NodeJS, NPM, React, VueJS, etc. etc. etc. were all "mature" one year in? Many of those are actually extremely simple and limited in functionality compared to actual "real" enterprise apps. What an amazingly naïve comment.
I’m not sure what methodology has to do with my point. Launching a system isn’t a big deal, evolving a system is harder to do, finally evolving an enterprise (system of systems) is measured in years. You don’t make architectural decisions over night and aligning multiple independent systems and services is a lot harder than your ignorant comment is aware of.
Yes, but the idea is that software changes as customer needs change. If not, then that is an out of date product, and by the time it would have become "mature" it would be out of fashion anyway. Good software is software that changes often, yet it maintains quality. Unlike in waterfall where it probably takes 2 years to release it, and by then it is already old. For "enterprise" software such as oracle or ibm products, that would not be a surprise, but for highly adaptable products, 2 months is the maximum something would not change.
In this case the article is talking about pretty expansive hardware projects, think GPS or a drone fleet and that software needs to be involved earlier with requirements and design instead of an afterthought.
That is quite different than the CRUD web application that most people are working with.
Even in "non expensive" (relative) HW projects. I've been doing mobile/embedded for a long time. Many experts, SW architects, HW architects are frequently consulted early & frequently throughout the process as no one can possibly have a complete picture. It's just impossible to do it any other way and ship things on time & meeting the quality bar.
Good point. I am coming from the web app point of view. I assumed the comment section was a bit more generic. Also i should have clarified what context i am referring to.
> 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?
> 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.
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?
> 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 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.
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.
> 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.
Unfortunately, the only type of architects I've worked with have been "architecture astronauts", and they've only created excessive complexity in their designs.
I’m surprised HN is so hostile toward IT architecture. I work in the public sector in Denmark, and enterprise architecture is vital for us. We’re 98 municipalities that each operate around 300 different IT systems. These need to interact with each other, as well as major IT systems on the regional and state level (citizen base data, healthcare, taxes and so on). They’re build/maintained by 50 major vendors and a few thousand small ones. Sometimes a system changes hands through public procurement. The longest running systems are from the 70ies, and have several layers of modern APIs build on top of each other.
Imagine doing all that by letting thousands of random developers run completely free. I mean, I don’t have to imagine because we didn’t actually involve architects early enough, and it’s cost us billions to correct that mistake.
I think a lot of posts here completely missed the point of the article, which is NOT about the role of architects in pure software products such as websites.
The author is talking about large defense systems like satellite arrays and airplanes. The status quo that the author is responding to is that engineers of the physical systems (missiles, satellites, etc.) make all the decisions with software bolted on after the fact. This is definitely true at places like Boeing.
You could replace architect with "senior software engineer" or whatever.
Point is, software should have some seat at the table during the design process.
The fundamental thesis of the piece is: "If, instead, system acquirers ensure that systems engineers address software concerns at the same time as the physical solution is conceptualized, acquirers can opt for a slightly different physical system, whose software architecture is tuned to optimize the provided capabilities."
Which, to me, sounds entirely reasonable. If some system needs an MLOC or so and the software will be doing a complex thing like piloting the aircraft, you better be thinking about the software from the beginning of the project...
As an aerospace and defence systems engineer & software engineering manager I came here to note exactly the same thing, however it’s not hugely surprising on a SW-centric site like HN.
I think this applies to all disciplines “under” systems engineering too, the thing is with software there are often a lot more chances for things to go sideways compared to EE or mech in development.
The sooner you get the smart people in each discipline (Software or otherwise) to the table the better off everyone will be. This is why in systems engineering processes like ARP4754 you’ll see the word “preliminary” a lot. Preliminary architecture can be developed along with the system requirements as a basis for discussion with those performing the safety analysis and those implementing the software and hardware items. Having a software architect at the table, someone who can reason about the software architecture and its impact on the systems as a whole and the safety case can only help.
Yeah, between this and the MITRE post the other day I wondered if it was suddely Systems Engineering Week at HN. This is not the kind of content you usually find here.
Professional conferences and the like. For better and worse, it more resembles fields like medicine, law, traditional engineering where most shop talk happens in professional settings and at a specific allotted time, as opposed to online throughout the year during after work hours.
I think this depends entirely on the organization and size of the product.
If you have one "squad" that owns the product top-to-bottom ("squad" being defined here as a team with daily discussion and syncing of progress) then I think the architect aspect is decentralized across everyone.
But once there's more than one "squad" that each own a separate chunk of the overall product and the work of these squads overlap even a little bit, then there must be one individual who is enforcing a confluence of design in that overlapped region.
Where I have worked, the architect is the person who helps the key implementors work together smoothly, shares knowledge about the design, gives advice, and brings in other teams he knows can help.
It takes a lot of "tribal knowledge" about the various teams involved in a project to do this kind of thing well. The most successful architects I have worked with are the ones who have a lot of experience at the same company. They don't design the architecture -- they convince all of the participants in a project to collaborate on designing the architecture.
The people I am describing are more technical than project managers and are able to give informed advice on the architecture and the code, and often commit some of the code to the project in addition to the other project management duties.
If it's a single piece of software that runs on one or a few machines, sure.
But the OP talks about complex, distributed systems that run on several different hardware architectures, and probably implemented by several dozens or maybe hundreds of software engineers. I think you really need an architect for some key decisions: where does what kind of data come from, where is the source of truth for which data, what protocols are used for communication between them etc.
Maybe that's more of a system architect than a software architect, but the lines are kinda blurry.
In a "large complex system" the subsystems might be so large and so many, that it's no longer feasible for the key implementors of each subsystem to get together and discuss technical details or participate in stakeholder and management meetings.
They might also have difficulty ensuring that architectural constraints which are not directly visible to them are respected.
> “Software is never 'finished' but must be constantly updated to maintain capability, address ongoing security issues and potentially add or increase performance.”
Something that people really need to understand when they are asking if something is done. “Done enough for now” is the best, simple phrase I’ve learned to convey the sense of what was quoted above. It can easily segway into that conversation, if handled delicately, and teachable moments for management.
At one previous job I was at, people were saying things are done when they weren't. Then the PM started going, is it done-done? Oh sure. I think that mostly meant "is it actually checked in and running?" Then when we had bugs, they would come around and ask, is it done-done-done (said quickly, with a sense of doom)?
I love the "done enough for now.," although I do find some use in breaking down doneness.
My levels of done:
1) I've got a prototype or POC that works. I've cracked the hardest issues and gotten it to work, at least in some way.
2) Code is buttoned up, checked in, and running in the build (probably in a branch), maybe even reviewed.
3) Code is tested, and tests pass
4) Code is integrated and working functionally as part of a system. People are able to call it and rely on it. Proves code does what it needs to.
So I really try not to say "it's done," but more where it is at in this SDL.
"When I pass a series of inputs to the classifier, they are tagged with at least 65% precision and at least 65% recall."
It could be that the available data and current approach yield only 63%, in which case the user story is being worked on indefinitely for months.
Or it could be that 65% is achieved, but the threshold chosen was a wild guess; business value is actually linear all the way up to perfect, so it's worth iterating indefinitely.
The scrum & user story format work well for small and unambiguous units of customer-facing behavior, but some software is made of more than that.
I think the word architect is a failed metaphor for software.
What is the role of architect in the real world? In some high profile cases they are designers - even to the point of doing something like project management/business development (the only reason we funded this project is because of the awesome ideas we got from the architect, we worked with the architect to make sure the building would meet our dreams for this project ...). But more commonly — I understand their role more in construction to me more in the realm of being a maintainer of documentation — maybe they have some role in proposing the original design but the majority of their time is probably spent ensuring that these plans satisfy all required regulations — and updating the plans in response to what actually happens during building so that the building itself will pass all regulations ...
This is nothing at all like the nebulous responsibilities generally associated with software architects. Some projects could benefit from this level of book keeping requirement — but a lot of projects which contain “software architects” probably would reject paying someone to maintain specifications to a similar level of accuracy as is required of real world architects — especially if that was basically all that was being asked of them to do ...
That's a step in the right direction for all major components to be designed together but it's not adequate because normally you have to make structural changes to components over the course of the development and maintenance of the project.
So all components need to be designed and maintained with a high degree of visibility and ideally direct cooperation.
My impression is that the core structures of these contracts are always flawed. For example, they seem based on detailed pre-estimation and fixed fees. To me it would be more realistic to give ranges and focus on core goals and milestones with the expectation that detailed requirements will evolve.
But stepping back even further, the paradigm that drives all of this which is labelled as "defense" is quite an outdated paradigm. So expecting operational aspects to make sense might be asking too much. The paradigm goes back to for example https://en.m.wikipedia.org/wiki/Roman%E2%80%93Persian_Wars
I don't believe in architecture being done fully via a separate role, it's counterproductive.
What you need instead is developers on the team who also understand software architecture, and implement it especially in it's initial phases.
This takes more senior developers, then later on less experienced developers can jump in once the structure is in place.
But a completely separate person external to the development team, which is going to define the architecture using text and diagrams only?
That doesn't exist, it's a myth. What ends up happening in practice is that some senior developer on the team ends up implementing the actual architecture, and those documents are used just as broad guidelines at most.
For larger or more complex systems, focusing on a subsystem software architecture from a purely technical execution point of view is myopic, since the overall architecture is much more than a subsystem architecture.
Even if a senior developer ends up "implementing the actual architecture", if that does not mesh with the other subsystems and the other stakeholders, their conflicting requirements, and their weighting of the architectural quality attributes, and so on, the end result misses the goal.
Details become more concrete the more closer one gets to the developer. Conversely, if one goes the other way, things become more abstract. You need people for the topmost abstraction level, people in the middle levels who understand both the abstract and the concrete, as well as the people at the lowest abstraction level where the implementation happens.
Of course, sometimes the systems are small enough or well-defined enough so that the person in the middle level can be the same as the highest-level keeper of abstractions.
I don't think having a separate role of an architect is always counter-productive. The architect as a separate role can be useful: that person listens to other people and teams and filters and translates their desires into something which can be defined unambiguously to be actually implemented. If the architect has time to code too, that's great. If not, then there must be those senior developers who can create the more technical parts and write code, too.
The book’s use of the term “architecture” is pretty different from modern usage. It refers to the shape that the new computer/OS will present to application developers. The architect is something like a product manager; a voice for what the customer wants.
What my team calls “architecture” - the decomposition into services and classes, database schemas, interfaces between major components - I think Brooks would call “implementation design.”
It seems to me that he would think interfaces between major subsystems would be architect level while any database table that only gets used within a single sub system is implementation level.
Trying to be careful as I realize HN is the kind of forum where he or a close friend of him might show up to correct me :-)
Brooks famously showed up to correct himself: the book advocates against information hiding but he later changed his mind and said encapsulation was a good thing.
In agile world software architect does not fit in. This is where the conflict comes in. people thinking in old traditional software architect system meets agile teams. It does not work however we have been successfully working in a team as lean architectures which is a perfect balance for architect role combining with scrum teams.
I don’t think this is true. Agile doesn’t mean that you don’t consider long term trade offs, only that you don’t wait until all the requirements and studies are done before commencing system implementation. Involving software architects in the process actually makes agile work better, as they’re able to provide insight into fixing emergent issues that crop up in a better way.
That is what I meant but you have to think differently from traditional architecture. Like you can’t be design system upfront when scrum teams are sprinting
She is talking about systems as in "GPS" or "Drone fleet", i.e. huge systems with significant hardware components and that these days software will be such an important part that it needs to be a part of the earliest designs and requirements.
This conversation has gone in a completely different direction from the article. We're now all complaining about architects instead of the point it's trying to make.
But you can't fix that, so I'll chime in.
In my opinion, an Architect is just a role that gives advancement opportunities to individual contributors that doesn't go down a management path. You're still a part of the dev team, and you still do work.
When I've been in that role, that's how I treat it, and it's worked out pretty well. Generally speaking, when the position gets treated that way, I'd get involved in new products or major changes. For major changes, there's a specific thing we're targeting that needs something different. An extra complexity or just a different approach. That's all I focus on while writing the design document in response to the requirements document. Everything else is fine, but we need to do this one specific thing differently to make it work better. And this will have trickle-down effects on the rest of the system that's going to have to accommodate it. If I've done my job well, those are reasonably doable without that much explanation. I'll write the prototype that gets at the core of what needs to change, do code review with the team I'm eventually going to hand it off to, and explain my decisions in person. Once everyone is on the same page and gets what we're trying to do, I can hand it off and move on to something else.
For new products it's a little different. We want to make sure that we learn from our past wherever we can. Companies often have themes to their products and even a completely greenfield project isn't totally different from other stuff you've done. There's lots of stuff floating around that isn't great, but it's not so bad that you're ready to invest in a "major change." But if you had to do it all over again, you would do it differently.
That's what you want to make sure you capture when you start a new project. So again, there's requirements. And again, I write a tech document that represents my interpretation of the specs as it applies to the systems in play. The vast majority of these don't really matter, and any competent developers on the team can handle them. So my input is to focus on the things that are non-obvious and caused problems for us in the past. But the end result is the same: I write the prototype, workshop it with the team that's going to be taking it over, and hand it off and move on when everyone is confident that we all know what needs to be done.
Sometimes, it's not either of those things. Sometimes there's just a really annoying bug that needs tracking down and is really hard. It might not even be caused by the system your team is working on. You might need some cross-team investigation to figure it out. Sometimes you need a wider knowledge than a specialized team has. And sometimes it's just because some shit is broken that you wrote 6 years ago, and no one noticed until now because no one used it quite this way back then, but now everyone uses it that way, and it's awful, and half the reason you got promoted to architect is because that solution was mindblowing and novel, but now it sucks because no one knows how it works. Not even you. So it's your problem, genius, so go fix it. And you go crawl in a hole of shame.
Architect as anything other than really super double senior engineer doesn't make sense to me. Architect as an outside hire doesn't make a ton of sense to me. Architect as a layer of management that's not engaged in building software doesn't make any sense to me at all.
Architect makes sense as a retention strategy. It makes sense as an upward path for ICs. Architects should mentor.
Architect shouldn't be a special title. It should be a normal result of doing solid work over time by a person who wants to keep doing solid work instead of switching to management track just to justify a raise/promotion.
I never been able to get clear answer. What exactly is the role of a manager, why are they so highly paid. What does a software manager do on typical day.
They are paid more because they are multipler. They represent the department. Speaking to this one person I can get the whole department to do something. When something goes wrong that person has to answer for it.
On a typical day a software manager does work their boss assigns them and answers your questions/queries from other departments.
- Provide status updates to bosses. Reports / presentations in regards to department goals.
- They watch over the developers/leads make sure they are productive / issues handled
- They attend other department meetings, vendor meetings
- They read over everything and provide signoff
- They attend community events and represent the department
Every place is different. A manager could be a lead and expected to jump in and code.
A manager could be an office manager or a project manager or a product owner as well.
Does that help? They manage the department.. ensure resources are in place.
One of the crappier roles. Very little power, low respect from above or below. Slightly higher pay in general but not uncommon to be the lowest paid in the department.
Give your manager a high five once in awhile. They do a lot to make your life easier.
Depends a lot on each company, but managers are responsible for hiring/firing, holding their teams accountable to quarterly targets, shielding their team from politics, helping each engineer grow professionally (including having one on ones with everybody and doing performance reviews), and making sure the team gets the resources they need to do good work (which can include managing budgets and arguing for more capital allocation).
At some places they are also responsible for coding (this also depends on seniority), and at many smaller startups they will also play the role of product/program manager since the companies haven't hired for those positions yet or are not even aware of what those positions are.
I can't comment on specific cases, but I think most engineers are wildly unaware of just how much work it is to play politics at any company, and it's an unspoken part of the job for any manager.
There are of course many definitions. In my current small company, here's one definition of the "technical manager" role:
Figure out what to do, figure out what not do (10x more work), handle hiring/firing (both are really hard, but in different ways), handle random human situations with employees, motivate the team, get people to grow (give them incrementally larger individual responsibilities over time), get developers to focus on stuff that actually matters, manage the technical debt, plot a clear plan forwards. Feed developers with tasks, suitably small or large depending on their XP level. Learn exactly what kind of tasks each individual can handle. Pre-chew medium-hard tasks so that the can be handled by junior devs. Follow up on tasks, especially those that have an architectural impact. Create product progress. Manage issue tracking. Be on top of devops. Do some random small dev tasks yourself so you don't lose track of the code. Run regular team meetings. Etc. It's an exercise in time utilization/fragmentation.
For example, a project manager's role is to track progress of a project, reveal and resolve deadlocks (A waits on B, B waits on C, C waits on A), communicate progress to the outside and so on.
In other cases, managers act as proxies for teams. If you want something from a team, nobody expects you to talk to all 12 members and convince everybody -- instead you talk to the manager, and the manager then talks to the (relevant parts of the) team.
From the team's perspective, a good manager shields them from most of the company's politics, declines nonsense requests early on, organizes all materials necessary for the team to work etc.
In general, managers are paid well because they carry a lot of responsibility. Even a brilliant team will underperform under a terrible manager, and a very good manager can bring out the best in teams.
I’m friends with a architecture manager at one company in Austin that has 4 direct reports, attends a few meetings a day, spends his downtime doing online courses prepping for the next job change, all while making 145k/year.
My manager at a previous company had coding responsibilities in addition top 15 direct reports and was really overworked.
Delegate work. Thats pretty much it, coz in most cases they don't have expertise to do anything else (you will hear a lot of other arguments but when you dive deeper or investigate its all PR bullshit).
Keep in mind that delegating requires separate kind of skills to engineering. Tho often times I see an insult that managers don't understand the tech to make an impact.
Ps. Im not neglating some parts of the work they do. Simply comparing it to the amount of knowledge that is required in other parts of production chain.
Way back when I worked in organizations that had production lines, we had a job called "progress chaser". I think much of what goes on in a typical software project is the same kind of work.
