Good on him for designing software in the large on the regular and on the daily. I saw him give a talk once in the round. Without him I would be in a bad way.
Designing Software in the Large
21–30 of 41 posts
Re: Designing Software in the Large
#22Earlier quoted context omitted.
Project managers shouldn't be running engineering. They are there to keep the trains running on time, not to design the track, trains and stations. The generally accepted roles are Product decides what we need to build, Design decides how it should work from user perspective, Engineering decides how to build it at a reasonable upfront and maintenance cost. This involves a fair amount of influence, because Engineering…
I disagree fundamentally with the modern division of labor. I’ve been around long enough to understand that it doesn’t actually have to work like this. I don’t think you can be an expert in generic “Product” just like I don’t think you can be a generic management expert. And I don’t think you can decide what to build or how it should work from a user perspective without taking into account how it’s built. In many way…
Agree on the one engineer overpromising. But you can talk about a product without knowing how it’s built in finer details. But what can and can’t be done is the realm of engineering. Then the filtered list can be reduced by product to the ones that are inportant. So it’s actually a spiral: (product) here’s what I would like -> (eng) here’s how it can be done -> (product) let’s go with this one -> (eng) here is the plan -> etc…
Re: Designing Software in the Large
#23The actual hard question is probably making even 10% of such wisdom and good intentions survive when the program is bombarded by contributor patches, or people taking Jira tickets. TFA talks about it in the context of strategy and tactics. Organizationally enforcing strategy would be the issue. And also that the people most interested in making rules for others in an organization may not be the ones best qualified to…
It would be cool to see a linter, or a new language, that makes good architecture easy and bad architecture hard. Like making state machines easier than channels. (Rust is sort-of good at state machines compared to C++ but it has one huge issue because of the ownership model, which makes good SMs a little clumsy) Or making it slightly inconvenient to do I/O buried in the middle of business logic.
Bad architecture is a communication problem, not a technical one. It’s rushing in without knowing the domain and its constraints.
Doing IO in the middle of business logic is just bad coding. It’s usually the developer not caring about the architecture (tornado coding or slum coding) or the architecture not existing.
Re: Designing Software in the Large
#24I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read. It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things. I find software design highly related to scientific theory development and modeling, and related to mathematica…
[dead]
Re: Designing Software in the Large
#25I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read. It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things. I find software design highly related to scientific theory development and modeling, and related to mathematica…
The author is describing less a theory and more a framework or system of heuristics bases on extensive practicap experience. There's no need for rigor if it's practical and useful. I think your desire for grounding in something "scientific" or "mathematical" is maybe missing the forest for the trees a bit. Saying this as someone with loads of practical software development experience and loads of math experience. I just don't find that rigor does much to help describe or guide the art of software. I do think Ousterhout's book is invaluable.
Re: Designing Software in the Large
#26The actual hard question is probably making even 10% of such wisdom and good intentions survive when the program is bombarded by contributor patches, or people taking Jira tickets. TFA talks about it in the context of strategy and tactics. Organizationally enforcing strategy would be the issue. And also that the people most interested in making rules for others in an organization may not be the ones best qualified to…
It would be cool to see a linter, or a new language, that makes good architecture easy and bad architecture hard. Like making state machines easier than channels. (Rust is sort-of good at state machines compared to C++ but it has one huge issue because of the ownership model, which makes good SMs a little clumsy) Or making it slightly inconvenient to do I/O buried in the middle of business logic.
The language is English, the linter is us. These are things ultimately solved by establishing good processes and frameworks, making it difficult to do a task in a way other than the intended one.
Re: Designing Software in the Large
#27I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read. It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things. I find software design highly related to scientific theory development and modeling, and related to mathematica…
> related to mathematical theories like model theory, which give precise accounts of what it means to describe something
Perhaps too precise? APoSD is about the practical challenges of large groups of people creating and maintaining extensive written descriptions of logic. Mathematical formalisms may be able to capture some aspects of that, but I'm not sure they do so in a way that would lend real insight.
"How can I express a piece of complicated logic in an intuitive and easy-to-understand way" is fundamentally closer to writer's craft than mathematics. I don't think a book like this would ever be mathematically grounded, any more than a book about technical writing would be. Model theory would struggle to explain how to write a clear, legible paragraph.
Re: Designing Software in the Large
#28The complexity in our team's code bases have only gotten worse with AI-integrated agents. Maybe it's the prompts we're using, but it's an ironic twist that these tools that promise so much productivity today ends up dumping more tech debt into our code. It's funny reading the "key contributors to dependency-complexity" -- Duplication, Exceptions, Inheritance, Temporal Decomposition -- because those qualities seem lik…
I have to take special effort to tamp down on duplication in AI generated code.
For me it's not uncommon for AI to draft an initial solution in X minutes, which I then spend 3*X minutes refactoring. Here's a specific example for a recent feature I coded: https://www.youtube.com/watch?v=E25R2JgQb5c
Re: Designing Software in the Large
#29The largest successful software system we have is the internet.
So perhaps we should ask ourselves: What can we learn from the internet architecture?
And no that does not automatically mean micro-services. The core idea of the internet is to agree on API's (protocols like HTTP) and leave the rest as implementation details. You can do the same with modules, libraries, classes, files etc.
Re: Designing Software in the Large
#30The largest successful software system we have is the internet. So perhaps we should ask ourselves: What can we learn from the internet architecture? And no that does not automatically mean micro-services. The core idea of the internet is to agree on API's (protocols like HTTP) and leave the rest as implementation details. You can do the same with modules, libraries, classes, files etc.
I totally agree and recently wrote a piece about this and how I came to the same question: "what can we learn?"
https://github.com/MickDuprez/Protocol-Driven-Development
Even if you do use micro-services you still need a protocol!