7 ms·

Ask HN: Best books on managing software complexity?

253 points by zenkat 5y ago

What are the best books you've read on how to manage software complexity, both from an architectural as well as organizational perspective?

yuppie_scum 5y ago
These are more architecture focused but maybe relevant. The Phoenix Project. The DevOps Handbook. The Google SRE Book. And “Kill It With Fire.”
jupp0r 5y ago
“Software Engineering at Google” has been eye opening for me. It hits what you are looking for in its first chapter and then goes into details of different aspects in later chapters. https://abseil.io/resources/swe-book https://abseil.io/resources/swe-book
- hutrdvnj 5y ago
  Summary of each chapter from the Book: https://www.seagnotes.com/index.html https://www.seagnotes.com/index.html
MoritzWall 5y ago
Architectural perspective: Clean Architecture: A Craftsman’s Guide to Software Structure and Design https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/ https://www.oreilly.com/library/view/clean-architecture-a/97... Organizational perspective: An Elegant Puzzle: Systems of Engineering Management by Will Larson https://press.stripe.com/an-elegant-puzzle https://press.stripe.com/an-elegant-puzzle
- ignoramous 5y ago
  Re: An Elegant Puzzle: If you remember, could you please write a bit about the key insights from it?
  - kqr 5y ago
    Not the person you're asking, but I was actually somewhat underwhelmed by that book. Maybe I had unrealistic expectations, but I felt like it combined very general, obvious ideas ("keep teams together") with oddly specific numeric recommendations ("a manager doing technical work in addition to management can support at most five people") that didn't come with any good evidence beyond author opinion. There were some things that I did find reason to take notes on, such as: - Each area of responsibility should have a team dedicated to it, even if some teams end up having zero people in them, and sometimes members from other teams have to rotate into that function. I liked this because I know how easy it is to forget that some functions are understaffed if you squeeze them in with other functions. - If you want to improve how the larger organisation works, run the improvement as an experiment in your team and then publish a very brief report on the results along with instructions for how other teams can try it. I liked this because I've often done the first part, but I've often forgotten the publishing part. - A leader is asked to decide a million things a day. Your job is not the make those decisions, your job is to figure out a system in which the decision is not needed, or the right decision is clear for anyone to see, and then help others participate in that system. I knew this from before, but it bears repeating because it's so easy to forget in the heat of decision-making. (The last point has a more general corollary: your job is never to do what you were hired for, it's to teach others how to do what you were hired for.)
    - blowski 5y ago
      I found "An Elegant Puzzle" brilliant because the advice was so specific and concrete on a wide range of topics. But I'd guess the target audience is a leader in a mid-size startup (100-500 employees), so its advice isn't going to be so much help outside that group.
kqr 5y ago
Michael Feather's book on legacy code contains a lot of advice that ought to be obvious, and yet every time I'm handed a scary piece of complex legacy software, I leaf through Feather's book and I almost always find something useful.
- SideburnsOfDoom 5y ago
  This book: https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code https://www.goodreads.com/book/show/44919.Working_Effectivel... You can also google up a fair amount of related blog text, and video talks content.
ncfausti 5y ago
I’ve been liking Grokking Simplicity so far. It starts out by separating code into three parts: data, computations, side-effects. You want to minimize side-effects, preferring computations over them, and data over computations. I’m still early into it, however, this already has been a helpful lens to view my code through. https://www.manning.com/books/grokking-simplicity https://www.manning.com/books/grokking-simplicity
mikevm 5y ago
I suggest looking into: https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy/dp/0136524036 https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy/dp/... It's very unorthodox, but cuts through a lot of the bullshit.
irthomasthomas 5y ago
Bob Martins stuff is good, like Clean Architecture https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164 https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar... https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...
m0rc 5y ago
As a baseline on what is know and not know about managing software projects, I always recommend Robert L. Glass Facts and Fallacies of Software Engineering. More speculatively, I think that the following biology readings are inspiring: - Gerald Jay Sussman, Building Robust Systems an essay. In general, biology should be a source of inspiration for engineers. - E. Goldratt, The Goal
kennethh 5y ago
Surprised nobody have mentioned Making software, https://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321 https://www.amazon.com/Making-Software-Really-Works-Believe/... It takes a empirical view on the software process. Does writing tests first help you develop better code faster? Can code metrics predict the number of bugs in a piece of software? Do design patterns actually make better software?
bear8642 5y ago
Yet to experience proper work life, but really enjoyed Brook's The Mythical Man-Month
- myle 5y ago
  I read it last year and it felt quite outdated. Perhaps because the innovative ideas then that the book presents are now mainstream.
pluggles 5y ago
A philosophy of software design by John Ousterhout https://smile.amazon.com/dp/1732102201/ref=cm_sw_r_apan_glt_i_WR2F47J0SEXNEPJNE0BZ https://smile.amazon.com/dp/1732102201/ref=cm_sw_r_apan_glt_... The entire focus of the book is reducing complexity.
mdaniel 5y ago
I enjoyed "A philosophy of software design" by John K Ousterhout https://www.worldcat.org/title/philosophy-of-software-design/oclc/1274059436 https://www.worldcat.org/title/philosophy-of-software-design... just be forewarned that at 180 pages, it's a lot more aspirational than instructive. It depends on what kind of organizational problem you're having: lack of experience, lack of interest, lack of discipline, lack of buy-in, or $other
- urthor 5y ago
  A philosophy of software design is an excellent book. Although its ideas are heavily couched in OO terminology, it's changed my ideas about interfaces and exposure to complexity utterly. Not comprehensive, but every programmer should absolutely read it (it's a tiny book after all).
  - Scarblac 5y ago
    I just finished it and haven't sat down to write a proper review yet. But I thought it was very uneven in value. The parts about deep and shallow modules, what good interfaces are, _why_ keeping everything about their implementation hidden is so important -- those were very good. He also advocated against having small routines, which are almost dogma nowadays (mostly because they're easier to unit test), and he's pretty convincing. That would mean that "making your code easier to test also improves its design" is wrong. Other parts about documentation etc I thought were too long and not very interesting. Then the bit at the end about optimizing for execution speed was very interesting again, though perhaps because I had never read much on the subject, before, I don't know. Yes, read it, it's an interesting contribution.
    - exclipy 5y ago
      > That would mean that "making your code easier to test also improves its design" is wrong. I assume that quote is talking about unit tests, but it's becoming more and more accepted that integration tests are more important than unit tests. https://kentcdodds.com/blog/write-tests https://kentcdodds.com/blog/write-tests This shift away from unit tests is the corollary to Ousterhout's preference for deep modules.
