13 ms·

Software architects should be involved in earliest system engineering activities

225 points by runningmike 7y ago

RcouF1uZ4gsC 7y ago
Seems to be getting the HN hug of death. Here is an archive: http://archive.is/IT34b http://archive.is/IT34b
goatinaboat 7y ago
This strongly reminds me about this over on Stack Exchange: https://workplace.stackexchange.com/questions/141278/complaints-from-junior-developers-against-solution-architects-how-can-we-show https://workplace.stackexchange.com/questions/141278/complai...
- dtech 7y ago
  Jesus Christ that post shows everything that's wrong with Software Architect as a role and the guy is completely oblivious to it
  - qznc 7y ago
    There is a very interesting part "No complaints from senior developers".
    - dtech 7y ago
      Stockholm syndrome and self-selection, since people who are not willing to put up with it leave long before they become senior developers
dominotw 7y ago
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.
- MegaButts 7y ago
  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.
- pojzon 7y ago
  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.
- perlgeek 7y ago
  There are many types of managers. 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.
paulsutter 7y ago
Does software need to be architected? Yes. Does this require a dedicated role called "Architect"? No. Usually the key implementor architects software. Even in a large complex system, you really want key implementors working together to design.
- 9wzYQbTYsAIc 7y ago
  Thank you for clarifying your statement. But you should have kept the part about what an architect is.
- perlgeek 7y ago
  I think that depends on the size of the project. 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.
- twblalock 7y ago
  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.
  - paulsutter 7y ago
    Their title is architect, but they ... don't architect? > They don't design the architecture -- they convince all of the participants in a project to collaborate on designing the architecture
2bitencryption 7y ago
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.
arkadiytehgraet 7y ago
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.
- perlgeek 7y ago
  > 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.
- heydenberk 7y ago
  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.
9wzYQbTYsAIc 7y ago
> “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. How do you convey doneness in your projects?
- streetcat1 7y ago
  1) You slice your project into use cases. 2) You "do" every use case end to end (including the pieces of infra needed for that use case and the user interface parts). 3) You add regression tests (unit / func) for the use case. 4) Every new such use case is a new release. This way you are always done.
  - rumanator 7y ago
    Then there's the fact that requirements do change, and do change often, and of course there are bugs and emergent design issues.
    - streetcat1 7y ago
      Absolutely. But this is just another use case. The real risk of working UC by UC, is that you might get locked into bad architecture. The way to mitigate that is by using microservices.
- cbanek 7y ago
  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.
asimpletune 7y ago
This reminds me of Conway's Law https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law > organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
deleted 7y ago
[deleted]
glenjamin 7y ago
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".
- malandrew 7y ago
  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.
  - taurath 7y ago
    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.
- mixmastamyk 7y ago
  Some places call this a "Principal Developer." Believe it is largely the same thing, i.e. software/system designer.
  - zwkrt 7y ago
    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.
throwawayjava 7y ago
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...
- kejaed 7y ago
  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.
- cc81 7y ago
  Yes, people seems not to be reading the article at all. Someone should just change words to "hardware people" and "software people" and I think people here would receive it better.
infinity0 7y ago
Principle Systems Architect: write lots of non-executable articles about why an organization needs a Principle Systems Architect, and complain loudly when the executable stuff doesn't match their article, except it actually does because the article contents are obvious tautologies, but they get frustrated reading other people's code and are unable to abstract away (ignore) the real-world concrete parts needed to make a piece of work actually executable.
eitland 7y ago
I've recently taken time to start reading The mythical man-month book by Fred Brooks. As far as I remember (first read through this week and big parts of the book is stuffed with quotable material) he says that - that the architect should be able to provide an example implementation - but that it is also important that the architect steps back and stays away from the actual implementation I've more or less already decided to re-read that book. Highly recommend and available in searchable selectable PDF form from archive.org
- closeparen 7y ago
  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.”
  - eitland 7y ago
    Partially agree: 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 :-)
    - bboreham 7y ago
      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.
      - qznc 7y ago
        Interesting. Do you have a link or reference for that?
