9 ms·

Another quote of his; "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your

by hcrisp 4y ago

Another quote of his; "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975) Stated a different way: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -Linus Torvalds

wodenokoto 4y ago
In reality though the tables are going to be like: Column named “price_usd_incl_tax” is neither in usd nor does it include all taxes.
- javawizard 4y ago
  Which is exactly what Linus' quote is about.
- dt3ft 4y ago
  This hits home. Not only in databases, but also in code.
- quickthrower2 4y ago
  It used to mean that, but a programmer changed the meaning. They could. (a) rename the column, be the guy who broke the system and spend all weekend trying to fix 6 systems he never knew existed, written in Access, Excel, Crystal Reports, VB6, Delphi and a CMD file on a contractors laptop. (b) keep the column name, deliver the feature, go home.
  - pif 4y ago
    There's no point in keeping the same name so that a system can keep running, if the data meaning has changed. Bad programmers chose (b). Good programmers choose (a). Better programmers refuse the change request.
    - deleted 4y ago
      [deleted]
  - ilyt 4y ago
    If data meaning changed tho those 6 systems would break too, no ?
    - throwaway39978 4y ago
      It might not be math-related; could be something as simple as a requests table being named to indicate that api X was used and now it uses API y and there is some reporting on that somewhere that doesn't care which API was used. Ideally the table would have been named more generically but in an earlier stage startup there will be mistakes in naming things no matter how hard you try to avoid that. So the only thing that actually breaks here is that a small number of engineers that care about this might misinterpret what it means unless they learn the appropriate tribal knowledge. Ideally it gets fixed but if you look at all of the things that can be improved in an early stage startup, this kind of thing is pretty minimal in importance so it becomes tech debt.
      - maaarghk 4y ago
        Anyway, where were we? Oh yeah - RIP Fred Brooks.
  - Ma8ee 4y ago
    I really hope you are joking 100%, because (b) Go home and be happily oblivious that six other systems silently started to produce wrong results since the meaning of the column has changed. But, of course, that is someone else’s problem, some other day, when several months of reports and forecasts have to be recalled and updated.
  - js8 4y ago
    That's why you should also have comments, and maintain them. Then if the name is hard to change, you can at least document the new semantics.
  - deniska 4y ago
    We prefer option c: add a new table/column with similar looking name. Then few years later start wondering why there're two almost identical entities, and why one of them behaves weirder than another.
  - quickthrower2 4y ago
    To be clear I am pointing out incentives to make a worse choice, rather than the better choice.
- retSava 4y ago
  Don't worry, the code is self-documenting. /s Self-documenting code (what I take in practice means "no comments"-culture) is something I don't understand how it can work, never seen a good implementation of it. It _can_ be successful in describing the _what_ but is poorly or not at all describing the _why_. Perhaps I'm in the wrong domain for that though.
  - the-smug-one 4y ago
    The why should be clear from the domain that you're working within. A line of comment should count as something like 10 lines of code, if you're reading a comment then you're treading into real complexity. If you're in a code base where that isn't true, then is the comment really necessary? Fairly hot take from me, life is more ambiguous than that :-).
    - saiya-jin 4y ago
      Unless you are in some trivial startup domain, real domains (TM) have almost fractal-level complexities if you dig deep enough, corner cases, sometimes illogical rules etc. The "why" is still very much needed since it can have 10 different and even conflicting reasons, and putting it in the code in appropriate amount shows certain type of professional maturity and also emotional intelligence/empathy towards rest of the team. I mean, somebody has to be extremely junior to never experience trying to grok somebody's else old non-trivial code in situation when you need to deliver fix/change on it now. And its fairly trivial to write very complex code even in few lines, which some smart inexperienced juniors (even older, but total skill-wise still juniors) produce as some sort of intellectual game out of boredom.
      - eru 4y ago
        And even more important than the 'why' can be the 'why not'? Ie explanations for implementation choices that haven't been taken for various reasons.
      - rob74 4y ago
        > I mean, somebody has to be extremely junior to never experience trying to grok somebody's else old non-trivial code People are definitely capable of looking at someone else's code and saying "this crap is completely unreadable, we should rewrite it all", while at the same time believing that their own code is perfectly readable and self-documenting.
- bazoom42 4y ago
  In that case the code will probably also be difficult to read. In my experience, studying the database schema and IO data structures is indeed the best way to begin understanding a complex system.
