51–60 of 127 posts
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.
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…
Written by the authors of sicp: 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.
> 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.
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 abo…
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.
I enjoyed "A philosophy of software design" by John K Ousterhout 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
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).
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.
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 p…
The nature approach sounds intriguing, any pointers on where to start or what to read?
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.
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 abo…
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 h…
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.
Earlier quoted context omitted.
The nature approach sounds intriguing, any pointers on where to start or what to read?
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 tha…
But looking at something personal and concrete like exercise makes total sense, thanks!
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…
Any recommendations re: Weinberg and complexity? I've read his book on consulting, which was really well written.
Domain Driven Design by Eric Evans
The Evans book is sort of written backwards, in that it starts with a bunch of powerful tactical tools and people stop reading halfway through which means now all they have is a hammer.
The PPPoDDD book instead starts out with reasoning about when DDD is appropriate and when it's not, to dive into the tactical patterns last, once the other options are eliminated. I think that approach makes much more sense.
After all, most of the skill in a technique consists in knowing when to apply that technique, and, critically, when not to.
The PPPoDDD book also places a heavy emphasis on having productive conversations with businesspeople as a design tool. I think Evans accidentally underemphasises that too.