9 ms·

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful co

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems using UML or otherwise. And they'd know the classics, like memorizing all design patterns. Finally, they'd use formalized architectural decision making methodologies to justify tech choices. Nobody seems to do anything like that anymore. Everybody is half-assing design or skipping it entirely. Solutions are reinvented and tech choices made on a whim by the loudest person whom won't see the consequences of it anyway. Because we've told ourselves that shipping garbage in short cycles is the one and only way to do things.

rr808 3y ago
Now hardware and bandwidth is so cheap now you dont have to care about design so much. Make a service, JSON in JSON out. Some kind of loose versioning but no formal schema and fix it up as it goes.
shinycode 3y ago
So sad and so true
colordrops 3y ago
The pendulum swung, and now we bias towards action rather than design. But to be honest, the "software architect" era wasn't great either, with people in the role sometimes not qualified, spending months on an architecture behind the curtain, releasing some over-verbose spec document that doesn't match the product needs, cargo-culting the latest fad from Martin Fowler.
- phs318u 3y ago
  Just as well we no longer cargo-cult any practices these days.
  - deleted 3y ago
    [deleted]
beyonddream 3y ago
I am curious to know what are these “formalized architectural decision making methodologies” ? Any books that u know of that cover these topics ?
- jt2190 3y ago
  “Rational Unified Process” https://en.m.wikipedia.org/wiki/Rational_unified_process https://en.m.wikipedia.org/wiki/Rational_unified_process
  - beyonddream 3y ago
    Oh this! I suffered learning this during college ;)
mkozlows 3y ago
Yeah, hard disagree on all that. As someone who lived through that era professionally, and who has had an "architect" title in the past, I was actually resistant to ever stepping into that role, because I had so many bad experience with the Formal Architecture Methodology crew, who would produce the most absurd and out-of-touch designs. There's a reason that "architecture astronaut" is a term from that era. Lots of people make bad designs today, sure, but it's not for a lack of formal methodologies, because average design quality was way worse back in the design patterns 'n' UML days.
- fmajid 3y ago
  Seconded. I once went to an IBM seminar with Grady Booch and seldom have I heard such an inane string of platitudes. Architecture Astronauts are the worst, and if there is one thing Agile can legitimately claim for, it's getting us rid of that plague.
  - doctor_eval 3y ago
    I agree with you both except that architects are alive and well. I worked with an ex IBM architect a couple of years ago. Lovely guy but for someone designing software systems, I found it remarkable that he didn’t know how to write code.
    - gedy 3y ago
      I worked for a company not long ago that had leadership which felt you can't be a real architect if you write code. See ya!
    - cogogo 3y ago
      All of these experiences resonate with me. The pendulum has swung hard to the continuous deployment model and just like the other side of the long arc of the pendulum not everything about it is good.
    - snapetom 3y ago
      I'd say this is a company red flag if they are still having these people around. About four years ago I was at a company that still had someone like that. Useless and highfalutin, he obstructed many projects thanks to an archaic director who thought he was still necessary. I got out after butting heads with him constantly, and I don't think said company ever shipped anything meaningful in his entire tenure here.
peanut-walrus 3y ago
Software architects, much like real architects, often end up with absolutely beautiful elegant designs which are unfit for purpose and have leaky roofs.
- bluGill 3y ago
  And other architects make buildings/software that gets done on time because unlike babies adding people can make things go faster (it is always sub linear, but good architecture can get close to linear, while bad can go negative slope)
doctor_eval 3y ago
I don’t think this is any more true than it ever was. If anything, the rise of open source libraries, GitHub and friends has made it easier than ever to reuse software and avoid NIH. This has lead to a different set of problems, but relative to when I was writing C in the 90s I’d say software reuse and design is far advanced from those days. I do however agree that design is sorely missing from the current software project management zeitgeist, which means it’s done in a more ad hoc way. People are taking frameworks like Scrum far too literally, and I agree that in some cases there is little vision or overall architecture because the framework doesn’t include these things. There should be design and review activities both before and after coding, but these are largely neglected from most project management frameworks. Scrum for example doesn’t even include backlog management, which in my work is a critical activity. While that doesn’t mean design, architecture and scope management is not done, it’s certainly less visible than it might be. All of that said, I’m a big believer that the ultimate expression of any design is code. The design artefacts that come before code is written are scaffolding, age quickly, and are soon useless. So there’s not much need to keep them around, and they are mostly of interest as preliminary directions. In this regard I’m a big fan of Jack Reeves essays from the same period at https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...
_proofs 3y ago
while i feel as if i largely understand what you're pointing out, i kinda want to offer my own speculation as a SWE who is very guilty in thinking in terms of sequence diagrams (and also more formal UML) -- sometimes UML is so fucking bogged down with (impl) details, i am just over here going "i don't give a shit about the (impl) details, i just want to know the abstract concept(s), and logical flows, and focus on necessary system interactions" -- bc i can (and should at this stage) worry about (impl) details later. i prefer to reason about a system and component relationships using, say, a single word as representation, instead of glaring at one or many inheritance directionals, interface details, and other "field" information, which is usually conveyed in a UML node. i do not think the lack of formalism is a degradation -- we work with abstractions after-all, so it makes sense to further leverage that fact and express things simply, at a high-level, and straight-forwardly -- you can pack a lot into a single word. of course as the nature of any tool, there is a time and a place for its application. but i don't think it is fair to call it a degradation.
- DSMan195276 3y ago
  I've noticed the "over-detailed" problem a lot at my company that has dedicated "software architect" roles. IMO part of the issue is that most of them do not write any code anymore, but 'architecture' alone just doesn't have a full-time job's worth of stuff to do (or they're bad about finding it). The 'solution' they end up on is just treating UML like code and specifying exactly how they would have written the whole thing - which is a huge waste of time when they could have just been writing real code.