- lucideer 4y ago
  This is only in the reality where nobody is shown the table. Showing things acts as a forcing function to fix the thing being shown
- mejutoco 4y ago
  At least you can grep that column name in the source code to find out where other taxes are calculated. Of course an ORM can further complicate this.
- lightbendover 4y ago
  I can just barely count the times I have seen a production failure due to someone assuming a millicent value from a column with ambiguous naming was in centicents or vice-versa.
zelphirkalt 4y ago
The Linus quote is ripe for misinterpretation. Not worrying about the code can lead to an unreadable mess, that ones future self or others will hate working with. So a really good programmer will probably rather go the Sussman way and realize, that programs are firstly meant to be read and only lastly meant to be run by a computer (paraphrasing here).
- citrin_ru 4y ago
  Designing good data structures is very important for code readability too. If you struggle to understand how given data structure is used / what it contains it would be hard to understand the rest of the code.
- Cthulhu_ 4y ago
  There's a lot of code out there that would improve massively with better data structures though. I mean I've waded through tons of code where the original author abused strings to indicate relationships in a table - a column with semicolon-separated values referencing other tables / rows. And a ton of code to check references. Mind you, that's more database design than data structures, but they're close enough for this example.
- lloeki 4y ago
  > The Linus quote I always attributed it to Rob Pike, but it turns out Pike's is following: > Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. > Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. https://users.ece.utexas.edu/~adnan/pike.html https://users.ece.utexas.edu/~adnan/pike.html Interestingly enough, the above link has this to say: > Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Which I guess references GP's excerpt. Also says this, which kinda loops back to Linus's way of saying it: > Rule 5 is often shortened to "write stupid code that uses smart objects".
atdrummond 4y ago
What if the table includes a poorly labeled column entitled “fiat@“?
- gilbetron 4y ago
  Underrated comment that would have been perfect if you said "labled"
mekoka 4y ago
While I agree with both quotes separately, I don't think that they necessarily mean the same thing. To me, the first (by Brooks) seems to be about grasping the domain model to understand what the system does (or can do) in general. Wheras the second (by Torvalds) seems to be about how best to organize data in code for efficient processing. Array, hash, tree, heap, etc and their associated access time complexity. The efficiency of your solution depends on your choice of a data structure that fits the local problem.

by hcrisp 4y ago

wodenokoto 4y ago

In reality though the tables are going to be like: Column named “price_usd_incl_tax” is neither in usd nor does it include all taxes.

javawizard 4y ago
Which is exactly what Linus' quote is about.
dt3ft 4y ago
This hits home. Not only in databases, but also in code.
quickthrower2 4y ago
It used to mean that, but a programmer changed the meaning. They could. (a) rename the column, be the guy who broke the system and spend all weekend trying to fix 6 systems he never knew existed, written in Access, Excel, Crystal Reports, VB6, Delphi and a CMD file on a contractors laptop. (b) keep the column name, deliver the feature, go home.
- pif 4y ago
  There's no point in keeping the same name so that a system can keep running, if the data meaning has changed. Bad programmers chose (b). Good programmers choose (a). Better programmers refuse the change request.
  - deleted 4y ago
    [deleted]
- ilyt 4y ago
  If data meaning changed tho those 6 systems would break too, no ?
  - throwaway39978 4y ago
    It might not be math-related; could be something as simple as a requests table being named to indicate that api X was used and now it uses API y and there is some reporting on that somewhere that doesn't care which API was used. Ideally the table would have been named more generically but in an earlier stage startup there will be mistakes in naming things no matter how hard you try to avoid that. So the only thing that actually breaks here is that a small number of engineers that care about this might misinterpret what it means unless they learn the appropriate tribal knowledge. Ideally it gets fixed but if you look at all of the things that can be improved in an early stage startup, this kind of thing is pretty minimal in importance so it becomes tech debt.
    - maaarghk 4y ago
      Anyway, where were we? Oh yeah - RIP Fred Brooks.
- Ma8ee 4y ago
  I really hope you are joking 100%, because (b) Go home and be happily oblivious that six other systems silently started to produce wrong results since the meaning of the column has changed. But, of course, that is someone else’s problem, some other day, when several months of reports and forecasts have to be recalled and updated.
- js8 4y ago
  That's why you should also have comments, and maintain them. Then if the name is hard to change, you can at least document the new semantics.
