8 ms·

Published in 2010? Curious how much of it has survived since then? I like “Design It” because of some of the workshop/activities that are nice for technical fo

by pbnjay 2y ago

Published in 2010? Curious how much of it has survived since then? I like “Design It” because of some of the workshop/activities that are nice for technical folks who need to interact with stakeholders/clients (I’m in a consulting role so this is more relevant). Also it doesn’t lean hard on specific technical architectural styles which change so frequently…

zeroCalories 2y ago
Process at my work is heavily influenced by this book, and I think it gives a pretty good overview of architecture and development processes. Author spends a lot of time in prose talking about mindset, and it's light on concrete skills, but it does provide references for further reading.
jeremyjh 2y ago
I can't think of many things that have changed in architecture since 2010. I'm not talking about fads but about actual principles.
- CuriouslyC 2y ago
  Things are changing now, pretty fast. The architecture that is optimal for humans is not the same architecture that is optimal for AI. AI wants shallow monoliths built around function composition using a library of helper modules and simple services with dependency injection.
  - wizzwizz4 2y ago
    > I'm not talking about fads but about actual principles. Most problems are not well-addressed by shallow monoliths made of glue code. It's irrelevant what "AI wants", just as it's irrelevant what blockchain "wants".
    - CuriouslyC 2y ago
      If you think development velocity doesn't matter, you should talk to the people who employ you.
      - loup-vaillant 2y ago
        If you think AI helps speed up development…
        wizzwizz4 2y ago
        AI does help speed up development! It lets you completely skip the "begin to understand the requirements" and "work out what's sensible to build" steps, and you can get through the "type out some code" parts even faster than copy-pasting from Stack Overflow (at only 10× the resource expenditure, if we ignore training costs!). It does make the last step ("have a piece of software that's fit-for-purpose") a bit harder; but that's a price you should be willing to pay for velocity.
        water-your-self 2y ago
        Velocity is good for impact, typically.
        deleted 2y ago
        [deleted]
        jeffreygoesto 2y ago
        Poor code monkeys. I am in a industry where software bugs can severely harm people since over 20 years and the fastest code never survived. It always only solved some cheap and easy 70% of the job and the remaining errors almost killed the project and everything had to be reworked peoperly. Slow is smooth and smooth is fast. "Fast" code costs you four times: write it, discuss why it is broken, remove it, rewrite it.
        CuriouslyC 2y ago
        I don't have to think, people have done research.
    - cqqxo4zV46cp 2y ago
      This response is entirely tribalist and ignores the differences between LLMs and ‘blockchain’ as actual technologies. To be blunt, I find it hard to professionally respect anyone that buys into these culture wars to the point where it completely overtakes their ability to objectively evaluate technologies. This isn’t me saying that anyone that has written off LLMs is an idiot. But to equate these two technologies in this context makes absolutely no sense to me just from a logical perspective. I.e. not involving a value judgment toward either blockchain or LLMs. The only reason you’re invoking blockchain here is because the blockchain and LLM fads are often compared / equated in these conversations. Nobody has suggested that blockchain technology be used to assist with the development of software in the way that LLMs are. It simply doesn’t make sense. These are two entirely separate technologies setting out to solve two entirely orthogonal problems. The argument is completely nonsensical.
      - wizzwizz4 2y ago
        > Nobody has suggested that blockchain technology be used to assist with the development of software in the way that LLMs are. It simply doesn’t make sense. Linus Torvalds is a strong advocate. He even wrote a blockchain-based source code management system, which he dubbed “the information manager from hell”[0], spending over three months on it (six months, by his own account) before handing it over to others to maintain. People complain that this “information manager” system is hard to understand, but it's actively used (alongside email) for coordinating the Linux kernel project. Some say it's crucial to Linux's continued success, or even that it's more important than Linux. [0]: see commit e83c5163316f89bfbde7d9ab23ca2e25604af290
      - wizzwizz4 2y ago
        (A less snarky reply:) LLMs and blockchains are both special-purpose tools that are almost completely useless for their best-known applications (virtual-assistants and cryptocurrency, respectively). The social behaviour surrounding them is way more relevant than the actual technologies, and I don't think it's tribalistic to acknowledge that. People tried to use both as databases, put both in cars, invest in both. The vast majority of claims people make about them are just not evidenced, yet their hypist-adherents are so confident that they're willing to show you evidence that contradicts their claims, and call it "proof". Yes, the actual technologies are very different. But nobody is actually paying attention to the technologies (an ignorance that my other comment snarkily accuses you of displaying here – I probably should've been kinder).
  - rednafi 2y ago
    This whole part sounds like BS mumbo jumbo. AI isn’t developing any system anytime soon and people surely aren’t going to design systems that cater to the current versions of LLMs.
    - dcow 2y ago
      Have you heard of modular, mojo, and max?
      - viraptor 2y ago
        They're designed for fast math and python similarity in general. Llama.cpp on the other hand is designed for LLM as we use it right now. But Mojo is general purpose enough to support many other "fast Python" use cases and if we completely change the architecture of LLMs, it's still going to be great for them. It's more of a generic system with attention on performance of specific application rather than a system designed to cater to current LLMs.
        dcow 2y ago
        No. Max is an entire compute platform designed around deploying LLMs at scale. And Mojo takes a Python syntax (it’s a superset) but reimplements the entire compiler so you (or the compiler on your behalf) can target all the new AI compute hardware that’s almost literally popped up overnight. Modular is the company that raised 130MM dollars in under 2 years to make these two plays happen. And Nvidia is on fire right now. I can assure you without a sliver of a doubt that humans are most certainly redesigning entire computing hardware and the systems atop to accommodate AI. Look at the WWDC Keynote this year if you need more evidence.
        viraptor 2y ago
        Sure it's made to accommodate AI or more generally fast vector/matrix math. But the original claim was about "people surely aren’t going to design systems that cater to the current versions of LLMs." Those solutions are way more generic than current or future versions of LLMs. Once LLMs die down a bit, the same setups will be used for large scale ML/research unrelated to languages.
  - ysofunny 2y ago
    AI wanted you to write code in GoLang so that it could absorb your skills more faster. kthanksbai
  - wolfgang42 2y ago
    I don’t know about this architecture for AI, but your description sounds like the explanations I’ve heard of the Ruby on Rails philosophy, which is clearly considered optimal by at least some humans.
  - afro88 2y ago
    Maybe this post wasn't the right one for your comment, hence the downvotes. But I find it intriguing. Do you mean architecting software to allow LLMs to be able to modify and extend it? Having more of the overall picture in one place (shallow monoliths) and lots of helper funtions and modules to keep code length down? Ie, optimising for the input and output context windows?
    - CuriouslyC 2y ago
      LLMs are very good at first order coding. So, writing a function, either from scratch or by composing functions given their names/definitions. When you start to ask it to do second or higher order coding (crossing service boundaries, deep code structures, recursive functions) it falls over pretty hard. Additionally, you have to consider the time it takes an engineer to populate the context when using the LLM and the time it takes them to verify the output. LLMs can unlock incredibly development velocity. For things like creating utility or helper functions and their unit tests at the same time, an engineer using a LLM will easily 10x an equally skilled engineer not using a LLM. The key is to architect your system so that as much of it as possible can be treated this way, while not making it indecipherable for humans.
      - hollerith 2y ago
        >while not making it indecipherable for humans This is a temporary constraint. Soon the maintenance programmers will use an AI to tell them what the code says. The AI might not reliably be able to do that unless it is in the same "family" of AIs that wrote the code. In other words, analogous to the situation today where choice of programming language has strategic consequences, choice of AI "family" with which to start a project will tend to have strategic consequences.
  - jerf 2y ago
    Nobody has ten years of experience with a code base "optimized for AI" to be able to state such a thing so confidently. And nobody ever will, because in 10 years, coding AIs will not look like they do now. Right now they are just incapable of architecture, which your supposed optimal approach seems to be optimizing for, but I wouldn't care to guarantee that's the case in 10 years. If nothing else, there will certainly be other relevant changes. And you'll need experience to determine how best to use those, unless they just get so good they take care of that too.