cryptozeus 7y ago
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.
- pm90 7y ago
  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.
  - cryptozeus 7y ago
    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
bartimus 7y ago
Architect: "I have a great idea!" Developer: "Oh nice! Go ahead and build it!" Architect: "No I can't do that. I don't know how!" Developer: "Oh..." Building architect: "I've scheduled a meeting so I can present the PowerPoint presentation of this cool new building I've been designing." Client: "Oh great! Do you have a mock-up?" Building architect: "No" Client: "Ah you have a 3D virtual reality tour then perhaps?" Building architect: "No, just some slides" Client: "Oh..." When are people going to learn there's no human execution in software development? It's the computers who do the execution. Not the developers. The developers are the architects. They design the blueprints for the computers to execute. If developers are doing a bad job that doesn't mean you need architects. It means you need better developers.
kazinator 7y ago
> Software architects should be involved in earliest system engineering activities. Rather, the people doing these activities should have a solid background in software. If you don't have software kung-fu, you shouldn't be designing something that will be heavily programmed in order to fulfill its function.
- cc81 7y ago
  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.
thinkersilver 7y ago
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.
- Buttons840 7y ago
  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.
  - ramraj07 7y ago
    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.
  - sb8244 7y ago
    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
- cc81 7y ago
  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.
breatheoften 7y ago
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 ...
- username90 7y ago
  Software architects are more like ancient architects who were responsible for everything, which includes structure integrity and load requirements.
vfc1 7y ago
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.
- jnurmine 7y ago
  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.
moksly 7y ago
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.
higherkinded 7y ago
The fact that someone needs to say that for it to be apparent is somewhat unsettling.
ilaksh 7y ago
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 https://en.m.wikipedia.org/wiki/Roman%E2%80%93Persian_Wars
reilly3000 7y ago
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.
- xMAY 7y ago
  I've never seen such an architect in software and I'm surprised this is the top comment here. HN has been taken over by talkers and bullshitters.
- qznc 7y ago
  As a software architect myself, I agree. 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.
ianamartin 7y ago
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. Just my thoughts.
shyneeup 7y ago
What is the role of an architect nowadays?

225 points by runningmike 7y ago

Seems to be getting the HN hug of death. Here is an archive: http://archive.is/IT34b http://archive.is/IT34b

This strongly reminds me about this over on Stack Exchange: https://workplace.stackexchange.com/questions/141278/complaints-from-junior-developers-against-solution-architects-how-can-we-show https://workplace.stackexchange.com/questions/141278/complai...

dtech 7y ago
Jesus Christ that post shows everything that's wrong with Software Architect as a role and the guy is completely oblivious to it
- qznc 7y ago
  There is a very interesting part "No complaints from senior developers".
  - dtech 7y ago
    Stockholm syndrome and self-selection, since people who are not willing to put up with it leave long before they become senior developers

dominotw 7y ago

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.

MegaButts 7y ago
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.
pojzon 7y ago
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.
perlgeek 7y ago
There are many types of managers. 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.

paulsutter 7y ago

Does software need to be architected? Yes. Does this require a dedicated role called "Architect"? No. Usually the key implementor architects software. Even in a large complex system, you really want key implementors working together to design.

9wzYQbTYsAIc 7y ago
Thank you for clarifying your statement. But you should have kept the part about what an architect is.
perlgeek 7y ago
I think that depends on the size of the project. 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.
twblalock 7y ago
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.
- paulsutter 7y ago
  Their title is architect, but they ... don't architect? > They don't design the architecture -- they convince all of the participants in a project to collaborate on designing the architecture

2bitencryption 7y ago

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.

arkadiytehgraet 7y ago

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.

perlgeek 7y ago
> 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.
heydenberk 7y ago
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.

9wzYQbTYsAIc 7y ago

> “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. How do you convey doneness in your projects?