Twisol 5y ago
Peter Naur's "Programming as Theory Building" is a classic essay, and absolutely worth reading. This transcription [1] (with some extra remarks at the end by the transcriptor?) is pretty accessible. [1] https://pablo.rauzy.name/dev/naur1985programming.pdf https://pablo.rauzy.name/dev/naur1985programming.pdf
jnmandal 5y ago
Domain Driven Design by Eric Evans
- stevebmark 5y ago
  I found DDD very poorly written. It's a nightmare slog to read. I find Evans isn't a gifted writer and thinks unedited rambling is appropriate for a textbook. The 600 pages could easily have been 100. DDD can also be a poison to core systems, and Evans never considers this (I don't think he knows it). If you try to encode business domains, service lines, product names, stakeholder role names, what have you, into your core software, now you can't iterate on the business, because it requires refactoring the core. Building generic platforms with minimal "domain" (whatever that term means, Evans can't even define it) concerns in it, and keeping the business logic as far in user configuration land as possible, gives a business more flexibility and a better chance at surviving.
  - stepbeek 5y ago
    I don’t believe that Evans was arguing for pulling every concern in the wider system into a single model (the last third of the book gives techniques for overall system architecture). Different service lines, or products, would surely belong in distinct bounded contexts in DDD. > keeping the business logic as far in user configuration land as possible This sounds dreadfully difficult to build and test. The kind of business rules engine that you’re describing is more likely to be overpriced and buggy than a simpler well-modeled set of core domain classes imo. Not every piece of software should be excel.
  - hackerfromthefu 5y ago
    I've only had one experience with DDD at an company that was very interested in it and trying to push it into their codebase, and kind of 'righteous' about it. Zealots in other words but unfortunately they didn't have enough real world experience to know what actually worked well in their context.. just cargo culting. They had a project in planning for 18 months but hadn't been able to start it. I was hired as a principal and given this one of my major impacts to deliver, though other things kept getting piled on in front of it. To actually get it done one weekend I sat down and cranked out a functioning POC that could easily and rapidly be extend into the fully working system. Come Monday they were blown away to see the major progress of an actual working system, and loved the system and were very happy about it. Then the bike-shedding began, an order of magnitude more person hours was spent talking about it than it took me to build it and they required rewriting it because they a data library I used 'old tech and uncool'.. Hilariously that data library was actually a DDD system that created bounded contexts and enforced a domain model in them, but due to their lack of understanding they didn't see that! The hilarious irony! I wasn't a DDD guy, though having been a high level architect for 15 years I was using all the things I have found that worked best. Some time later I was reading about DDD and realised that system was actually DDD. Of course by that time I had already left, to deliver working systems instead of waste time bike-shedding with cargo culters!
throwaway2037 5y ago
"Large-Scale C++ Volume I: Process and Architecture" by John Lakos
- Cwizard 5y ago
  How specific is this book to C++? Would you still recommend it to someone who doesn’t work with C++?
  - Cthaeeh 5y ago
    It contains lots of c++ specific advice but also general good architecture advice. I would recommend it if you have already read Ousterhouts 'A philosophy of Software design' and maybe one more book and are still curious about the topic. Also there is something of a summary, by himself here: https://youtu.be/d3zMfMC8l5U https://youtu.be/d3zMfMC8l5U
- Cthaeeh 5y ago
  I loved that book! But it is unfortunately not a book for everyone, since it has ~1000 pages. It contains both one of the best architecture discussions (IMHO) and a ton of C++ specific advice/rules. So for someone that doesn't have a large C++ code bad, Ousterhouts book is the better suggestion.
rTX5CMRXIfFG 5y ago
I haven't read any of the books on architecture recommended in this thread, but I learned how to manage software complexity by: 1. Counter-intuitively, being deeply interested and reading about a topic in natural science. Software is complex because it is a system, and especially if you're using a programming language with plenty of OOP features, you're going to benefit a lot from understanding how nature separates properties and functions into organic matter, how they work in concert to achieve a particular effect, and how they compose each other to scale up from the atomic to the cosmic scale; or 2. If you can't be bothered to learn about topics beyond programming itself, then practice unit testing. As a matter fact, attempt to write unit tests for your old code. If you can't make the unit test run, then that's life slapping you in the face to tell you that your code is way too tightly-coupled. By the end of the day, doing any of the above things (but more so, both!) will teach you the true essence of KISS.
- elcapitan 5y ago
  The nature approach sounds intriguing, any pointers on where to start or what to read?
  - rTX5CMRXIfFG 5y ago
    It has to be a topic of interest specifically for you, otherwise you’ll probably just get bored and stop halfway through. For me it was exercise science. It was a super fascinating and mind-opening journey for me from skeletal muscle contractions to how the body burns calories, to how to program weight training exercises, how to make my own diet program and throwing away all the hype around it, etc. I can imagine that for others it might be just straight up neuroscience, or something zoology if you like pets, or physics. The idea is to try to see these natural phenomena as running code, and to think of how nature designed and wrote the code to make it all work. I can see how the approach sounds absurd, but maybe video game developers would be able to relate to what I’m saying since (I assume) they do a lot of world-building and have to make simulations of real-world objects.
    - elcapitan 5y ago
kqr 5y ago
I feel like a broken record for the amount of comments I've posted related to Deming and lean product development these past few days, but as Taiichi Ohno says, the biggest waste is overproduction. A lot of the things we build into our software is complexity nobody really needs. One way of managing it is by never making it in the first place. This takes at least two things: - Thorough discussion with the customer about what problem they really are trying to solve. They will come to you with what they think is the solution. That way leads unnecessary complexity. - Rough economical analysis of choices. Often we do things because that's what one ought to do. Make a quick napkin calculations. A lot of the things one ought to do are not actually necessary. There are way too many books to recommend here, but perhaps some of the most relevant are - Deming's The New Economics, and Out of the Crisis, - Reinertsen's Principles of Product Development Flow, - Ward's Lean Product and Process Development.
- ozim 5y ago
  Unfortunately "not implementing a feature" is not my decision most of the time. Most of the time we need to convince some customer that we can implement what he needs because even though everything is there "they are super special". If you start with saying no - you won't get a sale, our sales of course try to explain that we are quite successful SaaS solution so they probably could work in way we propose and won't have to pay for custom development. Mind you that it most of the time is not purely technical but often it is checking if they can get what they want so to say "checking the waters" if we are responsible vendor. Sometimes it is just asserting dominance by asshole manager of a big company to see how far will company bend over to win the contract. Good part is most of the time we simply get paid for "custom development" but the downside is when 1 year or 2 later such customer goes away this code stays and is not that useful for other customers. So even if those customers pay quite a lot for custom dev, they externalize cost of software maintenance to SaaS vendor. Because I don't believe anyone is factoring that in the price even if customer pays monthly fees for 2 years, if he goes away we are left with dead code and even removing it costs money as you still have to do regression testing.
  - kqr 5y ago
    Yes, there are difficult customers. Sometimes they're worth taking on, and sometimes it's better to tell them "best of luck in searching for what you want with someone else." That takes said napkin calculation, and thinking a bit like an insurance business. You can't know for sure whether you'll make or lose money on a particular customer, but you can learn to work with expectations so that your bets in aggregate make you money.
kqr 5y ago
Software complexity is often made worse by organisational complexity. Someone put it as "make sure people do complex jobs in simple organisations rather than the other way around. David Marquet's books have been surprisingly helpful to me in shaping simpler organisations, starting, of course, with Turn the Ship Around.
eterps 5y ago
Domain Modeling Made Functional - Scott Wlaschin
- matyasrichter 5y ago
  This is great especially if you're deep into the OOP way of building everything - Java, .NET, ... Really gives a whole another perspective.
adamddev1 5y ago
This might seem more basic/beginner level but I really have enjoyed working through How To Design Programs. [1] It teaches you how to think about data, types, abstraction, and creating mini languages/sets of functions for robust, adjustable, and maintainable code. It's helped me immensely as I've started to build much more complicated stuff. It's amazing how you can follow the design recipies, break problems into parts, plug functions together, everything just works. Applying these principles in a typed language (TypeScript) has massively improved my ability to much more complex stuff that is also more safe and maintainable. [1]: https://htdp.org/ https://htdp.org/
- deleted 5y ago
  [deleted]
kqr 5y ago
The least complex software is the one never built. We often over-automate. Automation is brittle and inflexible and easily ends up lined with edge cases and other types o complexity. Automation is great when it replaces a stable, well-working manual process. The way to introduce automation is to first experiment with humans doing something manually until you have a great process. Then take the dumbest, most reliable part of that and turn it into a computer program that alerts a human if it encounters an edge case. Try not to handle edge cases in the software, but try to remove them from the greater system in which they occur. Automate by elimination, not by complexity. Good books in this vein would be anything with Taiichi Ohno in the title, or, perhaps better, as the author.
- extheat 5y ago
  Conversely, automation creates a clear and well defined workflow for completing a task. There is nothing to "automate" if there is not already a manual process to doing it. Sure, sometimes the automation you introduce can be an over-engineered solution that's more difficult to maintain (or just not work) compared to a human-done manual process. To that point I think a valid solution would be to make the process itself more automation friendly, if possible given your circumstances.
  - kqr 5y ago
    Yes. This is what Taiichi Ohno would call "standard work": well-defined processes intended to be executed literally, and evolved with and by the people who perform the execution. Standard work is a great source of things to automate, but automation is not a replacement for it.
- majkinetor 5y ago
  > Automation is brittle and inflexible Wait what ? Mine automation works for years without an issue. Flaky automation is meaningless. > that alerts a human if it encounters an edge case. No. It shouldn't alert anybody almost never if it's good. When you have 300 automation routines, even if it alerts once a year you will have some alert every day. So it needs to alert lower then that, when the world falls out or something...
aristofun 5y ago
Grady Booch “OO Analysis & Design” Classics
sakesun 5y ago
For me it's Design Patterns: Elements of Reusable Object-Oriented Software The essay in the the beginning of the book gave me a profound epiphany back then.
- atulatul 5y ago
  I agree so much about the essay. One of those contents where I felt like underlining every single sentence.
fred123 5y ago
Out of the tar pit is the best paper on this I’ve ever read: http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf
- bob1029 5y ago
  This paper revolutionized my perspective on software engineering and ultimately how our company does business. If you want to skip to the good part, Chapter 9 is where you want to be. We were able to create a hybrid FRP system that uses SQLite & application-defined functions as the sandbox within which all of this hypothetical functional/relational business occurs. This is in production for several of our customers right now.
  - fred123 5y ago
    Actually I think chapters 1–8 are more valuable than the chapters dealing with a concrete implementation because they teach you ideas and principles
- rramadass 5y ago
  Very good suggestion ! I would add Frederick Brooks' No Silver Bullet alongside this for better understanding.
blowski 5y ago
I agree with much of what's already said here. 1. Figure out the difference between your inherent and accidental complexity. The Cynefin framework can be a useful way of thinking about what types of complexity you have. 2. Attempt to reduce (or remove) the complexity at root before assuming you must model it. "The biggest tragedy in business is doing well that which should not be done at all." For example, we had an important user still on a legacy browser because they couldn't afford to upgrade their old laptop. Instead of adding a complicated legacy layer, we bought them a new laptop. 3. Think of the whole system, rather than just shifting the burden somewhere else within the system. This is why microservice architectures so often fail - engineers think they've reduced complexity because each service is so simple. Yet all they've done is move the complexity into the operational layer, where it's harder to deal with. Gerald Weinberg is a fun writer in this space. 4. In many organisations, a lot of people's salaries depend on their ability to add complexity, especially to processes but also to code. If you are working within such an organisation, you will have a Sysiphian task until you solve the organisational problem. Whether you can solve this problem depends on how much influence you have. This is why "skunkworks" projects so often work until they are re-integrated into the mainstream. 5. Once you've sorted out the organisational complexity, separated the inherent and accidental complexity, you'll be most of the way there. Keep reviewing and challenging everything. Complexity is a weed that just seems to grow unless you constantly tend to the garden.
- elcapitan 5y ago
  Any recommendations re: Weinberg and complexity? I've read his book on consulting, which was really well written.
  - kqr 5y ago
    He has a whole series on Quality Software which, admittedly, I only came about a third of the way through before I took a break for other books, but it has contained some useful analysis so far. I do plan on picking it up again once I'm done with my current read.
- webmaven 5y ago
  > For example, we had an important user still on a legacy browser because they couldn't afford to upgrade their old laptop. Instead of adding a complicated legacy layer, we bought them a new laptop. I'm curious about the specifics regarding the combination of "important user" and "couldn't afford to upgrade". Was the user's importance social rather than financial? Were the hardware requirements particularly hefty?
bobm_kite9 5y ago
I touch on both these perspectives in my book ‘Risk-First Software Development’. You can read all it online at https://riskfirst.org https://riskfirst.org if you want. Hope this is useful to you.
andreskytt 5y ago
https://link.springer.com/chapter/10.1007/978-981-15-5856-6_7 https://link.springer.com/chapter/10.1007/978-981-15-5856-6_... Has a bunch of useful references. Olivier de Weck of the MIT held an awesome conference speech at the 2016 MIT SDM Conference explaining sources, metrics and cost of organizational complexity linked to engineering complexity. Sadly, the video no longer appears online. But the work of him and his group (references in the article above) is highly relevant to your question.
froh 5y ago
At an organizational level, Donald Reinertsen "the principles of product development flow" is outstanding. https://books.google.de/books/about/The_Principles_of_Product_Development_Fl.html?id=1HlPPgAACAAJ&source=kp_book_description&redir_esc=y https://books.google.de/books/about/The_Principles_of_Produc... It motivates small batch sizes, decision making at ground level, short cycle times, all the mechanics behind kanban, scrum, XP, without ever using any of their jargon. And it moves up into economics by explaining e.g. cost of delay as a metric guiding useful decision making. The book eatablishes a wonderful shared understanding of the principles underlying lean and agile, why they work and how to make them work, shared understanding between engineering and management.
deltaonefour 5y ago
Written by the authors of sicp: https://mitpress.mit.edu/books/software-design-flexibility https://mitpress.mit.edu/books/software-design-flexibility Organization is just a name for a group of methodologies. Ultimately what we want is the right way to organize programs for maximum flexibility.
- adamddev1 5y ago
  I really like that tagline, "How to avoid programming yourself into a corner." Sometimes I've made stuff that I've hacked and hacked together until it barely works and it feels like you're just straining harder and harder to get it workable and then there's this sinking feeling of, "oh dear, I can never touch or change this or everything will crumble into an irreparable mess." Learning the SICP/HTDP way of creating a "language" to handle your problem with changed everything for me. It helps you to clearly lay out and work with the particular kinds of operations that your problem (and its variations) require. As Hal Abelson explains in this podcast: [1] > So you really take the attitude that, boy if I’m writing something complex, I need to think about what I’m doing as if I’m writing a language. Or just say that a little less onerously. When I think about the operations I want to produce in any kind of program I’m writing, I don’t want to think about only that particular problem I’m doing right then. I want to carve out a space that’s broad enough that I could be doing that particular problem and lots of variations and lots of similar ones. [1]: https://corecursive.com/039-hal-abelson-sicp https://corecursive.com/039-hal-abelson-sicp
  - deltaonefour 5y ago
    Agreed. That tagline is what entire corporations do. They program their entire ecosystem into a corner and it demands an entire rewrite or refactor.
triebelf 5y ago
I found this one very good: A Philosophy of Software Design https://www.amazon.com/dp/173210221X https://www.amazon.com/dp/173210221X
zonovar 5y ago
The Pragmatic Programmer https://www.amazon.co.uk/Pragmatic-Programmer-Andrew-Hunt/dp/020161622X https://www.amazon.co.uk/Pragmatic-Programmer-Andrew-Hunt/dp...
KingOfCoders 5y ago
First keep it simple, shameless self plug: https://www.radicalsimpli.city/ https://www.radicalsimpli.city/
AussieWog93 5y ago
At least from where I'm at (ex-SWE, quit at a relatively junior level), I'm not sure this is something you can read about and reason logically. It's something you need to a feel for through experience.
fulafel 5y ago
Do you want to find out about managing a bad case of complexity in an existing project? Or are you searching for ways to avoid getting into a bad place with sw complexity and looking for even radical simplicity because you are determinde to avoid (or can't afford) complexity? These are quite different missions since it's rarely possible to recover form complexity if you've already gone there.
david_allison 5y ago
Michael C. Feathers - Working Effectively with Legacy Code Scott Wlaschin - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#
- rmetzler 5y ago
  Eric Normand - Grokking Simplicity: Taming complex software with functional thinking I also bought the Scott Wlaschin book, but I must say I like Eric Normand's book a little bit better. Since the examples are also in JavaScript (but applicable to a lot of languages), I think it's easier to follow for everyone who's coming from an OOP background. I'm also looking forward to Yehonathan Sharvit - Data-Oriented Programming: Unlearning objects.
rramadass 5y ago
I think it is worthwhile to first look into the fields of Complexity Science/Complex Systems Science and Systems Thinking/Systems Theory for overarching insights : [ https://en.wikipedia.org/wiki/Complex_system https://en.wikipedia.org/wiki/Complex_system and https://complexityexplained.github.io/ https://complexityexplained.github.io/ ] and [ https://en.wikipedia.org/wiki/Systems_thinking https://en.wikipedia.org/wiki/Systems_thinking and https://thesystemsthinker.com/systems-thinking-what-why-when-where-and-how/ https://thesystemsthinker.com/systems-thinking-what-why-when... ] For Software specific issues i highly recommend David Parnas' collected papers in the book Software Fundamentals. He and his colleagues defined much of what is mainstream in today's Software Architecture/Organization practice. Finally, the case studies given here are a great source of insights: https://aosabook.org/en/index.html https://aosabook.org/en/index.html
- kqr 5y ago
  Am I doing something wrong if I'm unable to find that Parnas collection as a digital book? I've read some of his papers and they were very influential on me. Would love the book but I rarely have the energy to bring a print copy of books.
  - rramadass 5y ago
    In this case the "paper copy" of the book is very much worth it :-) The articles are all foundational, timeless and gets to the heart of the matter unlike most books today.
rrrodia 5y ago
It's a long shot, but is anyone aware of useful MOOCs that cover this topic?
bkgh 5y ago
Object Thinking by David West
Ozzie_osman 5y ago
- Philosophy of Software Design (great short read packed with insight) - Mythical Man-Month (the classic, a little outdated but the principles still ring very true) - Software Engineering at Google (thoughts from a company that has spent a lot of time thinking about this at scale)
glintik 5y ago
Best book is task description how to add small feature to your project. If it’s still clear and easy, then you don’t need to read any books about software complexity management ).
sedeki 5y ago
This is a book that focuses on managing software complexity and to "avoid painting oneself into a corner": https://mitpress.mit.edu/books/software-design-flexibility https://mitpress.mit.edu/books/software-design-flexibility
zenkat 5y ago
OP here. Thank you for all of the great suggestions! I've compiled all the references into this spreadsheet: <https://docs.google.com/spreadsheets/d/1kgFSWp7rM3ZegweXAoMN-4Hv88sNS--xUuDnHp6IftQ/edit https://docs.google.com/spreadsheets/d/1kgFSWp7rM3ZegweXAoMN...> From my perspective, the top "must-reads" are: -- John K Ousterhout, A Philosophy of Software Design -- Titus Winter (et al), Software Engineering at Google -- Hanson and Sussman, Software Design for Flexibility Other interesting titles that caught my eye: -- Peter Naur, Programming as Theory Building -- Scott Wlaschin, Domain Modeling Made Functional -- Yehonathan Sharvit, Data-Oriented Programming: Unlearning objects (upcoming) -- Nick Tune, Patterns, Principles, and Practises of Domain Driven Design -- Robert L. Glass, Facts and Fallacies of Software Engineering -- Donald Reinertsen, The Principles of Product development Flow -- Eric Normand, Grokking Simplicity
bradleysmith 5y ago
Not a book, but this paper “big ball of mud” has resonated with me in describing troubles I’ve faced before, and has me coming back to it as I run into new architectural problems where I’m not confident in my/our approach. http://www.laputan.org/mud/ http://www.laputan.org/mud/
tq-qv 5y ago
The "original" Scrum book https://read.amazon.com/kp/card?asin=0130676349Q&preview=inline&linkCode=kpe&ref_=dbs_a_def_rwt_bibl_vppi_i2 https://read.amazon.com/kp/card?asin=0130676349Q&preview=inl... Stuff on lean manufacturing (yes. manufacturing!) https://www.amazon.de/dp/B000SEGIVS?ref_=cm_sw_r_kb_dp_ocvTDbQPS1EGA&tag=kp0508-21&linkCode=kpe https://www.amazon.de/dp/B000SEGIVS?ref_=cm_sw_r_kb_dp_ocvTD... https://www.amazon.de/dp/B002LHRM2O?ref_=cm_sw_r_kb_dp_I9SSDb704MDTV&tag=kp0508-21&linkCode=kpe https://www.amazon.de/dp/B002LHRM2O?ref_=cm_sw_r_kb_dp_I9SSD...

253 points by zenkat 5y ago

What are the best books you've read on how to manage software complexity, both from an architectural as well as organizational perspective?

yuppie_scum 5y ago

These are more architecture focused but maybe relevant. The Phoenix Project. The DevOps Handbook. The Google SRE Book. And “Kill It With Fire.”

jupp0r 5y ago

“Software Engineering at Google” has been eye opening for me. It hits what you are looking for in its first chapter and then goes into details of different aspects in later chapters. https://abseil.io/resources/swe-book https://abseil.io/resources/swe-book

hutrdvnj 5y ago
Summary of each chapter from the Book: https://www.seagnotes.com/index.html https://www.seagnotes.com/index.html

MoritzWall 5y ago

Architectural perspective: Clean Architecture: A Craftsman’s Guide to Software Structure and Design https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/ https://www.oreilly.com/library/view/clean-architecture-a/97... Organizational perspective: An Elegant Puzzle: Systems of Engineering Management by Will Larson https://press.stripe.com/an-elegant-puzzle https://press.stripe.com/an-elegant-puzzle

ignoramous 5y ago
Re: An Elegant Puzzle: If you remember, could you please write a bit about the key insights from it?
- kqr 5y ago
  Not the person you're asking, but I was actually somewhat underwhelmed by that book. Maybe I had unrealistic expectations, but I felt like it combined very general, obvious ideas ("keep teams together") with oddly specific numeric recommendations ("a manager doing technical work in addition to management can support at most five people") that didn't come with any good evidence beyond author opinion. There were some things that I did find reason to take notes on, such as: - Each area of responsibility should have a team dedicated to it, even if some teams end up having zero people in them, and sometimes members from other teams have to rotate into that function. I liked this because I know how easy it is to forget that some functions are understaffed if you squeeze them in with other functions. - If you want to improve how the larger organisation works, run the improvement as an experiment in your team and then publish a very brief report on the results along with instructions for how other teams can try it. I liked this because I've often done the first part, but I've often forgotten the publishing part. - A leader is asked to decide a million things a day. Your job is not the make those decisions, your job is to figure out a system in which the decision is not needed, or the right decision is clear for anyone to see, and then help others participate in that system. I knew this from before, but it bears repeating because it's so easy to forget in the heat of decision-making. (The last point has a more general corollary: your job is never to do what you were hired for, it's to teach others how to do what you were hired for.)
  - blowski 5y ago
    I found "An Elegant Puzzle" brilliant because the advice was so specific and concrete on a wide range of topics. But I'd guess the target audience is a leader in a mid-size startup (100-500 employees), so its advice isn't going to be so much help outside that group.

kqr 5y ago

Michael Feather's book on legacy code contains a lot of advice that ought to be obvious, and yet every time I'm handed a scary piece of complex legacy software, I leaf through Feather's book and I almost always find something useful.

SideburnsOfDoom 5y ago
This book: https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code https://www.goodreads.com/book/show/44919.Working_Effectivel... You can also google up a fair amount of related blog text, and video talks content.

ncfausti 5y ago

I’ve been liking Grokking Simplicity so far. It starts out by separating code into three parts: data, computations, side-effects. You want to minimize side-effects, preferring computations over them, and data over computations. I’m still early into it, however, this already has been a helpful lens to view my code through. https://www.manning.com/books/grokking-simplicity https://www.manning.com/books/grokking-simplicity

mikevm 5y ago

I suggest looking into: https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy/dp/0136524036 https://www.amazon.com/Righting-Software-Juval-L%C3%B6wy/dp/... It's very unorthodox, but cuts through a lot of the bullshit.

irthomasthomas 5y ago

Bob Martins stuff is good, like Clean Architecture https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164 https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar... https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...

m0rc 5y ago

As a baseline on what is know and not know about managing software projects, I always recommend Robert L. Glass Facts and Fallacies of Software Engineering. More speculatively, I think that the following biology readings are inspiring: - Gerald Jay Sussman, Building Robust Systems an essay. In general, biology should be a source of inspiration for engineers. - E. Goldratt, The Goal

kennethh 5y ago

Surprised nobody have mentioned Making software, https://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321 https://www.amazon.com/Making-Software-Really-Works-Believe/... It takes a empirical view on the software process. Does writing tests first help you develop better code faster? Can code metrics predict the number of bugs in a piece of software? Do design patterns actually make better software?

bear8642 5y ago

Yet to experience proper work life, but really enjoyed Brook's The Mythical Man-Month

myle 5y ago
I read it last year and it felt quite outdated. Perhaps because the innovative ideas then that the book presents are now mainstream.

pluggles 5y ago

A philosophy of software design by John Ousterhout https://smile.amazon.com/dp/1732102201/ref=cm_sw_r_apan_glt_i_WR2F47J0SEXNEPJNE0BZ https://smile.amazon.com/dp/1732102201/ref=cm_sw_r_apan_glt_... The entire focus of the book is reducing complexity.

mdaniel 5y ago

I enjoyed "A philosophy of software design" by John K Ousterhout https://www.worldcat.org/title/philosophy-of-software-design/oclc/1274059436 https://www.worldcat.org/title/philosophy-of-software-design... just be forewarned that at 180 pages, it's a lot more aspirational than instructive. It depends on what kind of organizational problem you're having: lack of experience, lack of interest, lack of discipline, lack of buy-in, or $other

urthor 5y ago
A philosophy of software design is an excellent book. Although its ideas are heavily couched in OO terminology, it's changed my ideas about interfaces and exposure to complexity utterly. Not comprehensive, but every programmer should absolutely read it (it's a tiny book after all).
- Scarblac 5y ago
  I just finished it and haven't sat down to write a proper review yet. But I thought it was very uneven in value. The parts about deep and shallow modules, what good interfaces are, _why_ keeping everything about their implementation hidden is so important -- those were very good. He also advocated against having small routines, which are almost dogma nowadays (mostly because they're easier to unit test), and he's pretty convincing. That would mean that "making your code easier to test also improves its design" is wrong. Other parts about documentation etc I thought were too long and not very interesting. Then the bit at the end about optimizing for execution speed was very interesting again, though perhaps because I had never read much on the subject, before, I don't know. Yes, read it, it's an interesting contribution.
  - exclipy 5y ago
    > That would mean that "making your code easier to test also improves its design" is wrong. I assume that quote is talking about unit tests, but it's becoming more and more accepted that integration tests are more important than unit tests. https://kentcdodds.com/blog/write-tests https://kentcdodds.com/blog/write-tests This shift away from unit tests is the corollary to Ousterhout's preference for deep modules.

