←back to thread

107 points pixelworm | 1 comments | | HN request time: 0s | source

I’m working on improving my software design skills, and it was recommended that I study existing well designed codebases. What are some publicly accessible codebases you would consider gold standards for software design?
Show context
pfannkuchen ◴[] No.45001808[source]
Maybe I’m just not good enough at paying attention, but for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems. Then you end up being able to mentally simulate what problems you will run into, and design is basically all about avoiding future problems of various kinds (and balancing tradeoffs about which future problems to avoid and how much effort to put into each, whether you can solve multiple with one design play, etc).
replies(6): >>45002077 #>>45002139 #>>45002144 #>>45002299 #>>45002595 #>>45068338 #
teiferer ◴[] No.45002299[source]
> for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems

This shows how immature the field of software engineering is. Imagine bridges or houses were built like that. Or your surgeon was trained like that.

Over time, we hopefully develop estblished norms, but at the moment, things are too much in flux. Put 5 sw engineers in a room, pose a problem and you will get not just 5 different solution proposals, but there will likely be strong disagreements on which approach is a good one.

"I recognize a good solution when I see it" is just not good enough for a serious engineering discipline.

replies(7): >>45002314 #>>45002440 #>>45002698 #>>45003480 #>>45006059 #>>45006883 #>>45008972 #
hvb2 ◴[] No.45002314[source]
> Imagine bridges or houses were built like that. Or your surgeon was trained like that.

While I don't disagree with you in general, this does feel a bit off.

By that logic you can call the field of music immature, and all of the arts. I think the difference is that its easy to experiment without high costs.

I genuinely think that if building bridges was cheap and quick, the fastest way to learn was to try...

replies(1): >>45004250 #
nchagnet ◴[] No.45004250{3}[source]
I generally agree with your point on ease of experimentation, but if we insist on calling it software engineering, then maybe the field needs to adhere to engineering principles, as the GP highlighted.
replies(2): >>45004748 #>>45005384 #
HPsquared ◴[] No.45005384{4}[source]
Notice OP says "software design". Design is still an art, even in mechanical engineering.

Engineering applies to looking at a design and proving something about it.

replies(1): >>45010767 #
1. teiferer ◴[] No.45010767{5}[source]
The term "design" is ambiguous here.

When design is a process to build something pleasing (like in music or painting), then yes, it's an art, and you can rightfully have different opinions about outcomes, sometimes diametrically opposed opinions, which is all not just fine and accepted but inherent in the field and a required ingredient.

When design is about building something functional, then it's part of engineering. You can objectively measure whether it does satisfy the requirements. That's where serious engineering disciplines are and where software engineering needs to aim for if it wants to keep engineering in its title without getting laughed at. As long as programmers consider themselves part artists, that's hard to achieve, but as the field matures, there is hope.

Note that some fields are trying to be both. For example architecture. There it's solved by making a more or less clear distinction between the pleasing art part (that's what the architect does) and the functional engineering part (structural engineer). Both roles are not being conflated. In software, we still do that.