streetcat1 7y ago
1) You slice your project into use cases. 2) You "do" every use case end to end (including the pieces of infra needed for that use case and the user interface parts). 3) You add regression tests (unit / func) for the use case. 4) Every new such use case is a new release. This way you are always done.
- rumanator 7y ago
  Then there's the fact that requirements do change, and do change often, and of course there are bugs and emergent design issues.
  - streetcat1 7y ago
    Absolutely. But this is just another use case. The real risk of working UC by UC, is that you might get locked into bad architecture. The way to mitigate that is by using microservices.
cbanek 7y ago
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.

asimpletune 7y ago

This reminds me of Conway's Law https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law > organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

deleted 7y ago

[deleted]

glenjamin 7y ago

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".

malandrew 7y ago
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.
- taurath 7y ago
  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.
mixmastamyk 7y ago
Some places call this a "Principal Developer." Believe it is largely the same thing, i.e. software/system designer.
- zwkrt 7y ago
  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.

throwawayjava 7y ago

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...

kejaed 7y ago
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.
cc81 7y ago
Yes, people seems not to be reading the article at all. Someone should just change words to "hardware people" and "software people" and I think people here would receive it better.

infinity0 7y ago

Principle Systems Architect: write lots of non-executable articles about why an organization needs a Principle Systems Architect, and complain loudly when the executable stuff doesn't match their article, except it actually does because the article contents are obvious tautologies, but they get frustrated reading other people's code and are unable to abstract away (ignore) the real-world concrete parts needed to make a piece of work actually executable.

eitland 7y ago

I've recently taken time to start reading The mythical man-month book by Fred Brooks. As far as I remember (first read through this week and big parts of the book is stuffed with quotable material) he says that - that the architect should be able to provide an example implementation - but that it is also important that the architect steps back and stays away from the actual implementation I've more or less already decided to re-read that book. Highly recommend and available in searchable selectable PDF form from archive.org

closeparen 7y ago
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.”
- eitland 7y ago
  Partially agree: 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 :-)
  - bboreham 7y ago
    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.
    - qznc 7y ago
      Interesting. Do you have a link or reference for that?

cryptozeus 7y ago

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.

pm90 7y ago
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.
- cryptozeus 7y ago
  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

bartimus 7y ago

Architect: "I have a great idea!" Developer: "Oh nice! Go ahead and build it!" Architect: "No I can't do that. I don't know how!" Developer: "Oh..." Building architect: "I've scheduled a meeting so I can present the PowerPoint presentation of this cool new building I've been designing." Client: "Oh great! Do you have a mock-up?" Building architect: "No" Client: "Ah you have a 3D virtual reality tour then perhaps?" Building architect: "No, just some slides" Client: "Oh..." When are people going to learn there's no human execution in software development? It's the computers who do the execution. Not the developers. The developers are the architects. They design the blueprints for the computers to execute. If developers are doing a bad job that doesn't mean you need architects. It means you need better developers.

kazinator 7y ago

> Software architects should be involved in earliest system engineering activities. Rather, the people doing these activities should have a solid background in software. If you don't have software kung-fu, you shouldn't be designing something that will be heavily programmed in order to fulfill its function.

cc81 7y ago
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.

thinkersilver 7y ago

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.

Buttons840 7y ago
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.
- ramraj07 7y ago
  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.
- sb8244 7y ago
  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
cc81 7y ago
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.

breatheoften 7y ago

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 ...

username90 7y ago
Software architects are more like ancient architects who were responsible for everything, which includes structure integrity and load requirements.

vfc1 7y ago

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.

jnurmine 7y ago
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.

moksly 7y ago

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.

higherkinded 7y ago

The fact that someone needs to say that for it to be apparent is somewhat unsettling.

ilaksh 7y ago

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 https://en.m.wikipedia.org/wiki/Roman%E2%80%93Persian_Wars

reilly3000 7y ago

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.

xMAY 7y ago
I've never seen such an architect in software and I'm surprised this is the top comment here. HN has been taken over by talkers and bullshitters.
qznc 7y ago
As a software architect myself, I agree. 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.

ianamartin 7y ago

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. Just my thoughts.

shyneeup 7y ago

What is the role of an architect nowadays?