- pbnjay 2y ago
  I mean shared hosting certainly existed but "the cloud" as we think of it today was much simpler and not nearly as ubiquitous. It doesn't really change the principles themselves but it certainly affects aspects of the risk calculus that dominates the table of contents.
- zmmmmm 2y ago
  probably containerisation is a big one, and also serverless computing they aren't principles as such, but they certainly play into what is important and how you apply them
- kqr 2y ago
  Since 1970, to be fair... The people at the NATO Software Engineering conferences of '68 and '69 knew quite a bit about architecture. Parnas, my house-god in the area, published his best stuff in the 1970s.
gfairbanks 2y ago
Keeling's Design It book is great [1]. It helps teams engage with architecture ideas with concrete activities that end up illuminating what's important. My book tries to address those big ideas head-on, which turns out to be difficult, pedagogically, because it's such an abstract topic. Which ideas have survived since 2010? Some operating systems are microkernels, others are monolithic. Some databases are relational, others are document-centric. Some applications are client-server, others are peer-to-peer. These distinctions are probably eternal and if you come back in 100 years you may find systems with those designs even though Windows, Oracle, and Salesforce are long-gone examples. And we'll still be talking about qualities like modifiability and latency. The field of software architecture is about identifying these eternal abstractions. See [2] for a compact description. "ABSTRACT: Software architecture is a set of abstractions that helps you reason about the software you plan to build, or have already built. Our field has had small abstractions for a long time now, but it has taken decades to accumulate larger abstractions, including quality attributes, information hiding, components and connectors, multiple views, and architectural styles. When we design systems, we weave these abstractions together, preserving a chain of intentionality, so that the systems we design do what we want. Twenty years ago, in this magazine, Martin Fowler published the influential essay “Who Needs an Architect?” It’s time for developers to take another look at software architecture and see it as a set of abstractions that helps them reason about software." [1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/ https://pragprog.com/titles/mkdsa/design-it/ [2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1OAJv5H4jew https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...

by pbnjay 2y ago

zeroCalories 2y ago

Process at my work is heavily influenced by this book, and I think it gives a pretty good overview of architecture and development processes. Author spends a lot of time in prose talking about mindset, and it's light on concrete skills, but it does provide references for further reading.

jeremyjh 2y ago

I can't think of many things that have changed in architecture since 2010. I'm not talking about fads but about actual principles.

CuriouslyC 2y ago
Things are changing now, pretty fast. The architecture that is optimal for humans is not the same architecture that is optimal for AI. AI wants shallow monoliths built around function composition using a library of helper modules and simple services with dependency injection.
- wizzwizz4 2y ago
  > I'm not talking about fads but about actual principles. Most problems are not well-addressed by shallow monoliths made of glue code. It's irrelevant what "AI wants", just as it's irrelevant what blockchain "wants".
  - CuriouslyC 2y ago
    If you think development velocity doesn't matter, you should talk to the people who employ you.
    - loup-vaillant 2y ago
      If you think AI helps speed up development…
      - wizzwizz4 2y ago
        AI does help speed up development! It lets you completely skip the "begin to understand the requirements" and "work out what's sensible to build" steps, and you can get through the "type out some code" parts even faster than copy-pasting from Stack Overflow (at only 10× the resource expenditure, if we ignore training costs!). It does make the last step ("have a piece of software that's fit-for-purpose") a bit harder; but that's a price you should be willing to pay for velocity.
        water-your-self 2y ago
        Velocity is good for impact, typically.
        deleted 2y ago
        [deleted]
        jeffreygoesto 2y ago
        Poor code monkeys. I am in a industry where software bugs can severely harm people since over 20 years and the fastest code never survived. It always only solved some cheap and easy 70% of the job and the remaining errors almost killed the project and everything had to be reworked peoperly. Slow is smooth and smooth is fast. "Fast" code costs you four times: write it, discuss why it is broken, remove it, rewrite it.
      - CuriouslyC 2y ago
        I don't have to think, people have done research.
  - cqqxo4zV46cp 2y ago
    This response is entirely tribalist and ignores the differences between LLMs and ‘blockchain’ as actual technologies. To be blunt, I find it hard to professionally respect anyone that buys into these culture wars to the point where it completely overtakes their ability to objectively evaluate technologies. This isn’t me saying that anyone that has written off LLMs is an idiot. But to equate these two technologies in this context makes absolutely no sense to me just from a logical perspective. I.e. not involving a value judgment toward either blockchain or LLMs. The only reason you’re invoking blockchain here is because the blockchain and LLM fads are often compared / equated in these conversations. Nobody has suggested that blockchain technology be used to assist with the development of software in the way that LLMs are. It simply doesn’t make sense. These are two entirely separate technologies setting out to solve two entirely orthogonal problems. The argument is completely nonsensical.
    - wizzwizz4 2y ago
      > Nobody has suggested that blockchain technology be used to assist with the development of software in the way that LLMs are. It simply doesn’t make sense. Linus Torvalds is a strong advocate. He even wrote a blockchain-based source code management system, which he dubbed “the information manager from hell”[0], spending over three months on it (six months, by his own account) before handing it over to others to maintain. People complain that this “information manager” system is hard to understand, but it's actively used (alongside email) for coordinating the Linux kernel project. Some say it's crucial to Linux's continued success, or even that it's more important than Linux. [0]: see commit e83c5163316f89bfbde7d9ab23ca2e25604af290
    - wizzwizz4 2y ago
      (A less snarky reply:) LLMs and blockchains are both special-purpose tools that are almost completely useless for their best-known applications (virtual-assistants and cryptocurrency, respectively). The social behaviour surrounding them is way more relevant than the actual technologies, and I don't think it's tribalistic to acknowledge that. People tried to use both as databases, put both in cars, invest in both. The vast majority of claims people make about them are just not evidenced, yet their hypist-adherents are so confident that they're willing to show you evidence that contradicts their claims, and call it "proof". Yes, the actual technologies are very different. But nobody is actually paying attention to the technologies (an ignorance that my other comment snarkily accuses you of displaying here – I probably should've been kinder).