Twisol 5y ago

Peter Naur's "Programming as Theory Building" is a classic essay, and absolutely worth reading. This transcription [1] (with some extra remarks at the end by the transcriptor?) is pretty accessible. [1] https://pablo.rauzy.name/dev/naur1985programming.pdf https://pablo.rauzy.name/dev/naur1985programming.pdf

jnmandal 5y ago

Domain Driven Design by Eric Evans

stevebmark 5y ago
I found DDD very poorly written. It's a nightmare slog to read. I find Evans isn't a gifted writer and thinks unedited rambling is appropriate for a textbook. The 600 pages could easily have been 100. DDD can also be a poison to core systems, and Evans never considers this (I don't think he knows it). If you try to encode business domains, service lines, product names, stakeholder role names, what have you, into your core software, now you can't iterate on the business, because it requires refactoring the core. Building generic platforms with minimal "domain" (whatever that term means, Evans can't even define it) concerns in it, and keeping the business logic as far in user configuration land as possible, gives a business more flexibility and a better chance at surviving.
- stepbeek 5y ago
  I don’t believe that Evans was arguing for pulling every concern in the wider system into a single model (the last third of the book gives techniques for overall system architecture). Different service lines, or products, would surely belong in distinct bounded contexts in DDD. > keeping the business logic as far in user configuration land as possible This sounds dreadfully difficult to build and test. The kind of business rules engine that you’re describing is more likely to be overpriced and buggy than a simpler well-modeled set of core domain classes imo. Not every piece of software should be excel.
- hackerfromthefu 5y ago
  I've only had one experience with DDD at an company that was very interested in it and trying to push it into their codebase, and kind of 'righteous' about it. Zealots in other words but unfortunately they didn't have enough real world experience to know what actually worked well in their context.. just cargo culting. They had a project in planning for 18 months but hadn't been able to start it. I was hired as a principal and given this one of my major impacts to deliver, though other things kept getting piled on in front of it. To actually get it done one weekend I sat down and cranked out a functioning POC that could easily and rapidly be extend into the fully working system. Come Monday they were blown away to see the major progress of an actual working system, and loved the system and were very happy about it. Then the bike-shedding began, an order of magnitude more person hours was spent talking about it than it took me to build it and they required rewriting it because they a data library I used 'old tech and uncool'.. Hilariously that data library was actually a DDD system that created bounded contexts and enforced a domain model in them, but due to their lack of understanding they didn't see that! The hilarious irony! I wasn't a DDD guy, though having been a high level architect for 15 years I was using all the things I have found that worked best. Some time later I was reading about DDD and realised that system was actually DDD. Of course by that time I had already left, to deliver working systems instead of waste time bike-shedding with cargo culters!

throwaway2037 5y ago

"Large-Scale C++ Volume I: Process and Architecture" by John Lakos

Cwizard 5y ago
How specific is this book to C++? Would you still recommend it to someone who doesn’t work with C++?
- Cthaeeh 5y ago
  It contains lots of c++ specific advice but also general good architecture advice. I would recommend it if you have already read Ousterhouts 'A philosophy of Software design' and maybe one more book and are still curious about the topic. Also there is something of a summary, by himself here: https://youtu.be/d3zMfMC8l5U https://youtu.be/d3zMfMC8l5U
Cthaeeh 5y ago
I loved that book! But it is unfortunately not a book for everyone, since it has ~1000 pages. It contains both one of the best architecture discussions (IMHO) and a ton of C++ specific advice/rules. So for someone that doesn't have a large C++ code bad, Ousterhouts book is the better suggestion.

rTX5CMRXIfFG 5y ago

I haven't read any of the books on architecture recommended in this thread, but I learned how to manage software complexity by: 1. Counter-intuitively, being deeply interested and reading about a topic in natural science. Software is complex because it is a system, and especially if you're using a programming language with plenty of OOP features, you're going to benefit a lot from understanding how nature separates properties and functions into organic matter, how they work in concert to achieve a particular effect, and how they compose each other to scale up from the atomic to the cosmic scale; or 2. If you can't be bothered to learn about topics beyond programming itself, then practice unit testing. As a matter fact, attempt to write unit tests for your old code. If you can't make the unit test run, then that's life slapping you in the face to tell you that your code is way too tightly-coupled. By the end of the day, doing any of the above things (but more so, both!) will teach you the true essence of KISS.

elcapitan 5y ago
The nature approach sounds intriguing, any pointers on where to start or what to read?
- rTX5CMRXIfFG 5y ago
  It has to be a topic of interest specifically for you, otherwise you’ll probably just get bored and stop halfway through. For me it was exercise science. It was a super fascinating and mind-opening journey for me from skeletal muscle contractions to how the body burns calories, to how to program weight training exercises, how to make my own diet program and throwing away all the hype around it, etc. I can imagine that for others it might be just straight up neuroscience, or something zoology if you like pets, or physics. The idea is to try to see these natural phenomena as running code, and to think of how nature designed and wrote the code to make it all work. I can see how the approach sounds absurd, but maybe video game developers would be able to relate to what I’m saying since (I assume) they do a lot of world-building and have to make simulations of real-world objects.
  - elcapitan 5y ago

kqr 5y ago

I feel like a broken record for the amount of comments I've posted related to Deming and lean product development these past few days, but as Taiichi Ohno says, the biggest waste is overproduction. A lot of the things we build into our software is complexity nobody really needs. One way of managing it is by never making it in the first place. This takes at least two things: - Thorough discussion with the customer about what problem they really are trying to solve. They will come to you with what they think is the solution. That way leads unnecessary complexity. - Rough economical analysis of choices. Often we do things because that's what one ought to do. Make a quick napkin calculations. A lot of the things one ought to do are not actually necessary. There are way too many books to recommend here, but perhaps some of the most relevant are - Deming's The New Economics, and Out of the Crisis, - Reinertsen's Principles of Product Development Flow, - Ward's Lean Product and Process Development.

ozim 5y ago
Unfortunately "not implementing a feature" is not my decision most of the time. Most of the time we need to convince some customer that we can implement what he needs because even though everything is there "they are super special". If you start with saying no - you won't get a sale, our sales of course try to explain that we are quite successful SaaS solution so they probably could work in way we propose and won't have to pay for custom development. Mind you that it most of the time is not purely technical but often it is checking if they can get what they want so to say "checking the waters" if we are responsible vendor. Sometimes it is just asserting dominance by asshole manager of a big company to see how far will company bend over to win the contract. Good part is most of the time we simply get paid for "custom development" but the downside is when 1 year or 2 later such customer goes away this code stays and is not that useful for other customers. So even if those customers pay quite a lot for custom dev, they externalize cost of software maintenance to SaaS vendor. Because I don't believe anyone is factoring that in the price even if customer pays monthly fees for 2 years, if he goes away we are left with dead code and even removing it costs money as you still have to do regression testing.
- kqr 5y ago
  Yes, there are difficult customers. Sometimes they're worth taking on, and sometimes it's better to tell them "best of luck in searching for what you want with someone else." That takes said napkin calculation, and thinking a bit like an insurance business. You can't know for sure whether you'll make or lose money on a particular customer, but you can learn to work with expectations so that your bets in aggregate make you money.

kqr 5y ago

Software complexity is often made worse by organisational complexity. Someone put it as "make sure people do complex jobs in simple organisations rather than the other way around. David Marquet's books have been surprisingly helpful to me in shaping simpler organisations, starting, of course, with Turn the Ship Around.

eterps 5y ago

Domain Modeling Made Functional - Scott Wlaschin

matyasrichter 5y ago
This is great especially if you're deep into the OOP way of building everything - Java, .NET, ... Really gives a whole another perspective.

adamddev1 5y ago

This might seem more basic/beginner level but I really have enjoyed working through How To Design Programs. [1] It teaches you how to think about data, types, abstraction, and creating mini languages/sets of functions for robust, adjustable, and maintainable code. It's helped me immensely as I've started to build much more complicated stuff. It's amazing how you can follow the design recipies, break problems into parts, plug functions together, everything just works. Applying these principles in a typed language (TypeScript) has massively improved my ability to much more complex stuff that is also more safe and maintainable. [1]: https://htdp.org/ https://htdp.org/

deleted 5y ago
[deleted]

kqr 5y ago

The least complex software is the one never built. We often over-automate. Automation is brittle and inflexible and easily ends up lined with edge cases and other types o complexity. Automation is great when it replaces a stable, well-working manual process. The way to introduce automation is to first experiment with humans doing something manually until you have a great process. Then take the dumbest, most reliable part of that and turn it into a computer program that alerts a human if it encounters an edge case. Try not to handle edge cases in the software, but try to remove them from the greater system in which they occur. Automate by elimination, not by complexity. Good books in this vein would be anything with Taiichi Ohno in the title, or, perhaps better, as the author.

extheat 5y ago
Conversely, automation creates a clear and well defined workflow for completing a task. There is nothing to "automate" if there is not already a manual process to doing it. Sure, sometimes the automation you introduce can be an over-engineered solution that's more difficult to maintain (or just not work) compared to a human-done manual process. To that point I think a valid solution would be to make the process itself more automation friendly, if possible given your circumstances.
- kqr 5y ago
  Yes. This is what Taiichi Ohno would call "standard work": well-defined processes intended to be executed literally, and evolved with and by the people who perform the execution. Standard work is a great source of things to automate, but automation is not a replacement for it.
majkinetor 5y ago
> Automation is brittle and inflexible Wait what ? Mine automation works for years without an issue. Flaky automation is meaningless. > that alerts a human if it encounters an edge case. No. It shouldn't alert anybody almost never if it's good. When you have 300 automation routines, even if it alerts once a year you will have some alert every day. So it needs to alert lower then that, when the world falls out or something...

aristofun 5y ago

Grady Booch “OO Analysis & Design” Classics

sakesun 5y ago

For me it's Design Patterns: Elements of Reusable Object-Oriented Software The essay in the the beginning of the book gave me a profound epiphany back then.

atulatul 5y ago
I agree so much about the essay. One of those contents where I felt like underlining every single sentence.

fred123 5y ago

Out of the tar pit is the best paper on this I’ve ever read: http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf

bob1029 5y ago
This paper revolutionized my perspective on software engineering and ultimately how our company does business. If you want to skip to the good part, Chapter 9 is where you want to be. We were able to create a hybrid FRP system that uses SQLite & application-defined functions as the sandbox within which all of this hypothetical functional/relational business occurs. This is in production for several of our customers right now.
- fred123 5y ago
  Actually I think chapters 1–8 are more valuable than the chapters dealing with a concrete implementation because they teach you ideas and principles
rramadass 5y ago
Very good suggestion ! I would add Frederick Brooks' No Silver Bullet alongside this for better understanding.

blowski 5y ago

I agree with much of what's already said here. 1. Figure out the difference between your inherent and accidental complexity. The Cynefin framework can be a useful way of thinking about what types of complexity you have. 2. Attempt to reduce (or remove) the complexity at root before assuming you must model it. "The biggest tragedy in business is doing well that which should not be done at all." For example, we had an important user still on a legacy browser because they couldn't afford to upgrade their old laptop. Instead of adding a complicated legacy layer, we bought them a new laptop. 3. Think of the whole system, rather than just shifting the burden somewhere else within the system. This is why microservice architectures so often fail - engineers think they've reduced complexity because each service is so simple. Yet all they've done is move the complexity into the operational layer, where it's harder to deal with. Gerald Weinberg is a fun writer in this space. 4. In many organisations, a lot of people's salaries depend on their ability to add complexity, especially to processes but also to code. If you are working within such an organisation, you will have a Sysiphian task until you solve the organisational problem. Whether you can solve this problem depends on how much influence you have. This is why "skunkworks" projects so often work until they are re-integrated into the mainstream. 5. Once you've sorted out the organisational complexity, separated the inherent and accidental complexity, you'll be most of the way there. Keep reviewing and challenging everything. Complexity is a weed that just seems to grow unless you constantly tend to the garden.

elcapitan 5y ago
Any recommendations re: Weinberg and complexity? I've read his book on consulting, which was really well written.
- kqr 5y ago
  He has a whole series on Quality Software which, admittedly, I only came about a third of the way through before I took a break for other books, but it has contained some useful analysis so far. I do plan on picking it up again once I'm done with my current read.
webmaven 5y ago
> For example, we had an important user still on a legacy browser because they couldn't afford to upgrade their old laptop. Instead of adding a complicated legacy layer, we bought them a new laptop. I'm curious about the specifics regarding the combination of "important user" and "couldn't afford to upgrade". Was the user's importance social rather than financial? Were the hardware requirements particularly hefty?

bobm_kite9 5y ago

I touch on both these perspectives in my book ‘Risk-First Software Development’. You can read all it online at https://riskfirst.org https://riskfirst.org if you want. Hope this is useful to you.

andreskytt 5y ago

https://link.springer.com/chapter/10.1007/978-981-15-5856-6_7 https://link.springer.com/chapter/10.1007/978-981-15-5856-6_... Has a bunch of useful references. Olivier de Weck of the MIT held an awesome conference speech at the 2016 MIT SDM Conference explaining sources, metrics and cost of organizational complexity linked to engineering complexity. Sadly, the video no longer appears online. But the work of him and his group (references in the article above) is highly relevant to your question.

froh 5y ago

At an organizational level, Donald Reinertsen "the principles of product development flow" is outstanding. https://books.google.de/books/about/The_Principles_of_Product_Development_Fl.html?id=1HlPPgAACAAJ&source=kp_book_description&redir_esc=y https://books.google.de/books/about/The_Principles_of_Produc... It motivates small batch sizes, decision making at ground level, short cycle times, all the mechanics behind kanban, scrum, XP, without ever using any of their jargon. And it moves up into economics by explaining e.g. cost of delay as a metric guiding useful decision making. The book eatablishes a wonderful shared understanding of the principles underlying lean and agile, why they work and how to make them work, shared understanding between engineering and management.

deltaonefour 5y ago

Written by the authors of sicp: https://mitpress.mit.edu/books/software-design-flexibility https://mitpress.mit.edu/books/software-design-flexibility Organization is just a name for a group of methodologies. Ultimately what we want is the right way to organize programs for maximum flexibility.

adamddev1 5y ago
I really like that tagline, "How to avoid programming yourself into a corner." Sometimes I've made stuff that I've hacked and hacked together until it barely works and it feels like you're just straining harder and harder to get it workable and then there's this sinking feeling of, "oh dear, I can never touch or change this or everything will crumble into an irreparable mess." Learning the SICP/HTDP way of creating a "language" to handle your problem with changed everything for me. It helps you to clearly lay out and work with the particular kinds of operations that your problem (and its variations) require. As Hal Abelson explains in this podcast: [1] > So you really take the attitude that, boy if I’m writing something complex, I need to think about what I’m doing as if I’m writing a language. Or just say that a little less onerously. When I think about the operations I want to produce in any kind of program I’m writing, I don’t want to think about only that particular problem I’m doing right then. I want to carve out a space that’s broad enough that I could be doing that particular problem and lots of variations and lots of similar ones. [1]: https://corecursive.com/039-hal-abelson-sicp https://corecursive.com/039-hal-abelson-sicp
- deltaonefour 5y ago
  Agreed. That tagline is what entire corporations do. They program their entire ecosystem into a corner and it demands an entire rewrite or refactor.

triebelf 5y ago

I found this one very good: A Philosophy of Software Design https://www.amazon.com/dp/173210221X https://www.amazon.com/dp/173210221X

zonovar 5y ago

The Pragmatic Programmer https://www.amazon.co.uk/Pragmatic-Programmer-Andrew-Hunt/dp/020161622X https://www.amazon.co.uk/Pragmatic-Programmer-Andrew-Hunt/dp...

KingOfCoders 5y ago

First keep it simple, shameless self plug: https://www.radicalsimpli.city/ https://www.radicalsimpli.city/

AussieWog93 5y ago

At least from where I'm at (ex-SWE, quit at a relatively junior level), I'm not sure this is something you can read about and reason logically. It's something you need to a feel for through experience.

fulafel 5y ago

Do you want to find out about managing a bad case of complexity in an existing project? Or are you searching for ways to avoid getting into a bad place with sw complexity and looking for even radical simplicity because you are determinde to avoid (or can't afford) complexity? These are quite different missions since it's rarely possible to recover form complexity if you've already gone there.

david_allison 5y ago

Michael C. Feathers - Working Effectively with Legacy Code Scott Wlaschin - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

rmetzler 5y ago
Eric Normand - Grokking Simplicity: Taming complex software with functional thinking I also bought the Scott Wlaschin book, but I must say I like Eric Normand's book a little bit better. Since the examples are also in JavaScript (but applicable to a lot of languages), I think it's easier to follow for everyone who's coming from an OOP background. I'm also looking forward to Yehonathan Sharvit - Data-Oriented Programming: Unlearning objects.

rramadass 5y ago

I think it is worthwhile to first look into the fields of Complexity Science/Complex Systems Science and Systems Thinking/Systems Theory for overarching insights : [ https://en.wikipedia.org/wiki/Complex_system https://en.wikipedia.org/wiki/Complex_system and https://complexityexplained.github.io/ https://complexityexplained.github.io/ ] and [ https://en.wikipedia.org/wiki/Systems_thinking https://en.wikipedia.org/wiki/Systems_thinking and https://thesystemsthinker.com/systems-thinking-what-why-when-where-and-how/ https://thesystemsthinker.com/systems-thinking-what-why-when... ] For Software specific issues i highly recommend David Parnas' collected papers in the book Software Fundamentals. He and his colleagues defined much of what is mainstream in today's Software Architecture/Organization practice. Finally, the case studies given here are a great source of insights: https://aosabook.org/en/index.html https://aosabook.org/en/index.html

kqr 5y ago
Am I doing something wrong if I'm unable to find that Parnas collection as a digital book? I've read some of his papers and they were very influential on me. Would love the book but I rarely have the energy to bring a print copy of books.
- rramadass 5y ago
  In this case the "paper copy" of the book is very much worth it :-) The articles are all foundational, timeless and gets to the heart of the matter unlike most books today.

rrrodia 5y ago

It's a long shot, but is anyone aware of useful MOOCs that cover this topic?

bkgh 5y ago

Object Thinking by David West

Ozzie_osman 5y ago

- Philosophy of Software Design (great short read packed with insight) - Mythical Man-Month (the classic, a little outdated but the principles still ring very true) - Software Engineering at Google (thoughts from a company that has spent a lot of time thinking about this at scale)

glintik 5y ago

Best book is task description how to add small feature to your project. If it’s still clear and easy, then you don’t need to read any books about software complexity management ).

sedeki 5y ago

This is a book that focuses on managing software complexity and to "avoid painting oneself into a corner": https://mitpress.mit.edu/books/software-design-flexibility https://mitpress.mit.edu/books/software-design-flexibility

zenkat 5y ago

OP here. Thank you for all of the great suggestions! I've compiled all the references into this spreadsheet: <https://docs.google.com/spreadsheets/d/1kgFSWp7rM3ZegweXAoMN-4Hv88sNS--xUuDnHp6IftQ/edit https://docs.google.com/spreadsheets/d/1kgFSWp7rM3ZegweXAoMN...> From my perspective, the top "must-reads" are: -- John K Ousterhout, A Philosophy of Software Design -- Titus Winter (et al), Software Engineering at Google -- Hanson and Sussman, Software Design for Flexibility Other interesting titles that caught my eye: -- Peter Naur, Programming as Theory Building -- Scott Wlaschin, Domain Modeling Made Functional -- Yehonathan Sharvit, Data-Oriented Programming: Unlearning objects (upcoming) -- Nick Tune, Patterns, Principles, and Practises of Domain Driven Design -- Robert L. Glass, Facts and Fallacies of Software Engineering -- Donald Reinertsen, The Principles of Product development Flow -- Eric Normand, Grokking Simplicity

bradleysmith 5y ago

Not a book, but this paper “big ball of mud” has resonated with me in describing troubles I’ve faced before, and has me coming back to it as I run into new architectural problems where I’m not confident in my/our approach. http://www.laputan.org/mud/ http://www.laputan.org/mud/

tq-qv 5y ago

The "original" Scrum book https://read.amazon.com/kp/card?asin=0130676349Q&preview=inline&linkCode=kpe&ref_=dbs_a_def_rwt_bibl_vppi_i2 https://read.amazon.com/kp/card?asin=0130676349Q&preview=inl... Stuff on lean manufacturing (yes. manufacturing!) https://www.amazon.de/dp/B000SEGIVS?ref_=cm_sw_r_kb_dp_ocvTDbQPS1EGA&tag=kp0508-21&linkCode=kpe https://www.amazon.de/dp/B000SEGIVS?ref_=cm_sw_r_kb_dp_ocvTD... https://www.amazon.de/dp/B002LHRM2O?ref_=cm_sw_r_kb_dp_I9SSDb704MDTV&tag=kp0508-21&linkCode=kpe https://www.amazon.de/dp/B002LHRM2O?ref_=cm_sw_r_kb_dp_I9SSD...