lainga 3y ago
Has anything replaced UML? I mean, if there are teams out there that aren't shunning design, what do they use to create architecture diagrams?
- doctor_eval 3y ago
  I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases. I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation. I’m also not afraid to use stuff that’s out of fashion. I use simplified ER diagrams, and even flow charts on occasion. But the tool I use most often in design is SQL DDL… I have also used Mermaid (using a modified Docsy theme in Hugo) and it is also great. Using Typora to edit Mermaid is also excellent.
  - ozim 3y ago
    I like use case diagrams as well. Thing is these should be short lived and used to make specific illustration in specific time. Not some holy grail of documentation that people should take as some god given truth for whole life of the system.
    - doctor_eval 3y ago
      Yeah, I posted elsewhere in this thread that I'm a big fan of Jack Reeves' essays on "code as design"; namely, that the code is what's important, and the design is just scaffolding. "The following essays by Jack W. Reeves offer three perspectives on a single theme, namely that programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself. This simple assertion gives rise to a rich discussion—one which Reeves explores fully in these three essays." https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...
    - macdaknife 3y ago
opportune 3y ago
That’s because software architecture is something any senior employee should be able to do, and it’s not as important as people thought. Like many abandoned corporate practices, I think it was abandoned for good reason. It may have made sense under different circumstances, like when you had a large army of cheap offshore devs who could not be trusted to architect a maintainable application. If I had some ivory tower “architect” trying to interfere with my work I’d be so pissed. Anybody I’ve seen with that title, that wasn’t doing 1P cloud consulting where the title means something different, usually had no clue what they were doing and had been given the title as a soft retirement.
- eropple 3y ago
  As much as I do think that software architecture does matter (though it should probably be somebody with a staff or principal hat, not a specific job title) I recently took a job at a place that really does like architect titles. Mine's even "lead architect". It is pretty funny when somebody runs into me and realizes for the first time that I have the job because I build stuff and write code, not because I'm good at LucidChart. I'm planning things out beyond immediate needs, but not because I'm looking for job security--it's because I've built the thing we're doing before and would like to not make the same mistakes I've made in the past. I'm over here demanding adequate standards of code and low- to mid-level design, and the "wait he's serious?" of it is sometimes honestly pretty fun to run up against. I am good at LucidChart though.
  - opportune 3y ago
    Yeah, I guess I would in retrospect refine my opinion to “software architecture is iterable and not completely separable from implementation” or that “architecture (as imagined by distinct architects who are shielded from implementation concerns) is not important”. Principal engineers and such who are still involved in operations, implementation, and more tactical approaches are who I also think are “supposed” to be doing architecture, but even then, more as guides and first among equals than as people who hand down decisions from on-high. The fundamental issue I have with a separate architect position is that it disempowers teams and makes them beholden to decisions that they may not agree with (and which very well may not understand the problem to the extent they do). It sounds like you’re doing the better thing of running up and down the layers of abstraction so your contributions empower people rather than disempower them
lmm 3y ago
We stopped doing that stuff because it was useless. We eliminated those practices and that profession because it was actively harmful to making good software. All those decision making methodologies consistently lead to worse technology choices than one dude actually trying to write some code with the thing for half an hour.
- icedchai 3y ago
  UML is mostly useless, but thinking ahead, even a bit, has value. I've seen stuff shipped in a sprint that was not used by any actual end users, only to be "redone" in the next sprint.
  - lmm 3y ago
    My experience is that shipping stuff that doesn't get used by any actual end users is more often caused by thinking ahead too much than by thinking ahead too little.
    - icedchai 3y ago
      I've actually seen it both ways: whole features (or even products) that were too early. But on the implementation level, I've seen someone pick the wrong thing (library, database, whatever) "because it was simple", only to have it be thrown out before getting any real usage.
      - kubanczyk 3y ago
        "Pick the wrong thing and then retract, losing some work" is as close to optimal as you can get. Iterate. The much worse outcome is "pick a thing, fiercely defend it whether it helps the ship to float or to sink".
        icedchai 3y ago
        I agree that outcome is worse. However, both extremes are bad. The optimal approach would be to do a little bit more work upfront, pick a "better" thing (where "better" is at least more than the next sprint or 3!), and use that.
cptskippy 3y ago
The problem you're describing Exists in all engineering disciplines. You don't hire firm to feasibility studies, develop a design plan, do a materials bid, sub contract clearing and construction for your mailbox installation do you? Most people hire a dude hanging out at Home Depot and pay him a flat fee. The risk and complexity dictate how much architecture and engineering are involved and with all things, businesses will try to get by with a bare minimum. The automotive, chemical, and other industrial sectors invest a lot in software architecture and enterprise architecture because the risk is so high. But even a medium size e-commerce platform has very low risk or complexity.
jrochkind1 3y ago
> And they'd know the classics, like memorizing all design patterns. That sentence is bringing back ptsd-like flashbacks. I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing. I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The phrase "architecture astronaut" was a common epithet, and not a friendly one] That above paragraph [without the brackets], ironically, could certainly be said of "agile" more recently too. I don't know how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. But yeah, I'm pretty convinced going back to appointing some almighty deity architecture astronaut who isn't responsible for or involved in any implementation (let alone operations!), who hands down plans from on high after "memorizing all design patterns" and drafting some diagrams, never sullied by "contact with the enemy"... no thank you, but thank you. ---- Instead of just complaining about that though, what I'll say in addition is -- I think the real problem is that engineers aren't given the time to carefully consider top-level designs. it's a basic business/resource issue -- until engineers have more breathing room to talk to each other and research and consider and come to decisions in an unhurried way, the top-level design stuff will remain chaotic. It's not an issue of appointing an ivory tower "architect", or something solved by it. Although sure, there should be senior and even "staff" or "principal" people with more authority/responsibility for higher-level designs. Everyone should be responsible for design at the level they are working. Everyone needs enough time to feel like they are doing it well, instead of running on a sweatshop code production treadmill.
- jrumbut 3y ago
  To be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries. If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new things that would have taken too long to do before. And that was the intent of the Gang of Four book, not to teach you patterns you should copy mindlessly, but to give examples of how to identify and extract useful patterns from the software you've already written and describe them to others. Since that is a lot more difficult than memorization, very few took up that work.
