Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What we talk about when we talk about system design

maheshba.bitbucket.io

Post reply on HN
Print view View original

31–37 of 37 posts

Re: What we talk about when we talk about system design

#31

Post by di4na »

samsquire wrote: post #9

Thanks for this article, I am a beginner in this space. I think systems suffer from interaction permutations complexity and the approach to look for a fundamental building block fails, because There Is No Primal Particle™. So we try introduce fundamental particle such as "everything is function", "everything is a list", "everything is a type", "everything is a file". It doesn't work. We do it to keep it in our heads…

That is sadly an impossible dreams due exactly to every (useful) software being a complex system.

It works the other way around. You as the designer tell the computer which interactions it should handle and how. There are sadly no ways around that.

Re: What we talk about when we talk about system design

#32

Post by prmph »

carbonguy wrote: post #2

Extremely high-quality work here - I spend (what I think is) a significant amount of time trying to understand systems, in general and in detail, and this feels on first reading like something I'll be referring to repeatedly in future. Already it suggests a surprising idea, which may or may not be fleshed out elsewhere, that a good way to understand an existing system is to try and solve the same problem without refe…

True, this is why I sometimes prefer not to look too closely at the state of the art when addressing a new system architectural problem.

By trying to solve it from first principles, and making some progress but most likely failing to completely solve it, I get a good sense of that the design forces and challenges are. Then, when I go back to study the state of art, I'm much better placed to understand what I'm studying.

Another good thing about this approach is that I minimize pre-biasing my thinking by what is out there now. Then, when studying existing afterward, solutions, I can more clearly begin to see gaps in them that I can direct my efforts to solving.

Re: What we talk about when we talk about system design

#33

Post by bob1029 »

john-tells-all wrote: post #28
heisenbit wrote: post #25

> Late-bind on designs. The goal of the design process is not to generate a single point solution, but to instead characterize the design space for a given problem: a single point should then fall naturally out of that space given the problem constraints. There is also value in early binding combined with a willingness to iterate. There is a lot of knowledge to be gained by trying to do things rather than staying on…

Strongly agree. Design Workflow: - spend little time making a couple design decisions -- lots of handwaving and "we'll figure it out" - bind these decisions, then write a tiny app to see what it looks like. What are the technical consequences? What are the business consequences (including risks)? How does this affect development? - repeat 2-4x. The goal is to maximize speed of feedback, at the cost of minimal scope a…

What you are describing is (to me) the pure essence of what it means to be an artist. There are a lot of days where I feel like software and systems engineering is more about creativity than it is math and science.

Try things, take risks, etc. The really amazing thing with software is that the cost of iteration is basically zero (+ your time). You don't even have to go buy new paints or brushes periodically. You can reset your digital canvas a billion times per day if you desire. You can even cheat and set waypoints in time that allow you to instantly teleport to any arbitrary moment with perfect recall. You can create infinite copies of your work at various stages. You can trivially blend your works together. There is no other media on earth that comes close to possessing these same attributes.

Re: What we talk about when we talk about system design

#34

Post by a1445c8b »

bob1029 wrote: post #33
john-tells-all wrote: post #28

Earlier quoted context omitted.

Strongly agree. Design Workflow: - spend little time making a couple design decisions -- lots of handwaving and "we'll figure it out" - bind these decisions, then write a tiny app to see what it looks like. What are the technical consequences? What are the business consequences (including risks)? How does this affect development? - repeat 2-4x. The goal is to maximize speed of feedback, at the cost of minimal scope a…

What you are describing is (to me) the pure essence of what it means to be an artist. There are a lot of days where I feel like software and systems engineering is more about creativity than it is math and science. Try things, take risks, etc. The really amazing thing with software is that the cost of iteration is basically zero (+ your time). You don't even have to go buy new paints or brushes periodically. You can…

One could also argue that this continuous feedback loop is the scientific process in action.

Re: What we talk about when we talk about system design

#35

Post by john-tells-all »

bob1029 wrote: post #33
john-tells-all wrote: post #28

Earlier quoted context omitted.

Strongly agree. Design Workflow: - spend little time making a couple design decisions -- lots of handwaving and "we'll figure it out" - bind these decisions, then write a tiny app to see what it looks like. What are the technical consequences? What are the business consequences (including risks)? How does this affect development? - repeat 2-4x. The goal is to maximize speed of feedback, at the cost of minimal scope a…

What you are describing is (to me) the pure essence of what it means to be an artist. There are a lot of days where I feel like software and systems engineering is more about creativity than it is math and science. Try things, take risks, etc. The really amazing thing with software is that the cost of iteration is basically zero (+ your time). You don't even have to go buy new paints or brushes periodically. You can…

Absolutely. [I'm also an artist]

I find Developers like to have a specific Goal, then explore the space towards it. An Artist does the opposite: they make random marks and explore the marks that they "like".

Art iteration is also almost free. In fact, the "cost" of physical media (pencils and paper) helps the human brain understand and integrate what it's learning, vs digital is harder for ideas to stick.

Developers could gain by doing the same thing as artists: do random things to gain knowledge, then create a Goal and work towards it.

Recommend checking out Lynda Barry, who's written multiple books helping students unleash their creativity -- exercise https://www.youtube.com/watch?v=gtb2M2SmeuA

Re: What we talk about when we talk about system design

#36

Post by hamburglar »

joseph wrote: post #22

> Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals). This is so true. It’s very common to see infrastr…

I’ve had a lot of success building good abstractions with a version of this “second app” idea. The delta between designing for 1 app and designing for 2 apps is vast, but once you’ve designed for 2, you are generally very close to being able to support N apps. By the time you get to 3, you understand the problem domain very well and have a lot of confidence in your interfaces.

Re: What we talk about when we talk about system design

#37

Post by edwardsdl »

rewmie wrote: post #30
rcxdude wrote: post #11

Earlier quoted context omitted.

Doesn't seem like you're actually disagreeing then, if systems design can apply just as well to a 'monolith' and it's often the better design.

> Doesn't seem like you're actually disagreeing then, if systems design can apply just as well to a 'monolith' and it's often the better design. "Can" and "do" are two different words. "Monolith" is often a cop out to hide amorphous big-ball-of-mud projects. In fact, the luddite-like movement's aversion to system design is rooted in the fact that it's not necessary, and their irrational aversion to microservices and…

> unlike monoliths, they are far less tolerant of hacking together big balls of mud and demand instead some degree of discipline to design a system and comply with the system design.

A demand that is often poorly met, leaving one with a distributed ball of mud that is more difficult to reason about and refactor.

Post reply on HN