- rednafi 2y ago
  This whole part sounds like BS mumbo jumbo. AI isn’t developing any system anytime soon and people surely aren’t going to design systems that cater to the current versions of LLMs.
  - dcow 2y ago
    Have you heard of modular, mojo, and max?
    - viraptor 2y ago
      They're designed for fast math and python similarity in general. Llama.cpp on the other hand is designed for LLM as we use it right now. But Mojo is general purpose enough to support many other "fast Python" use cases and if we completely change the architecture of LLMs, it's still going to be great for them. It's more of a generic system with attention on performance of specific application rather than a system designed to cater to current LLMs.
      - dcow 2y ago
        No. Max is an entire compute platform designed around deploying LLMs at scale. And Mojo takes a Python syntax (it’s a superset) but reimplements the entire compiler so you (or the compiler on your behalf) can target all the new AI compute hardware that’s almost literally popped up overnight. Modular is the company that raised 130MM dollars in under 2 years to make these two plays happen. And Nvidia is on fire right now. I can assure you without a sliver of a doubt that humans are most certainly redesigning entire computing hardware and the systems atop to accommodate AI. Look at the WWDC Keynote this year if you need more evidence.
        viraptor 2y ago
        Sure it's made to accommodate AI or more generally fast vector/matrix math. But the original claim was about "people surely aren’t going to design systems that cater to the current versions of LLMs." Those solutions are way more generic than current or future versions of LLMs. Once LLMs die down a bit, the same setups will be used for large scale ML/research unrelated to languages.