yafbum 3y ago
We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.
- ilyt 3y ago
  And they just shipped garbage in longer cycles... as anyone that had to deal with such designed legacy apps can confirm.
- RachelF 3y ago
  In truth it depends on the software. For web or phone or desktop apps which can be upgraded on the fly, short cycles are ok. On the other hand, Boeing's crappy software practices resulting in the 737-MAX crashes are an area where short-cuts killed people.
  - phs318u 3y ago
    So much this. Coding to marketing dictums on the cycle of days/weeks is completely NOTHING like engineering solutions where subtle design issues can make the difference between life and death (or IRL super good thing A and IRL super bad thing B).
- klabb3 3y ago
  > The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run The same market that gave us AT&T, Comcast, DRMed IoT Juice presses, FTX, Enron, and so on? Not sure it’s wise to conclude that the market produces optimal solutions, or even incrementally better solutions than yesterday. Especially in domains with extremely long feedback cycles, like organizational trends. I DO think there is some hocus pocus market zeitgeist that does something resembling gradient descent, but it’s acting over very long cycles and there’s a ton of room for cargo culting, grifting, and opportunistic grabs along the way. Heck, marketing is an entire field dedicated to affecting “rational actors” in the marketplace.
maximinus_thrax 3y ago
> Everybody is half-assing design or skipping it entirely. Solutions are reinvented and tech choices made on a whim by the loudest person whom won't see the consequences of it anyway. Because we've told ourselves that shipping garbage in short cycles is the one and only way to do things. I agree. I don't personally fetishize the old slow processes nor ivory tower architectures, but I think there's a healthy spectrum between that and the complete 'software fuckery' (https://web.archive.org/web/20160308032127/https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877 https://web.archive.org/web/20160308032127/https://medium.co...)
hejcloud 3y ago
German speaking. You can take German IT to get an idea what would have happened to SWE if you'd have kept those bureaucratic methods from the 2000s as the backbone of all SWE endeavors: a horrible, expensive, non-working mess with barely any progress. I think what many people, esp. from outside the SWE world, don't get: Software engineering is a deeply social kind of work. There are dozens of solutions for the given problems, you have to agree on one that works for all peers. That's the job. Optimizing it for drawing funny diagrams is not an issue if not for communication.
- _dain_ 3y ago
  I'm not familiar with how IT works in Germany. What's different about it? Got any stories?
  - userbinator 3y ago
    One word: SAP.
    - artyom 3y ago
      Oh no. I'm so sorry.
- devin 3y ago
  I'm also interested in the german software engineering culture. And also, heavy plus to this being a social problem more than a "engineers just need more time" problem. I tried to articulate this in another comment of mine but mostly beat around the bush. This is more directly what I was attempting to say.
  - hejcloud 3y ago
    Well in my theory core reason is that Germany never developed a thriving startup IT economy[0] that was ever relevant for the GDP, especially not in comparison with the industrial sectors (cars, steel, chemistry) and so IT completely got ignored by politicians. That resulted in no one who'd challenge the biggest gatekeepers Telekom and SAP, so they lobbied for and enforced whatever they wanted[1]. If you study CS in a German university you can easily get an MA without being able to write software at all (I personally happen to know several people). German universities teach what is easy to teach top down and test for: The textbook stuff that came out of the whole Java EE/OOP/SOAP/UML sector. You barely get practical coding lessons and can avoid them completely if you want. The academic sector never realized how crappy German software products are and never bothered looking at what Big Tech is doing. With given data protection and soon AI regulations, as a university you'd have a hard time collecting enough training data because your law department would step in referring to the current legal insecurity (I've heard stories from friends). Then we have this little crazy island Berlin which up until maybe 10ys ago was mainly driven by the infamous Rocket Internet "startup incubator" which is led by a couple of MBA sociopath billionaires, trying to copycat everything from SV and then sell it back to the SV company whenever they wanted to start conquering Europe. Thing is they never really developed enough SWE excellence to get the copycat successful in Germany or anywhere in Europe (with some exceptions). Third example? Here you are: Today I learned that the gov't already decided 20ys ago that they want to provide all usual governmental services online. 20ys later they (allegedly) poured 3.5Bn EUR into an unholy setup of consulting businesses, incompetent civil servants and a panel of software architect astronauts who could never really agree on things. All their deliverables are click-dummies, gazillions of PDFs with SOAP/WSDL/OMG/UML thingies and prototype projects rolled out in "experimental" cities. So if you happen to live in Bremen you might be able to register your dog online but not in Berlin. Therefore in Berlin you might be able to get a license plate for your car online. Pretty much all governmental projects (Covid vaccination registration, special governmental aid for students because of high inflation, etc.) broke down because all their systems are incapable of handling more than maybe 10k visitors (in my theory it always breaks down whenever the biggest single Oracle DB host they could buy is going down). Germany has some decent software engineers, especially if they're self-trained and not brainwashed by one of the universities or big corps. But the environment manages to regularly piss them off and make em emigrate to somewhere else. Ouff, much text. Hope at least someone enjoys reading it. --- [0] This is because if you start a company in Germany you're faced with horrible bureaucracy wrt taxes, laws, politics, governmental authorities, etc. For example, you're forced to pay for a membership in a funny non-IT institution called "Industrie- und Handelskammer (IHK)" which essentially consists of a crowd of old men who are officially supposed to lobby for you and create a networking environment but if you ask them something like "hey, can you tell me how many companies are having problem XYZ right now?" they will tell you that they don't have any numbers and have no means to collect them. In 2023 they still send out a meaningless paper printed magazine. So not helpful at all but take a significant share of your gross turnover mainly to pay for their pensions. Additionally, with all the regulations the governments set up over years they're now facing a significant cut in civil servants because Germany is getting older and older. As a result they're not having enough people to enforce or check regulations in time and never managed to develop any IT-based systems. Big problem with the influx of refugees in recent years and affects many other concerns as well. Finally, there's this cultural difference to, e.g., the US that average Germans are not business-savy at all. If you tell the average German mom that you want to start a business, she will tell you that you're a dreamer and should get a proper job. Germans generally tend to think that companies are something god-given. [1] They are still the go-to businesses if the gov't quickly needs something, like the Covid tracing app which German tax payers AFAIR ended up paying 120M EUR for (lol).
ilyt 3y ago
No, that's the era of worst, shittiest legacy software to date. The computers were just fast enough to handle layers and layers of extraction and oh boy industry loved to pile them one and UML was just another way to pile up the rot
mytailorisrich 3y ago
The problem is that the expection was to document the software design in excruciating details (e.g. class diagrams with all fields and methods, etc.) before any coding. To the extreme you were meant to all the coding in your head and a Word document before doing it again in your IDE. This wastes a huge amount of time and usually the documents become obsolete as soon as you try to actually run some code. This is the very issue the Agile manifesto identifies and proposes a solution to when it says "working software over comprehensive documentation". 'Comprehensive' is a key word as they don't mean NO documentation but effectively just what's needed to plan and help people understand the code.
qwertywert_ 3y ago
Overdesign is one of the worst things to do. Trying to make something fit perfectly into some obscure pattern with horrible class hierarchies. Look at the linux kernel sources, it does not look "beautiful" to some architects but the actual ideas and patterns are simple, anyone can jump into it if they know C.
rerdavies 3y ago
Ok boomer. :-P Having lived through both, modern development practice is superior in practically every way, most especially with respect to quality. The problem with Heavy Development Methodologies is that they didn't actually work.
- eropple 3y ago
  Don't take this as an endorsement of BDUF practices and the like, they're as fraught as anything, but it's important to also recognize what modern development practices trend hard towards themselves: the trapping of oneself in a local maximum. I have a blog post in the works about this but it's not ready to share; in short, I can't help but notice that hyper-focused, optimize-for-time-to-market, minimum-viable-product projects have a real, and frequently killer, problem once you have built your initial, hopefully-better mousetrap. Almost every company I've ever worked for has gotten that initial mousetrap done, tried to expand horizontally to actually have enough stuff-that-works-together to actually sell, and fallen on their faces because that initial super-specific development effort created not just code, but product assumptions that are prohibitive to unwind. Most of them hit the hillside because reality is no longer playing ball with their (frequently VC-driven) needs to cut scope and ship.
zitterbewegung 3y ago
Sequence diagrams and state machines should be probably taught much better in CS courses. You generally see state machines in a theoretical course and things like sequence diagrams in an object oriented course. What we should do is probably in your advanced data structure programming course that everyone has to take is to create a model of an elevator and diagram the behavior using a sequence diagrams. This would be achieved by using an associative array AKA a map [1] that would represent where the elevator is and what it has to do next (current state and next state based on input). If you program this correctly it gets around using unit testing even because you have diagramed and all parts of the system are known and can just be gone through and that would be a sufficient test. An example of a library that implements this is at https://pypi.org/project/python-statemachine/ https://pypi.org/project/python-statemachine/ [1] https://en.wikipedia.org/wiki/Associative_array https://en.wikipedia.org/wiki/Associative_array
rukuu001 3y ago
I think the industry is diverging. - There's very high-level engineering occurring ('computer science'). I always assumed this would be at places with 'web-scale' problems, but I've been seeing amazing work in local (not-web-scale) product companies here in Australia. - On the other hand, I think a lot of other development work is not much above building flat-pack furniture. I guess this is where lo/no-code solutions will thrive The important thing is to recognise which is being done, and which practices apply each case.
wpietri 3y ago
> In fact, I believe it pretty much killed the profession of software architect. And thank goodness. I am all in favor of more consideration, more quality, more integrity. I like good architecture. But I think it's a giant mistake to create a software architect role. Every company where I saw that in practice, the average architect was a bloviator who did no actual work but was very excited to tell everybody else how to work. At the code level, this resulted in a lot of messes. The edicts and white papers sounded good in theory to the kind of people who decided the bonuses of the architects. But frequently they were unworkable in practice, causing a lot of code that conformed to the theory but was a pain to actually deal with. I agree with you that a lot of things are half-assed and rushed, of course. But we are never going back to a world of 18-36 month release cycles where people could stroke their chins for a quarter or two before building anything. Instead, we need to move in the direction of continually investing in quality, so that the design of systems improves over time. Something that I think is actually easier, in that waterfall design practices locked in important decisions early on, when people knew the least.
deleted 3y ago
[deleted]
anoy8888 3y ago
Apparently, you probably haven't started a real business or created a real successful product . This is what people believe when they are just a cog in the machine and they believe they can spend countless time designing or planning for things that are out of touch with reality
gonzo41 3y ago
I disagree. Software back then used to just fail as often, there was just less of it. Now there's lots of working software, most software sucks and lots of it fails. But the people paying well, and enabling their teams usually get good software at a reasonable price reflecting the complexity. The project management triangle never stopped existing.
lionkor 3y ago
In my short experience this is mostly due to OOP falling out of style, being replaced by a more hybrid approach that combines a lot of functional programming, procedural programming, and OOP - that, together with newer languages providing alternatives for inheritance (traits/concepts), and such, you rarely find yourself needing much more than visitor- and factory pattern.

rr808 3y ago

Now hardware and bandwidth is so cheap now you dont have to care about design so much. Make a service, JSON in JSON out. Some kind of loose versioning but no formal schema and fix it up as it goes.

shinycode 3y ago

So sad and so true

colordrops 3y ago

The pendulum swung, and now we bias towards action rather than design. But to be honest, the "software architect" era wasn't great either, with people in the role sometimes not qualified, spending months on an architecture behind the curtain, releasing some over-verbose spec document that doesn't match the product needs, cargo-culting the latest fad from Martin Fowler.

phs318u 3y ago
Just as well we no longer cargo-cult any practices these days.
- deleted 3y ago
  [deleted]

beyonddream 3y ago

I am curious to know what are these “formalized architectural decision making methodologies” ? Any books that u know of that cover these topics ?

jt2190 3y ago
“Rational Unified Process” https://en.m.wikipedia.org/wiki/Rational_unified_process https://en.m.wikipedia.org/wiki/Rational_unified_process
- beyonddream 3y ago
  Oh this! I suffered learning this during college ;)

mkozlows 3y ago

Yeah, hard disagree on all that. As someone who lived through that era professionally, and who has had an "architect" title in the past, I was actually resistant to ever stepping into that role, because I had so many bad experience with the Formal Architecture Methodology crew, who would produce the most absurd and out-of-touch designs. There's a reason that "architecture astronaut" is a term from that era. Lots of people make bad designs today, sure, but it's not for a lack of formal methodologies, because average design quality was way worse back in the design patterns 'n' UML days.

fmajid 3y ago
Seconded. I once went to an IBM seminar with Grady Booch and seldom have I heard such an inane string of platitudes. Architecture Astronauts are the worst, and if there is one thing Agile can legitimately claim for, it's getting us rid of that plague.
- doctor_eval 3y ago
  I agree with you both except that architects are alive and well. I worked with an ex IBM architect a couple of years ago. Lovely guy but for someone designing software systems, I found it remarkable that he didn’t know how to write code.
  - gedy 3y ago
    I worked for a company not long ago that had leadership which felt you can't be a real architect if you write code. See ya!
  - cogogo 3y ago
    All of these experiences resonate with me. The pendulum has swung hard to the continuous deployment model and just like the other side of the long arc of the pendulum not everything about it is good.
  - snapetom 3y ago
    I'd say this is a company red flag if they are still having these people around. About four years ago I was at a company that still had someone like that. Useless and highfalutin, he obstructed many projects thanks to an archaic director who thought he was still necessary. I got out after butting heads with him constantly, and I don't think said company ever shipped anything meaningful in his entire tenure here.

peanut-walrus 3y ago

Software architects, much like real architects, often end up with absolutely beautiful elegant designs which are unfit for purpose and have leaky roofs.

bluGill 3y ago
And other architects make buildings/software that gets done on time because unlike babies adding people can make things go faster (it is always sub linear, but good architecture can get close to linear, while bad can go negative slope)

doctor_eval 3y ago

I don’t think this is any more true than it ever was. If anything, the rise of open source libraries, GitHub and friends has made it easier than ever to reuse software and avoid NIH. This has lead to a different set of problems, but relative to when I was writing C in the 90s I’d say software reuse and design is far advanced from those days. I do however agree that design is sorely missing from the current software project management zeitgeist, which means it’s done in a more ad hoc way. People are taking frameworks like Scrum far too literally, and I agree that in some cases there is little vision or overall architecture because the framework doesn’t include these things. There should be design and review activities both before and after coding, but these are largely neglected from most project management frameworks. Scrum for example doesn’t even include backlog management, which in my work is a critical activity. While that doesn’t mean design, architecture and scope management is not done, it’s certainly less visible than it might be. All of that said, I’m a big believer that the ultimate expression of any design is code. The design artefacts that come before code is written are scaffolding, age quickly, and are soon useless. So there’s not much need to keep them around, and they are mostly of interest as preliminary directions. In this regard I’m a big fan of Jack Reeves essays from the same period at https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...

_proofs 3y ago

while i feel as if i largely understand what you're pointing out, i kinda want to offer my own speculation as a SWE who is very guilty in thinking in terms of sequence diagrams (and also more formal UML) -- sometimes UML is so fucking bogged down with (impl) details, i am just over here going "i don't give a shit about the (impl) details, i just want to know the abstract concept(s), and logical flows, and focus on necessary system interactions" -- bc i can (and should at this stage) worry about (impl) details later. i prefer to reason about a system and component relationships using, say, a single word as representation, instead of glaring at one or many inheritance directionals, interface details, and other "field" information, which is usually conveyed in a UML node. i do not think the lack of formalism is a degradation -- we work with abstractions after-all, so it makes sense to further leverage that fact and express things simply, at a high-level, and straight-forwardly -- you can pack a lot into a single word. of course as the nature of any tool, there is a time and a place for its application. but i don't think it is fair to call it a degradation.

DSMan195276 3y ago
I've noticed the "over-detailed" problem a lot at my company that has dedicated "software architect" roles. IMO part of the issue is that most of them do not write any code anymore, but 'architecture' alone just doesn't have a full-time job's worth of stuff to do (or they're bad about finding it). The 'solution' they end up on is just treating UML like code and specifying exactly how they would have written the whole thing - which is a huge waste of time when they could have just been writing real code.

