Hacker News Reader

Comment by ams6110 | Hacker News Reader

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.

View on HN

"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

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.

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.

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com