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

111–120 of 127 posts

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

#111

Post by kqr »

CyberDildonics wrote: post #109
kqr wrote: post #105

Earlier quoted context omitted.

Software is automation. By relying less on automation, your software is less complex. That's a way to manage software complexity organisationally.

This is like someone asking how to build a simpler house and your answer is to tell them to live in the woods. If someone is trying to design a better plane, it doesn't make sense to tell them to just convince everyone asking for a better plane to stop traveling. It is nonsense and seems like you have unrelated ideas that you are trying to shoehorn into this question.

That's not how I see it. Imagine for a moment that we had an epidemic where every family just had to build a five-story mansion complete with service buildings to feel like they keep up with the Joneses.

That's what I see a lot of in software right now.

I'm merely suggesting that maybe a regular two-story family house is enough. Maybe even one story, depending on needs.

Note that only the first sentence of my comment said "don't automate". The other eight described a way to automate with less complexity when you have to.

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

#112

Post by deltaonefour »

adamddev1 wrote: post #53
deltaonefour wrote: post #48

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.

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…

Agreed. That tagline is what entire corporations do. They program their entire ecosystem into a corner and it demands an entire rewrite or refactor.

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

#113

Post by CyberDildonics »

kqr wrote: post #111
CyberDildonics wrote: post #109

Earlier quoted context omitted.

This is like someone asking how to build a simpler house and your answer is to tell them to live in the woods. If someone is trying to design a better plane, it doesn't make sense to tell them to just convince everyone asking for a better plane to stop traveling. It is nonsense and seems like you have unrelated ideas that you are trying to shoehorn into this question.

That's not how I see it. Imagine for a moment that we had an epidemic where every family just had to build a five-story mansion complete with service buildings to feel like they keep up with the Joneses. That's what I see a lot of in software right now. I'm merely suggesting that maybe a regular two-story family house is enough. Maybe even one story, depending on needs. Note that only the first sentence of my comment…

Imagine for a moment

I think this is the problem - you are imagining a question that isn't being asked by telling someone to just not make that problem.

This person asked for book on managing complexity. You are saying 'just don't make software as complex and do it by not making software at all'. That is two steps removed from being any sort of answer to this question.

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

#114

Post by kqr »

CyberDildonics wrote: post #113
kqr wrote: post #111

Earlier quoted context omitted.

That's not how I see it. Imagine for a moment that we had an epidemic where every family just had to build a five-story mansion complete with service buildings to feel like they keep up with the Joneses. That's what I see a lot of in software right now. I'm merely suggesting that maybe a regular two-story family house is enough. Maybe even one story, depending on needs. Note that only the first sentence of my comment…

Imagine for a moment I think this is the problem - you are imagining a question that isn't being asked by telling someone to just not make that problem. This person asked for book on managing complexity. You are saying 'just don't make software as complex and do it by not making software at all'. That is two steps removed from being any sort of answer to this question.

I don't see it that way. When I have had trouble managing complexity, I have been happy for advice on how to reduce it going forward.

Step one to solving a problem is often to find a technique by which time is no longer stacked against you. Then you can attack the other thing in peace.

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

#115

Post by CyberDildonics »

kqr wrote: post #114
CyberDildonics wrote: post #113

Earlier quoted context omitted.

Imagine for a moment I think this is the problem - you are imagining a question that isn't being asked by telling someone to just not make that problem. This person asked for book on managing complexity. You are saying 'just don't make software as complex and do it by not making software at all'. That is two steps removed from being any sort of answer to this question.

I don't see it that way. When I have had trouble managing complexity, I have been happy for advice on how to reduce it going forward. Step one to solving a problem is often to find a technique by which time is no longer stacked against you. Then you can attack the other thing in peace.

I have been happy for advice on how to reduce it going forward.

You didn't do that, your solution was 'don't write software'.

If someone asks for tips on organizing their kitchen and without knowing anything more than that, you say 'make your kitchen smaller and don't use your kitchen' do you think that is reasonable advice?

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

#116

Post by kqr »

CyberDildonics wrote: post #115
kqr wrote: post #114

Earlier quoted context omitted.

I don't see it that way. When I have had trouble managing complexity, I have been happy for advice on how to reduce it going forward. Step one to solving a problem is often to find a technique by which time is no longer stacked against you. Then you can attack the other thing in peace.

I have been happy for advice on how to reduce it going forward. You didn't do that, your solution was 'don't write software'. If someone asks for tips on organizing their kitchen and without knowing anything more than that, you say 'make your kitchen smaller and don't use your kitchen' do you think that is reasonable advice?

Not writing as much software will result in reduced complexity going forward.

Sure, if someone built tens of industrial kitchens every month for regular families and just in the middle of nowhere (which is what i see a lot of in software) and then asked "how can I reduce my kitchen expenses" I would suggest "how about going forward you make your kitchens smaller and don't build them at all where nobody uses them?"

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

#117

Post by CyberDildonics »

kqr wrote: post #116
CyberDildonics wrote: post #115

Earlier quoted context omitted.

I have been happy for advice on how to reduce it going forward. You didn't do that, your solution was 'don't write software'. If someone asks for tips on organizing their kitchen and without knowing anything more than that, you say 'make your kitchen smaller and don't use your kitchen' do you think that is reasonable advice?

Not writing as much software will result in reduced complexity going forward. Sure, if someone built tens of industrial kitchens every month for regular families and just in the middle of nowhere (which is what i see a lot of in software) and then asked "how can I reduce my kitchen expenses" I would suggest "how about going forward you make your kitchens smaller and don't build them at all where nobody uses them?"

No one asked if they "should write software they don't need".

You are answering a question that no one would ever ask and you can't answer it because you don't have any other information other than the actual question that was asked.

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

#118

Post by urthor »

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.

In my experience, honestly the advantages of a unit testing suite are extremely minimal depending on your integration test runtime.

However, they're a good tool if for example you're working with a Big Data system, where an end to end integration test will necessarily take an extraordinary amount of time.

For my first job out of school in Apache Spark they were absolutely brilliant. For my current codebase? Not so much.

However, TDD just reduces the number of mistakes I make by an umpteenth amount.

Just because it breaks my code up into extremely short subroutines so I screw up less. Plus writing the unit test itself is a brilliant way to "measure twice, cut once."

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

#119

Post by derangedHorse »

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.

I disagree that most tests should be integration tests. He seems to dismiss them in the article because of his experience with diminishing returns with test coverage and tests that test implementation details which basically means the tests aren’t made correctly and/or targeted at the right areas. He also seems to dismiss the pyramid rather quickly without giving a good reason against it (unit tests are quicker to run and cheaper to implement). This is not to say we should ignore integration tests entirely (or e2e tests for that matter), just that a shift to the traditional guidance is still valid.

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

#120

Post by bradleysmith »

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/

Post reply on HN