- deniska 4y ago
  We prefer option c: add a new table/column with similar looking name. Then few years later start wondering why there're two almost identical entities, and why one of them behaves weirder than another.
- quickthrower2 4y ago
  To be clear I am pointing out incentives to make a worse choice, rather than the better choice.
retSava 4y ago
Don't worry, the code is self-documenting. /s Self-documenting code (what I take in practice means "no comments"-culture) is something I don't understand how it can work, never seen a good implementation of it. It _can_ be successful in describing the _what_ but is poorly or not at all describing the _why_. Perhaps I'm in the wrong domain for that though.
- the-smug-one 4y ago
  The why should be clear from the domain that you're working within. A line of comment should count as something like 10 lines of code, if you're reading a comment then you're treading into real complexity. If you're in a code base where that isn't true, then is the comment really necessary? Fairly hot take from me, life is more ambiguous than that :-).
  - saiya-jin 4y ago
    Unless you are in some trivial startup domain, real domains (TM) have almost fractal-level complexities if you dig deep enough, corner cases, sometimes illogical rules etc. The "why" is still very much needed since it can have 10 different and even conflicting reasons, and putting it in the code in appropriate amount shows certain type of professional maturity and also emotional intelligence/empathy towards rest of the team. I mean, somebody has to be extremely junior to never experience trying to grok somebody's else old non-trivial code in situation when you need to deliver fix/change on it now. And its fairly trivial to write very complex code even in few lines, which some smart inexperienced juniors (even older, but total skill-wise still juniors) produce as some sort of intellectual game out of boredom.
    - eru 4y ago
      And even more important than the 'why' can be the 'why not'? Ie explanations for implementation choices that haven't been taken for various reasons.
    - rob74 4y ago
      > I mean, somebody has to be extremely junior to never experience trying to grok somebody's else old non-trivial code People are definitely capable of looking at someone else's code and saying "this crap is completely unreadable, we should rewrite it all", while at the same time believing that their own code is perfectly readable and self-documenting.
bazoom42 4y ago
In that case the code will probably also be difficult to read. In my experience, studying the database schema and IO data structures is indeed the best way to begin understanding a complex system.
lucideer 4y ago
This is only in the reality where nobody is shown the table. Showing things acts as a forcing function to fix the thing being shown
mejutoco 4y ago
At least you can grep that column name in the source code to find out where other taxes are calculated. Of course an ORM can further complicate this.
lightbendover 4y ago
I can just barely count the times I have seen a production failure due to someone assuming a millicent value from a column with ambiguous naming was in centicents or vice-versa.

zelphirkalt 4y ago

The Linus quote is ripe for misinterpretation. Not worrying about the code can lead to an unreadable mess, that ones future self or others will hate working with. So a really good programmer will probably rather go the Sussman way and realize, that programs are firstly meant to be read and only lastly meant to be run by a computer (paraphrasing here).

citrin_ru 4y ago
Designing good data structures is very important for code readability too. If you struggle to understand how given data structure is used / what it contains it would be hard to understand the rest of the code.
Cthulhu_ 4y ago
There's a lot of code out there that would improve massively with better data structures though. I mean I've waded through tons of code where the original author abused strings to indicate relationships in a table - a column with semicolon-separated values referencing other tables / rows. And a ton of code to check references. Mind you, that's more database design than data structures, but they're close enough for this example.
lloeki 4y ago
> The Linus quote I always attributed it to Rob Pike, but it turns out Pike's is following: > Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. > Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. https://users.ece.utexas.edu/~adnan/pike.html https://users.ece.utexas.edu/~adnan/pike.html Interestingly enough, the above link has this to say: > Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Which I guess references GP's excerpt. Also says this, which kinda loops back to Linus's way of saying it: > Rule 5 is often shortened to "write stupid code that uses smart objects".

atdrummond 4y ago

What if the table includes a poorly labeled column entitled “fiat@“?

gilbetron 4y ago
Underrated comment that would have been perfect if you said "labled"

mekoka 4y ago

While I agree with both quotes separately, I don't think that they necessarily mean the same thing. To me, the first (by Brooks) seems to be about grasping the domain model to understand what the system does (or can do) in general. Wheras the second (by Torvalds) seems to be about how best to organize data in code for efficient processing. Array, hash, tree, heap, etc and their associated access time complexity. The efficiency of your solution depends on your choice of a data structure that fits the local problem.