lainga 3y ago

Has anything replaced UML? I mean, if there are teams out there that aren't shunning design, what do they use to create architecture diagrams?

doctor_eval 3y ago
I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases. I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation. I’m also not afraid to use stuff that’s out of fashion. I use simplified ER diagrams, and even flow charts on occasion. But the tool I use most often in design is SQL DDL… I have also used Mermaid (using a modified Docsy theme in Hugo) and it is also great. Using Typora to edit Mermaid is also excellent.
- ozim 3y ago
  I like use case diagrams as well. Thing is these should be short lived and used to make specific illustration in specific time. Not some holy grail of documentation that people should take as some god given truth for whole life of the system.
  - doctor_eval 3y ago
    Yeah, I posted elsewhere in this thread that I'm a big fan of Jack Reeves' essays on "code as design"; namely, that the code is what's important, and the design is just scaffolding. "The following essays by Jack W. Reeves offer three perspectives on a single theme, namely that programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself. This simple assertion gives rise to a rich discussion—one which Reeves explores fully in these three essays." https://www.developerdotstar.com/mag/articles/reeves_design_main.html https://www.developerdotstar.com/mag/articles/reeves_design_...
  - macdaknife 3y ago

opportune 3y ago

That’s because software architecture is something any senior employee should be able to do, and it’s not as important as people thought. Like many abandoned corporate practices, I think it was abandoned for good reason. It may have made sense under different circumstances, like when you had a large army of cheap offshore devs who could not be trusted to architect a maintainable application. If I had some ivory tower “architect” trying to interfere with my work I’d be so pissed. Anybody I’ve seen with that title, that wasn’t doing 1P cloud consulting where the title means something different, usually had no clue what they were doing and had been given the title as a soft retirement.