- ysofunny 2y ago
  AI wanted you to write code in GoLang so that it could absorb your skills more faster. kthanksbai
- wolfgang42 2y ago
  I don’t know about this architecture for AI, but your description sounds like the explanations I’ve heard of the Ruby on Rails philosophy, which is clearly considered optimal by at least some humans.
- afro88 2y ago
  Maybe this post wasn't the right one for your comment, hence the downvotes. But I find it intriguing. Do you mean architecting software to allow LLMs to be able to modify and extend it? Having more of the overall picture in one place (shallow monoliths) and lots of helper funtions and modules to keep code length down? Ie, optimising for the input and output context windows?
  - CuriouslyC 2y ago
    LLMs are very good at first order coding. So, writing a function, either from scratch or by composing functions given their names/definitions. When you start to ask it to do second or higher order coding (crossing service boundaries, deep code structures, recursive functions) it falls over pretty hard. Additionally, you have to consider the time it takes an engineer to populate the context when using the LLM and the time it takes them to verify the output. LLMs can unlock incredibly development velocity. For things like creating utility or helper functions and their unit tests at the same time, an engineer using a LLM will easily 10x an equally skilled engineer not using a LLM. The key is to architect your system so that as much of it as possible can be treated this way, while not making it indecipherable for humans.
    - hollerith 2y ago
      >while not making it indecipherable for humans This is a temporary constraint. Soon the maintenance programmers will use an AI to tell them what the code says. The AI might not reliably be able to do that unless it is in the same "family" of AIs that wrote the code. In other words, analogous to the situation today where choice of programming language has strategic consequences, choice of AI "family" with which to start a project will tend to have strategic consequences.
