4 ms·

First supervisor I had in my 2nd job out of school had a mantra: get the data model right and everything else falls into place. Has worked for me for 30+ years

First supervisor I had in my 2nd job out of school had a mantra: get the data model right and everything else falls into place. Has worked for me for 30+ years.

mavelikara 8y ago
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." -- Fred Brooks
- jwhitlark 8y ago
  This has certainly worked for me on smaller scale, but when things get big, it seems to break down. In theory, you should be able to look at subsets, but I've rarely seen things well factored enough that this worked well in practice.
- jessaustin 8y ago
  I've gotten the feeling that flowcharts used to be considered quite important by lots of coders, while today they are only used in particular subcultures. A flowchart is sort of an ungainly artifact. It repeats information that is in code, but is more difficult to produce and save than code is.
  - pg_bot 8y ago
    Anecdotally every flowchart loving dev I've worked with has been utterly useless. If someone's first step is to create a flowchart of the entire structure of the project then I immediately know they are going to be a disaster.
  - lovich 8y ago
    I've found them worth the effort pretty much only when trying to explain to stakeholders that they have given me conflicting requirements. When they can follow the logic path with their own eyes they are usually able to figure out what they actually want
  - adrianmsmith 8y ago
    Nowadays code is (relatively) easy to read. Back in the day of thousands of lines of assembler, perhaps on punched cards, less so. I think that's why flowcharts were more important in the past than they are now.
bungie4 8y ago
First class comment. I can't tell you how many times I point out the data model is flawed (even when it should be obvious) only to have the project turn it into something you don't want to step in. The most recent one was clearing of multiple work orders with one invoice. Yes you can, but you shouldn't.
- pmontra 8y ago
  If that was a business requirement then developers must find a way to implement it. All we can do is to point out the extra costs of the implementation.
makmanalp 8y ago
To add to this, usually when I see a mess of a data model it's not because it started that way but rather it's indicative of changing business requirements with not enough time given to engineers (or more rarely lack of experience, I guess) to refactor / redesign / migrate things properly. Or perhaps original creators leaving with no record of why things are built a certain way so no one wants to touch it.

First supervisor I had in my 2nd job out of school had a mantra: get the data model right and everything else falls into place. Has worked for me for 30+ years.

mavelikara 8y ago

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." -- Fred Brooks

jwhitlark 8y ago
This has certainly worked for me on smaller scale, but when things get big, it seems to break down. In theory, you should be able to look at subsets, but I've rarely seen things well factored enough that this worked well in practice.
jessaustin 8y ago
I've gotten the feeling that flowcharts used to be considered quite important by lots of coders, while today they are only used in particular subcultures. A flowchart is sort of an ungainly artifact. It repeats information that is in code, but is more difficult to produce and save than code is.
- pg_bot 8y ago
  Anecdotally every flowchart loving dev I've worked with has been utterly useless. If someone's first step is to create a flowchart of the entire structure of the project then I immediately know they are going to be a disaster.
- lovich 8y ago
  I've found them worth the effort pretty much only when trying to explain to stakeholders that they have given me conflicting requirements. When they can follow the logic path with their own eyes they are usually able to figure out what they actually want
- adrianmsmith 8y ago
  Nowadays code is (relatively) easy to read. Back in the day of thousands of lines of assembler, perhaps on punched cards, less so. I think that's why flowcharts were more important in the past than they are now.

bungie4 8y ago

First class comment. I can't tell you how many times I point out the data model is flawed (even when it should be obvious) only to have the project turn it into something you don't want to step in. The most recent one was clearing of multiple work orders with one invoice. Yes you can, but you shouldn't.

pmontra 8y ago
If that was a business requirement then developers must find a way to implement it. All we can do is to point out the extra costs of the implementation.

makmanalp 8y ago

To add to this, usually when I see a mess of a data model it's not because it started that way but rather it's indicative of changing business requirements with not enough time given to engineers (or more rarely lack of experience, I guess) to refactor / redesign / migrate things properly. Or perhaps original creators leaving with no record of why things are built a certain way so no one wants to touch it.