eropple 3y ago
As much as I do think that software architecture does matter (though it should probably be somebody with a staff or principal hat, not a specific job title) I recently took a job at a place that really does like architect titles. Mine's even "lead architect". It is pretty funny when somebody runs into me and realizes for the first time that I have the job because I build stuff and write code, not because I'm good at LucidChart. I'm planning things out beyond immediate needs, but not because I'm looking for job security--it's because I've built the thing we're doing before and would like to not make the same mistakes I've made in the past. I'm over here demanding adequate standards of code and low- to mid-level design, and the "wait he's serious?" of it is sometimes honestly pretty fun to run up against. I am good at LucidChart though.
- opportune 3y ago
  Yeah, I guess I would in retrospect refine my opinion to “software architecture is iterable and not completely separable from implementation” or that “architecture (as imagined by distinct architects who are shielded from implementation concerns) is not important”. Principal engineers and such who are still involved in operations, implementation, and more tactical approaches are who I also think are “supposed” to be doing architecture, but even then, more as guides and first among equals than as people who hand down decisions from on-high. The fundamental issue I have with a separate architect position is that it disempowers teams and makes them beholden to decisions that they may not agree with (and which very well may not understand the problem to the extent they do). It sounds like you’re doing the better thing of running up and down the layers of abstraction so your contributions empower people rather than disempower them