- jerf 2y ago
  Nobody has ten years of experience with a code base "optimized for AI" to be able to state such a thing so confidently. And nobody ever will, because in 10 years, coding AIs will not look like they do now. Right now they are just incapable of architecture, which your supposed optimal approach seems to be optimizing for, but I wouldn't care to guarantee that's the case in 10 years. If nothing else, there will certainly be other relevant changes. And you'll need experience to determine how best to use those, unless they just get so good they take care of that too.
pbnjay 2y ago
I mean shared hosting certainly existed but "the cloud" as we think of it today was much simpler and not nearly as ubiquitous. It doesn't really change the principles themselves but it certainly affects aspects of the risk calculus that dominates the table of contents.
zmmmmm 2y ago
probably containerisation is a big one, and also serverless computing they aren't principles as such, but they certainly play into what is important and how you apply them
kqr 2y ago
Since 1970, to be fair... The people at the NATO Software Engineering conferences of '68 and '69 knew quite a bit about architecture. Parnas, my house-god in the area, published his best stuff in the 1970s.

gfairbanks 2y ago

Keeling's Design It book is great [1]. It helps teams engage with architecture ideas with concrete activities that end up illuminating what's important. My book tries to address those big ideas head-on, which turns out to be difficult, pedagogically, because it's such an abstract topic. Which ideas have survived since 2010? Some operating systems are microkernels, others are monolithic. Some databases are relational, others are document-centric. Some applications are client-server, others are peer-to-peer. These distinctions are probably eternal and if you come back in 100 years you may find systems with those designs even though Windows, Oracle, and Salesforce are long-gone examples. And we'll still be talking about qualities like modifiability and latency. The field of software architecture is about identifying these eternal abstractions. See [2] for a compact description. "ABSTRACT: Software architecture is a set of abstractions that helps you reason about the software you plan to build, or have already built. Our field has had small abstractions for a long time now, but it has taken decades to accumulate larger abstractions, including quality attributes, information hiding, components and connectors, multiple views, and architectural styles. When we design systems, we weave these abstractions together, preserving a chain of intentionality, so that the systems we design do what we want. Twenty years ago, in this magazine, Martin Fowler published the influential essay “Who Needs an Architect?” It’s time for developers to take another look at software architecture and see it as a set of abstractions that helps them reason about software." [1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/ https://pragprog.com/titles/mkdsa/design-it/ [2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1OAJv5H4jew https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...