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

A Philosophy of Software Design

web.stanford.edu

Post reply on HN
Print view View original

71–80 of 116 posts

Re: A Philosophy of Software Design

#71

Post by simplegeek »

cc_ashby wrote: post #5

[redacted] are my favorite people on complexity. [redacted] was notably my professor for operating systems @ [redacted]. He taught not just ways to design software, but also ways to live. [redacted]’s work is also directly influenced by [redacted], as referenced at the end of his article. For [redacted], I suggest looking at the class website: [redacted] For [redacted], I suggest his book, [redacted]

> He taught not just ways to design software, but also ways to live.

Mind sharing his insights on ways to live?

Re: A Philosophy of Software Design

#72

Post by xoac »

corethree wrote: post #58
xoac wrote: post #37

Earlier quoted context omitted.

You seem to think that this is some sort of battle between the wordcels and the shape rotators or whatever, it's not. Extremely smart people have been in these fields for thousands of years and they didn't think that math and philosophy are opposites or in some tension. Even a cursory familiarity with the history of math and philo will reveal this.

>Extremely smart people have been in these fields for thousands of years and they didn't think that math and philosophy are opposites or in some tension. Even a cursory familiarity with the history of math and philo will reveal this. Yeah it was actually progress when the field largely separated the philosophical mumbo jumbo away from the pure math. In the past math text books were littered with this mumbo jumbo beca…

I studied philosophy at a department with an analytic slant. So essentially with philosophers who have a hardon for math and science. Still, even there people were not talking nonsense like this.

Pure math is really nice, but there are so many aspects of human activity where this math is just totally useless. This is where we have to use the fuzzy words and stuff and where rigorous interpretation that you get trained in philosophy and other wordcel departments comes useful.

I really encourage you to engage with some history of philosophy. You'll probably enjoy it and maybe change some of your views. Maybe try some history of science?

Re: A Philosophy of Software Design

#73

Post by marcosdumay »

glun wrote: post #38
laurent_du wrote: post #21

Earlier quoted context omitted.

If I ask my kids or my girlfriend to review my code, nothing will be obvious to them. Doesn't mean that my code is the problem. The idea that the reviewer is always right makes no sense.

Your family is not the intended audience for the code. If the reviewer isn’t either, then they have no business reviewing your code.

I can agree with that. But the intended audience for your code isn't as rigid and formalized a thing as review processes make the reviewers identities.

That actually means that review processes are usually wrong. But then, people experiences are about the wrong process, and that's what they react on.

Re: A Philosophy of Software Design

#74

Post by nlitened »

hu3 wrote: post #48
synthc wrote: post #40

Earlier quoted context omitted.

static typing is a way to manage complexity, Rich Hickey is about avoiding complexity

But there's no way to completely avoid complexity. So tools to manage complexity are welcome in my toolbox.

Tools have their defined use cases. If you use the same tool in all cases, you’re probably misusing it.

Re: A Philosophy of Software Design

#75

Post by danielovichdk »

"There is a new chapter 'Decide What Matters' that talks about how good software design is about separating what's important from what's not important and focusing on what's important."

I can almost hear the noise of team members arguing what's important and what's not.

This book is on my list I wanted to read for some time.

Re: A Philosophy of Software Design

#77

Post by Chris_Newton »

DoingIsLearning wrote: post #22
mparnisari wrote: post #7

His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.

I think the issue is _when_ you make the review. Psychologically suggesting a breaking change after someone invested in a bunch of tests and verification will raise their defenses up. I think there is value in doing a review (specially with junior team members) on their 'design intent' early on, as soon as a prototype/skeleton is up. Proposing a change then is met with a lot less friction.

Many years ago, I was on a working group looking at different ways to improve quality within a fairly large software development company. One of the most useful ideas the consultants brought to the table was that we should have “technical reviews” at key stages in the development process. The arguments back then were much the same as they are today: identify potential problems the original developer missed, share interesting ideas in time to consider and use them, making changes earlier is usually easier and cheaper, etc.

Today code reviews have become common practice, which is definitely a change for the better, but I rarely see assets like specs or design work reviewed with the same consistency and attention to detail. If anything, the trend has been to minimise formal requirements capture and to reduce or eliminate any kind of up-front design work, as if there is some kind of bizarre dichotomy where the only amounts of time you can invest in these activities before starting to write code are measured in either months or minutes. I believe this is a mistake that often leads to avoidable wasted work and tech debt.

Re: A Philosophy of Software Design

#78

Post by agumonkey »

mparnisari wrote: post #7

His book is awesome! One takeaway I had: code reviews matter. If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious.

good point but it's culture dependent

i had people telling me

   d = {i:str(i) for i in range(10)}
was too hard to read, preferring

    d = {}
    for i in range(10):
        d[i] = str(i)

Re: A Philosophy of Software Design

#79

Post by Ecoste »

anononaut wrote: post #67

I can't at all agree with the added differences of opinion with Uncle Bob's Clean Code. The author argues a reducing the size of a function of "a few dozen lines" likely won't improve the readability of the code. That's not even defensible! I would fail any (professional) code review for having that many lines of code in a function. It's a complete failure of abstraction. He later goes on to say "more functions means…

> The author argues a reducing the size of a function of "a few dozen lines" likely won't improve the readability of the code. That's not even defensible! I would fail any (professional) code review for having that many lines of code in a function.

I would argue that such absolutist rules are harmful. Yeah, there certainly are times when smaller functions are better. But there are times where separating a function into smaller ones does indeed make it 'harder' for me to read, since with each 'abstraction' you're losing context/details that might be very relevant in the code to follow. I would rather have a 40 line function with the dirty low-level details rather than the same split over 50 lines of different functions that I need to go into and figure out the details.

And then again, who is to decide what is 'one abstraction'? Abstractions can be at different levels, and abstracting different things. There really isn't an objective way to do it. I would argue that this is analogous to writing -- there are all kinds of books/stories/poems, short and long etc. and one isn't necessarily better than another.

Re: A Philosophy of Software Design

#80

Post by speed_spread »

Not directly related but there's a recent three-hour interview of Dave Cutler (main architect of OpenVMS and Windows NT) where he mentions giving money for a university computer lab to his name, and requesting that on one of the wall be painted in large letters "If you don't put it in, you won't have to take it out."
Post reply on HN