lmm 3y ago

We stopped doing that stuff because it was useless. We eliminated those practices and that profession because it was actively harmful to making good software. All those decision making methodologies consistently lead to worse technology choices than one dude actually trying to write some code with the thing for half an hour.

icedchai 3y ago
UML is mostly useless, but thinking ahead, even a bit, has value. I've seen stuff shipped in a sprint that was not used by any actual end users, only to be "redone" in the next sprint.
- lmm 3y ago
  My experience is that shipping stuff that doesn't get used by any actual end users is more often caused by thinking ahead too much than by thinking ahead too little.
  - icedchai 3y ago
    I've actually seen it both ways: whole features (or even products) that were too early. But on the implementation level, I've seen someone pick the wrong thing (library, database, whatever) "because it was simple", only to have it be thrown out before getting any real usage.
    - kubanczyk 3y ago
      "Pick the wrong thing and then retract, losing some work" is as close to optimal as you can get. Iterate. The much worse outcome is "pick a thing, fiercely defend it whether it helps the ship to float or to sink".
      - icedchai 3y ago
        I agree that outcome is worse. However, both extremes are bad. The optimal approach would be to do a little bit more work upfront, pick a "better" thing (where "better" is at least more than the next sprint or 3!), and use that.

cptskippy 3y ago

The problem you're describing Exists in all engineering disciplines. You don't hire firm to feasibility studies, develop a design plan, do a materials bid, sub contract clearing and construction for your mailbox installation do you? Most people hire a dude hanging out at Home Depot and pay him a flat fee. The risk and complexity dictate how much architecture and engineering are involved and with all things, businesses will try to get by with a bare minimum. The automotive, chemical, and other industrial sectors invest a lot in software architecture and enterprise architecture because the risk is so high. But even a medium size e-commerce platform has very low risk or complexity.

jrochkind1 3y ago

> And they'd know the classics, like memorizing all design patterns. That sentence is bringing back ptsd-like flashbacks. I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing. I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The phrase "architecture astronaut" was a common epithet, and not a friendly one] That above paragraph [without the brackets], ironically, could certainly be said of "agile" more recently too. I don't know how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. But yeah, I'm pretty convinced going back to appointing some almighty deity architecture astronaut who isn't responsible for or involved in any implementation (let alone operations!), who hands down plans from on high after "memorizing all design patterns" and drafting some diagrams, never sullied by "contact with the enemy"... no thank you, but thank you. ---- Instead of just complaining about that though, what I'll say in addition is -- I think the real problem is that engineers aren't given the time to carefully consider top-level designs. it's a basic business/resource issue -- until engineers have more breathing room to talk to each other and research and consider and come to decisions in an unhurried way, the top-level design stuff will remain chaotic. It's not an issue of appointing an ivory tower "architect", or something solved by it. Although sure, there should be senior and even "staff" or "principal" people with more authority/responsibility for higher-level designs. Everyone should be responsible for design at the level they are working. Everyone needs enough time to feel like they are doing it well, instead of running on a sweatshop code production treadmill.

