Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Best books on managing software complexity?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 127 posts

Re: Ask HN: Best books on managing software complexity?

#61

Post by kqr »

elcapitan wrote: post #37
rTX5CMRXIfFG wrote: post #11

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?

It doesn't even have to be nature -- I learned a lot about managing complexity from The Death and Life of Great American Cities which is about city planning!

Re: Ask HN: Best books on managing software complexity?

#62

Post by exclipy »

Scarblac wrote: post #55
urthor wrote: post #12

Earlier quoted context omitted.

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).

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 pre…

> 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

This shift away from unit tests is the corollary to Ousterhout's preference for deep modules.

Re: Ask HN: Best books on managing software complexity?

#63

Post by fulafel »

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.

Re: Ask HN: Best books on managing software complexity?

#64

Post by elcapitan »

kqr wrote: post #61
elcapitan wrote: post #37

Earlier quoted context omitted.

The nature approach sounds intriguing, any pointers on where to start or what to read?

It doesn't even have to be nature -- I learned a lot about managing complexity from The Death and Life of Great American Cities which is about city planning!

Ah, Jane Jacobs.. had that in my reading list for a very long time, but that's an interesting point with regards to complexity .. thanks!

Re: Ask HN: Best books on managing software complexity?

#65

Post by majkinetor »

kqr wrote: post #27

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…

> 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...

Re: Ask HN: Best books on managing software complexity?

#67

Post by SideburnsOfDoom »

kqr wrote: post #14

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.

This book: 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.

Re: Ask HN: Best books on managing software complexity?

#68

Post by Scarblac »

exclipy wrote: post #62
Scarblac wrote: post #55

Earlier quoted context omitted.

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 pre…

> 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 This shift away from unit tests is the corollary to Ousterhout's preference for deep modules.

It wasn't a direct quote, but an idea I've heard repeated many times.

And integration tests are nice, but the idea of testing small units was that every branch in the code under test doubles the number of possible execution paths, so tmit becomes harder and harder to test every path.

So we should branch less, I guess. His parts about "define errors put of existence" and writing more general code with fewer obscure details would probably help.

Post reply on HN