3 ms·

Articles on software architecture are extremely boring. HN tends to vote up articles that are eye-catching and fun to read. Software architecture is focused on

Articles on software architecture are extremely boring. HN tends to vote up articles that are eye-catching and fun to read. Software architecture is focused on giving advice about things that are peripheral to programming, so by nature they are not lively reading if you not steeped in it. And it is opinions. It's all arbitrary, and it changes with the latest fad. Not least, it is patronizing. It's like getting a lecture on proper handwriting or the correct pronunciation of words, and being grimly informed that half of your letters are written incorrectly, and this is unacceptable and must change. Frankly, HN would have to change culture entirely to cover design advice, and I would stop reading.

mtdewcmu 12y ago
Replying to myself/no edit link: The kicker about software architecture is that it gives bad advice about writing software. Now, it's true, the individual bits of advice are all over the map. They don't all agree. But the premise was to prevent bad code from getting written by syntax changes and style conventions, hopefully stopping bad practices in their tracks and encouraging good practices in their place. I think the premise failed -- bad code hasn't stopped -- but the experiment continues, and the net sum of all the advice and conventions has been to encourage more complexity and more code, while simplicity is what yields good software.
- mattgreenrocks 12y ago
  Which is why simplicity remains the ultimate sophistication in software architectures. At some point, you cannot continue writing code without structure. Then you slowly and deliberately introduce meaningful abstractions along the necessary dimensions. And no more. Abstractions are also useful to separate the arrangement of work from the actual work itself. These boundaries are useful for dividing up work among colleagues.
  - mtdewcmu 12y ago
    Knuth argues that programming is a form of writing. I agree. Therefore, you should organize code like a book or article, since those are forms of writing that have benefitted from centuries of use and refinement. Even books and articles on complex subjects are fairly light on structure.
  - mtdewcmu 12y ago
    Not sure if you'll come back and read this, but here's my current theory on structure. In a piece of software, there are many schemes by which you might organize the source code: - Organize by author of code - Organize by chronological order of appearance (e.g. what version or patch # this appeared in) - ... by order of execution (of course, this is only a partial order) - ... by library - ... by importance - ... by some arbitrary property of the code (by algorithm, by what data it touches, etc.) Each one makes sense in a different context, and you can't have all at once. But you don't want to double-down on one choice at the expense of other, equally-valid choices with excess structure.

mtdewcmu 12y ago

Replying to myself/no edit link: The kicker about software architecture is that it gives bad advice about writing software. Now, it's true, the individual bits of advice are all over the map. They don't all agree. But the premise was to prevent bad code from getting written by syntax changes and style conventions, hopefully stopping bad practices in their tracks and encouraging good practices in their place. I think the premise failed -- bad code hasn't stopped -- but the experiment continues, and the net sum of all the advice and conventions has been to encourage more complexity and more code, while simplicity is what yields good software.

mattgreenrocks 12y ago
Which is why simplicity remains the ultimate sophistication in software architectures. At some point, you cannot continue writing code without structure. Then you slowly and deliberately introduce meaningful abstractions along the necessary dimensions. And no more. Abstractions are also useful to separate the arrangement of work from the actual work itself. These boundaries are useful for dividing up work among colleagues.
- mtdewcmu 12y ago
  Knuth argues that programming is a form of writing. I agree. Therefore, you should organize code like a book or article, since those are forms of writing that have benefitted from centuries of use and refinement. Even books and articles on complex subjects are fairly light on structure.
- mtdewcmu 12y ago
  Not sure if you'll come back and read this, but here's my current theory on structure. In a piece of software, there are many schemes by which you might organize the source code: - Organize by author of code - Organize by chronological order of appearance (e.g. what version or patch # this appeared in) - ... by order of execution (of course, this is only a partial order) - ... by library - ... by importance - ... by some arbitrary property of the code (by algorithm, by what data it touches, etc.) Each one makes sense in a different context, and you can't have all at once. But you don't want to double-down on one choice at the expense of other, equally-valid choices with excess structure.