jrumbut 3y ago
To be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries. If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new things that would have taken too long to do before. And that was the intent of the Gang of Four book, not to teach you patterns you should copy mindlessly, but to give examples of how to identify and extract useful patterns from the software you've already written and describe them to others. Since that is a lot more difficult than memorization, very few took up that work.

yafbum 3y ago

We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.

ilyt 3y ago
And they just shipped garbage in longer cycles... as anyone that had to deal with such designed legacy apps can confirm.
RachelF 3y ago
In truth it depends on the software. For web or phone or desktop apps which can be upgraded on the fly, short cycles are ok. On the other hand, Boeing's crappy software practices resulting in the 737-MAX crashes are an area where short-cuts killed people.
- phs318u 3y ago
  So much this. Coding to marketing dictums on the cycle of days/weeks is completely NOTHING like engineering solutions where subtle design issues can make the difference between life and death (or IRL super good thing A and IRL super bad thing B).
klabb3 3y ago
> The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run The same market that gave us AT&T, Comcast, DRMed IoT Juice presses, FTX, Enron, and so on? Not sure it’s wise to conclude that the market produces optimal solutions, or even incrementally better solutions than yesterday. Especially in domains with extremely long feedback cycles, like organizational trends. I DO think there is some hocus pocus market zeitgeist that does something resembling gradient descent, but it’s acting over very long cycles and there’s a ton of room for cargo culting, grifting, and opportunistic grabs along the way. Heck, marketing is an entire field dedicated to affecting “rational actors” in the marketplace.

maximinus_thrax 3y ago

