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

Holding a Program in One's Head (2007)

paulgraham.com

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Holding a Program in One's Head (2007)

#31

Post by nnq »

> Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable.

...reread the whole thing and this thing got my imagination "high" ...I feel there's some deep wisdom in here ...maybe we do thing wrong in most of our organizations by requiring complex components like people to be interchangeable, instead of accepting the fact that they are not and that the "personality" of an organization should be allowed to radically change as people (or bigger "unique" subsystems) become part of it or leave it... maybe we could even end up with what Nassim Taleb calls "antifragile" organizations...

Re: Holding a Program in One's Head (2007)

#32

Post by saraid216 »

nnq wrote: post #23

You should never need to hold the entire program in your head ! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" ( http://www.laputan.org/mud/ ). Now…

I've noticed that, beyond a certain point, the term "program" is not actually very useful. Because it's open on the other window, is Facebook a program? Is the news feed a program? The buddy list? The chat features? The photo upload? The status update?

How about the API? Is that a program?

I could easily say that my scripts are programs. They're rarely more than a file large. But "program" is not a descriptive term for them; I say "script" because that explains that they are not services. They run once, do their job, and finish. Or something.

At work, I have a domain focus. There are swaths of code I own, and other swaths that my domain has strong and weak connections to. I know my domain. I can boot it up in my head at will, though it's too large to stick: I have to walk through each room independently, rather than having some manifold presence in every room. And there are a ton of things that I have to look up every time, because I don't actively work on those pieces. But there's no clear division at which I can say, "This is the program. I should put it all in my head."

We just remember everything that we can, and try to remember where to find out everything that we can't. I think that's reasonable.

Re: Holding a Program in One's Head (2007)

#33

Post by saraid216 »

nnq wrote: post #31

> Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable. ...reread the whole thing and this thing got my imagination "high" ...I feel there's some deep wisdom in here ...maybe we do thing wrong in most of our organizations by requiring complex components like people to be interchangeable, instead of accepting the fact that they are not a…

It's not just the "personality", though. It's also the idea that if your sysadmin gets hit by a bus, your site doesn't become unusable.

Re: Holding a Program in One's Head (2007)

#34

Post by nnq »

saraid216 wrote: post #33
nnq wrote: post #31

> Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable. ...reread the whole thing and this thing got my imagination "high" ...I feel there's some deep wisdom in here ...maybe we do thing wrong in most of our organizations by requiring complex components like people to be interchangeable, instead of accepting the fact that they are not a…

It's not just the "personality", though. It's also the idea that if your sysadmin gets hit by a bus, your site doesn't become unusable.

yep, the compromise is probably to separate maintenance from creative tasks, and accept that maintenance tasks need replaceable components, but then again, maybe it's ok to accept things like having a certain software component written by a "lone wolf eccentric genius" in a dialect of lisp he alone can understand (replace with your fav equivalent phrase) as the price for having really unique features and performance for that component that no competitor can match, and make contingencies for the risk of having to throw away that codebase and rewrite from scratch if he gets hit by a bus... maybe if the APIs and interfaces are properly designed (or processes or however else you may call then in peopleware land), you can accept working with unique and not easily replaceable components and somehow design systems that are architected to embrace the "hit by a bus" type of risks

...and if I think further along these line, the organization that can best afford these types of risks are big software corporations (think Google, Microsoft) that could afford to scrap entire codebases and projects (if they ever got over the "mind brakes" that make the managers consider such things insane), or start things in completely new directions when they bring new "genius visionaries" ...these types of innovation based on risky and irreplaceable components/people would be prohibitively expensive or impossible for start-ups, but may bring us new breakthroughs in things like general purpose AI or god know what

...maybe true progress really is the work of unique individuals and our whole focus on "team work" and "replaceable peopleware" is what suffocates and kills innovation

Re: Holding a Program in One's Head (2007)

#35

Post by Spearchucker »

Warning: controversy.

The text misses the point in that having to hold a program in one's mind is not required to begin with.

The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution, or at the component level, where one specific aspect is dealt with.

That minimizes the amount of stuff the programmer needs to hold in his head. If you find yourself oscillating between higher and lower levels of abstraction you should probably be revisiting your architecture.

It's called separation of concerns.

No tool improvement is going to solve that. Neither will a rethink of ways of working.

Re: Holding a Program in One's Head (2007)

#36

Post by batgaijin »

Spearchucker wrote: post #35

Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution…

What about Haskell? The type system tells you exactly what's going on.

Re: Holding a Program in One's Head (2007)

#37

Post by ippisl »

dualogy wrote: post #30
ippisl wrote: post #25

Earlier quoted context omitted.

One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them. [1] http://en.wikipedia.org/wiki/Controlled_natural_language

This is so cool. Follow-up question: > There's even some work to encode legal knowledge using them Where do I learn more about this? What's the name of that language, or research project, or...?

i just did a google search for : "controlled natural language" legal , and got some results.

Re: Holding a Program in One's Head (2007)

#38

Post by daniel-cussen »

nnq wrote: post #23

You should never need to hold the entire program in your head ! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" ( http://www.laputan.org/mud/ ). Now…

Holding the entirety of the problem in your head is a necessity when the program is an algorithm, and especially if its a hermetic algorithm.

Re: Holding a Program in One's Head (2007)

#39

Post by chubot »

Spearchucker wrote: post #35

Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution…

That's begging the question. To come up with the abstractions in the first place requires understanding the whole problem. There's no getting around this.

I can't tell you how many programs I've seen where the wrong abstraction is never perturbed, and as a result all feature development pays a huge cost in reliability and functionality.

To create or change an abstraction, you have to get your mind around all sides of it. That requires A LOT of context. You should always be "revisiting your architecture". It's basically never true that the first architecture works, unless you've written an extremely similar program before. The worst programs result when people are afraid to shift boundaries. That happens a lot in big company development that PG talks about -- each team just accumulates crud on their side of the abstraction boundary, but they never talk to each other so they can globally simplify.

It's true that abstraction reduces complexity, and thus is the only way you can build big programs, but it takes a lot of hard work to get there.

Re: Holding a Program in One's Head (2007)

#40

Post by Spearchucker »

chubot wrote: post #39
Spearchucker wrote: post #35

Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution…

That's begging the question. To come up with the abstractions in the first place requires understanding the whole problem. There's no getting around this. I can't tell you how many programs I've seen where the wrong abstraction is never perturbed, and as a result all feature development pays a huge cost in reliability and functionality. To create or change an abstraction, you have to get your mind around all sides of…

The "whole problem" is simply a process. Processes in the real world are composed of 1-* sub-processes, and ultimately distill down into transformations (input -> transformation -> output).

You don't need to understand every low-level process to make a start.

You raise two interesting points though. Yes, revisiting an architecture is required when you've not solved a similar problem before. Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others.

Sure, that means doing some work before writing code which seems decidedly unpopular these days. It's a free world.

You also say that it's a lot of hard work. Yes. Nothing worth doing is easy.

[Edit] There's a really good book (there always is) that describes complexity and problem solving better than any other I've found. http://www.amazon.com/dp/0787967653

Post reply on HN