> Everybody is half-assing design or skipping it entirely. Solutions are reinvented and tech choices made on a whim by the loudest person whom won't see the consequences of it anyway. Because we've told ourselves that shipping garbage in short cycles is the one and only way to do things. I agree. I don't personally fetishize the old slow processes nor ivory tower architectures, but I think there's a healthy spectrum between that and the complete 'software fuckery' (https://web.archive.org/web/20160308032127/https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877 https://web.archive.org/web/20160308032127/https://medium.co...)

hejcloud 3y ago

German speaking. You can take German IT to get an idea what would have happened to SWE if you'd have kept those bureaucratic methods from the 2000s as the backbone of all SWE endeavors: a horrible, expensive, non-working mess with barely any progress. I think what many people, esp. from outside the SWE world, don't get: Software engineering is a deeply social kind of work. There are dozens of solutions for the given problems, you have to agree on one that works for all peers. That's the job. Optimizing it for drawing funny diagrams is not an issue if not for communication.

_dain_ 3y ago
I'm not familiar with how IT works in Germany. What's different about it? Got any stories?
- userbinator 3y ago
  One word: SAP.
  - artyom 3y ago
    Oh no. I'm so sorry.
devin 3y ago
I'm also interested in the german software engineering culture. And also, heavy plus to this being a social problem more than a "engineers just need more time" problem. I tried to articulate this in another comment of mine but mostly beat around the bush. This is more directly what I was attempting to say.
- hejcloud 3y ago
  Well in my theory core reason is that Germany never developed a thriving startup IT economy[0] that was ever relevant for the GDP, especially not in comparison with the industrial sectors (cars, steel, chemistry) and so IT completely got ignored by politicians. That resulted in no one who'd challenge the biggest gatekeepers Telekom and SAP, so they lobbied for and enforced whatever they wanted[1]. If you study CS in a German university you can easily get an MA without being able to write software at all (I personally happen to know several people). German universities teach what is easy to teach top down and test for: The textbook stuff that came out of the whole Java EE/OOP/SOAP/UML sector. You barely get practical coding lessons and can avoid them completely if you want. The academic sector never realized how crappy German software products are and never bothered looking at what Big Tech is doing. With given data protection and soon AI regulations, as a university you'd have a hard time collecting enough training data because your law department would step in referring to the current legal insecurity (I've heard stories from friends). Then we have this little crazy island Berlin which up until maybe 10ys ago was mainly driven by the infamous Rocket Internet "startup incubator" which is led by a couple of MBA sociopath billionaires, trying to copycat everything from SV and then sell it back to the SV company whenever they wanted to start conquering Europe. Thing is they never really developed enough SWE excellence to get the copycat successful in Germany or anywhere in Europe (with some exceptions). Third example? Here you are: Today I learned that the gov't already decided 20ys ago that they want to provide all usual governmental services online. 20ys later they (allegedly) poured 3.5Bn EUR into an unholy setup of consulting businesses, incompetent civil servants and a panel of software architect astronauts who could never really agree on things. All their deliverables are click-dummies, gazillions of PDFs with SOAP/WSDL/OMG/UML thingies and prototype projects rolled out in "experimental" cities. So if you happen to live in Bremen you might be able to register your dog online but not in Berlin. Therefore in Berlin you might be able to get a license plate for your car online. Pretty much all governmental projects (Covid vaccination registration, special governmental aid for students because of high inflation, etc.) broke down because all their systems are incapable of handling more than maybe 10k visitors (in my theory it always breaks down whenever the biggest single Oracle DB host they could buy is going down). Germany has some decent software engineers, especially if they're self-trained and not brainwashed by one of the universities or big corps. But the environment manages to regularly piss them off and make em emigrate to somewhere else. Ouff, much text. Hope at least someone enjoys reading it. --- [0] This is because if you start a company in Germany you're faced with horrible bureaucracy wrt taxes, laws, politics, governmental authorities, etc. For example, you're forced to pay for a membership in a funny non-IT institution called "Industrie- und Handelskammer (IHK)" which essentially consists of a crowd of old men who are officially supposed to lobby for you and create a networking environment but if you ask them something like "hey, can you tell me how many companies are having problem XYZ right now?" they will tell you that they don't have any numbers and have no means to collect them. In 2023 they still send out a meaningless paper printed magazine. So not helpful at all but take a significant share of your gross turnover mainly to pay for their pensions. Additionally, with all the regulations the governments set up over years they're now facing a significant cut in civil servants because Germany is getting older and older. As a result they're not having enough people to enforce or check regulations in time and never managed to develop any IT-based systems. Big problem with the influx of refugees in recent years and affects many other concerns as well. Finally, there's this cultural difference to, e.g., the US that average Germans are not business-savy at all. If you tell the average German mom that you want to start a business, she will tell you that you're a dreamer and should get a proper job. Germans generally tend to think that companies are something god-given. [1] They are still the go-to businesses if the gov't quickly needs something, like the Covid tracing app which German tax payers AFAIR ended up paying 120M EUR for (lol).

ilyt 3y ago

No, that's the era of worst, shittiest legacy software to date. The computers were just fast enough to handle layers and layers of extraction and oh boy industry loved to pile them one and UML was just another way to pile up the rot

mytailorisrich 3y ago

The problem is that the expection was to document the software design in excruciating details (e.g. class diagrams with all fields and methods, etc.) before any coding. To the extreme you were meant to all the coding in your head and a Word document before doing it again in your IDE. This wastes a huge amount of time and usually the documents become obsolete as soon as you try to actually run some code. This is the very issue the Agile manifesto identifies and proposes a solution to when it says "working software over comprehensive documentation". 'Comprehensive' is a key word as they don't mean NO documentation but effectively just what's needed to plan and help people understand the code.

qwertywert_ 3y ago

Overdesign is one of the worst things to do. Trying to make something fit perfectly into some obscure pattern with horrible class hierarchies. Look at the linux kernel sources, it does not look "beautiful" to some architects but the actual ideas and patterns are simple, anyone can jump into it if they know C.

rerdavies 3y ago

Ok boomer. :-P Having lived through both, modern development practice is superior in practically every way, most especially with respect to quality. The problem with Heavy Development Methodologies is that they didn't actually work.

eropple 3y ago
Don't take this as an endorsement of BDUF practices and the like, they're as fraught as anything, but it's important to also recognize what modern development practices trend hard towards themselves: the trapping of oneself in a local maximum. I have a blog post in the works about this but it's not ready to share; in short, I can't help but notice that hyper-focused, optimize-for-time-to-market, minimum-viable-product projects have a real, and frequently killer, problem once you have built your initial, hopefully-better mousetrap. Almost every company I've ever worked for has gotten that initial mousetrap done, tried to expand horizontally to actually have enough stuff-that-works-together to actually sell, and fallen on their faces because that initial super-specific development effort created not just code, but product assumptions that are prohibitive to unwind. Most of them hit the hillside because reality is no longer playing ball with their (frequently VC-driven) needs to cut scope and ship.

zitterbewegung 3y ago

Sequence diagrams and state machines should be probably taught much better in CS courses. You generally see state machines in a theoretical course and things like sequence diagrams in an object oriented course. What we should do is probably in your advanced data structure programming course that everyone has to take is to create a model of an elevator and diagram the behavior using a sequence diagrams. This would be achieved by using an associative array AKA a map [1] that would represent where the elevator is and what it has to do next (current state and next state based on input). If you program this correctly it gets around using unit testing even because you have diagramed and all parts of the system are known and can just be gone through and that would be a sufficient test. An example of a library that implements this is at https://pypi.org/project/python-statemachine/ https://pypi.org/project/python-statemachine/ [1] https://en.wikipedia.org/wiki/Associative_array https://en.wikipedia.org/wiki/Associative_array

rukuu001 3y ago

I think the industry is diverging. - There's very high-level engineering occurring ('computer science'). I always assumed this would be at places with 'web-scale' problems, but I've been seeing amazing work in local (not-web-scale) product companies here in Australia. - On the other hand, I think a lot of other development work is not much above building flat-pack furniture. I guess this is where lo/no-code solutions will thrive The important thing is to recognise which is being done, and which practices apply each case.

wpietri 3y ago

> In fact, I believe it pretty much killed the profession of software architect. And thank goodness. I am all in favor of more consideration, more quality, more integrity. I like good architecture. But I think it's a giant mistake to create a software architect role. Every company where I saw that in practice, the average architect was a bloviator who did no actual work but was very excited to tell everybody else how to work. At the code level, this resulted in a lot of messes. The edicts and white papers sounded good in theory to the kind of people who decided the bonuses of the architects. But frequently they were unworkable in practice, causing a lot of code that conformed to the theory but was a pain to actually deal with. I agree with you that a lot of things are half-assed and rushed, of course. But we are never going back to a world of 18-36 month release cycles where people could stroke their chins for a quarter or two before building anything. Instead, we need to move in the direction of continually investing in quality, so that the design of systems improves over time. Something that I think is actually easier, in that waterfall design practices locked in important decisions early on, when people knew the least.

deleted 3y ago

[deleted]

anoy8888 3y ago

Apparently, you probably haven't started a real business or created a real successful product . This is what people believe when they are just a cog in the machine and they believe they can spend countless time designing or planning for things that are out of touch with reality

gonzo41 3y ago

I disagree. Software back then used to just fail as often, there was just less of it. Now there's lots of working software, most software sucks and lots of it fails. But the people paying well, and enabling their teams usually get good software at a reasonable price reflecting the complexity. The project management triangle never stopped existing.

lionkor 3y ago

In my short experience this is mostly due to OOP falling out of style, being replaced by a more hybrid approach that combines a lot of functional programming, procedural programming, and OOP - that, together with newer languages providing alternatives for inheritance (traits/concepts), and such, you rarely find yourself needing much more than visitor- and factory pattern.