While I appreciate the author's humility, I don't appreciate them putting it on to me. These questions have answers, just not the ones the author is looking for. The answer is the process. You take your context, your objectives, your team, and do what makes sense. And time changes all things, so constantly re-adjust. I prefer statically typed languages, but are you wrong to choose Python if that's what you and your team is most comfortable with? Absolutely not, if your goal is to deliver something using the knowledge you have now. I think the author is looking for a static answer: X is always right. And that isn't reality. It isn't reality in engineering, in art, and in play, all of which software can be done as an activity.
It is intrinsically difficult for the know-nothing money guys to trust people whose expertise is of a vastly different order -- across various dimensions such as technical difficulty and creative explorative engineering -- than what it takes to make deals on a golf course.
All they know is that the longer it takes us, the more money it costs them. And they don't want to know why, they just want us to wave the magic wand and deliver our systems, even though our best estimates are really just "guess a number, then multiply by three and add five."
Their entire job is to wring money out of the peasants, even when we're well-paid, well-intentioned, and hard-working engineer-wannabes who love what we do. Hell, most people (including us) don't realize that every new significant software project is an sublime artistic endeavor cut from whole cloth with rusty, bent scissors in the dark on a bumpy train ride, under fire.
It doesn't help that many of our peers are just paycheck-earners who only try their best to do the least they can to deliver the barest-minimum of quality, for the sole purpose of getting a better job somewhere else.
I've never looked for a job while I had one. I call that "being honestly committed to the job"; the mediocre of the world (most people) call it "not playing the game".
If there is any guideline I follow, it is that any complexity must be justified.
When for a client we have a choice in hosting environment, we still choose Windows because a shared IIS hosting environment or Az App Service in both cases allow deployment though MSDeploy and don't require docker because on Windows you can run many apps side-by-side without issue. This saves a whole lot of hassle.
For frontend, any library or build system needs to be justified. No webpack because it causes more problems than it solves. A simple gulp build suffices.
In terms of software architecture, a simple webapp-database architecture works fine for 80% of the use cases. No need to introduce extra parts with extra complexity. Boring architectures work best. Any complexity can and will be a source of headaches.
I agree completely. The simplest solution is often the best solution. And also, the best understood and best supported solution. Teams love new shiny objects and toys to play with, but if business leaders truly understood the tradeoffs, they’d shy away from the latest and “greatest” most of the time.
I like this idea. I think we can dismiss the most literal/extreme interpretation of this (as most commenters seem to be doing), but when I look at most of us I find we are more likely to forecast with overconfidence than underconfidence (tech X will destroy the company, or NOT using x will destroy the company).
I remember working at a place and our whole data-team (myself included) seemed like a useless waste a dozen engineers. I thought the company was adrift. A few years later it was bought for billions of dollars because the business people knew exactly how to threaten a dominant player in the market. And I realized my henny-penny attitude was complete noise, I just was out-of-the-loop about what the long-term play was.
I think a lot of this is that we each want to be the center of our own universe, we want our problems to be the THE problems, and to some degree understand that peddling our advice about tech X or Y is to some degree advancing our own influence.
Everyone doing senior work in any field is doing judgement. What are the pros and cons of doing this thing? What are the short and long term consequences?
There's not actually that much we can generalise about judgement itself. Did you think about it, considering all the tradeoffs? Did things work out?
So a lot of the high level advice I see in the Internet is basically just turning the same stones over and over.
I feel like the most useful articles are actually about specific things like how to write a memory allocator. Those are more like sharing experience that can be used as the raw material of making good decisions.
Yup, but I ain't telling y'all sh_t. You can figure that sh_t out for yourself. ;-)
I'm not really impressed with what y'all are building anyway. More FANG-sh_t? Microsoft-adeverywhere-2030? Salesforce? Better insurance software or real estate collusion? More Google artificial-ad-f_ckery? Better social media disinformation bots?
"Know your enemy." --RATM
[And, nothing personal, my friend. I'm addressing the industry via the "Royal You", representing by YC et al.]
I’d like to challenge a core argument of the article:
> Only your last ~20 years of experience matters for these questions, because the basic landscape of software development changes so rapidly. [...]
… with an anecdote. I’ve recently skimmed through a “Thinking Forth” book, and, language-specific information apart, was surprised to read that the software structure they recommend resembles to what I’ve figured out over years of programming by intuition.
The basic landscape "changes" so rapidly because although we keep talking in circles, about the same things over and over, for some reason we give them new names each time we go around.
I started to to code 25 years ago when I was 12 years old, creating chatbots to manage RPG sessions for a IRC server. Turns out that's the most up-to-date experience I have now with the advent of LLMs.
This is nihilistic nonsense. The author's problem is that he's only ever seemingly worked on web stuff. People stay in their domain far too often and then come up with big statements like "I have 20 years of experience and don't know what I'm doing." Is that maybe because you stick around a domain and layer defined by people with an average 2 years of experience, many of whom learned their job from a Youtube tutorial?
It's possible for organizations to get better, even good at building software. The foundations of the field haven't changed much, people just don't learn about them and go on to build towers of overwrought abstraction, which is the thing that keeps constantly changing.
If you think of React and Redux as foundational, then everything you say has water under it. Go open a TCP socket.
One thing that certainly has changed, over these years, is that the size of applications is much, much larger now.
And, certainly, we never had to think about security in the 90's, for regular-degular business apps, anyway. Now, the security dimension is it own barrel of worms, both affecting our software design and requiring network security specialists as well, configuring our boxen. I doubt very many of us are working on pure intranet apps.
So, yeah, the roots are the same, but the trunk is much larger, higher and much more expansively bushy, and its environment is considerably more dangerous.
I don't like the assumption of the author you must have observed these architectures in action. Nor does he think you can learn from a 4 year old architecture that was in place when you joined the company. Nor can you read books and papers published about companies' architectures.
He touches on this point only to reinforce that you can only learn by experience, which is at least partially incorrect, even if I agree its a fantastic teacher.
It's a nice bit in humility and a reminder of the length of time it takes to reveal major effects of architecture decisions but it paints a bit of a false hopelessness.
A lot of software does take a lot of trying & stumbling through to get good.
Alas many companies simply allow the rubble to build up around them, are on to new features, rather than figuring out how better to stitch their systems together after the first bad pass or two. Sure, X11 was there... it wasn't good. Trying to be more than haphazard takes work, and time.
I don't like the assumption of the author you must have observed these architectures in action. Nor does he think you can learn from a 4 year old architecture that was already in place when you joined the company. Nor can you read books and papers about lessons learned published by other companies.
It's a nice reminder to be humble and at the length it takes to see major effects from architecture decisions but he paints a kind of hopeless picture that just isn't there.
This is why consulting is such an awesome career path once you have some experience under your belt. It is absolutely possible to be well-informed enough to answer these questions, because consultants see the beginning, middle and end of these decisions!
All of these calls about which way to build software are judgment calls.
For example - a monolith has strong benefits but when you reach a certain size & team size it makes sense to split out some things - but you should still keep the monolith where it makes sense. And redux state storage makes sense for 99% of cases but the org should have flexibility to let teams run things their own way if they can make their case, depending what controls your org wants to have in place to keep a certain level of standardization. It’s about finding a balance.
The author seeks universal answers where none exist. All these different approaches have survived well enough to enter the zeitgeist so they each must have merit. The fact they’re contradictory suggests the appropriate mental model is more like a flowchart with many end states, than a path that seeks a holy grail.
I also strongly counter the author’s assertion that 20 years is not enough time to see all this play out. Of my 20 years’ software dev experience, 5 were at a company that went from less than 2000 employees to over 40000 while I was there. I saw the architecture evolve to meet the challenges of growth through many orders of magnitude of scale, and saw the hiring of people who’d done the thing in other companies at the level we needed and brought the leadership to implement it within our teams. 20 years is absolutely enough time to get in one of these 5 year experiences even if the other 15 years is throwaway. To maximize your chances, go and work in SF or Silicon Valley. Yes, it does happen elsewhere in the world; but with far less regularity. If you really want to hone your craft you have to go to the place it’s happening.
This is a dumb post. I can't believe someone with 20 years is still looking for X is better than Y, black-and-white answers. All these questions have answers, but they're not blanket ones. You have to get into the details. But even without getting into details, I could probably ask ChatGPT and with a short conversation get to the crux of each matter. Most of them come up frequently enough on HN to have stock answers that the author doesn't seem to know about.
Microservices? It's about parallelizing and scaling teams. By decoupling codebases, tech stacks, deployments (to a large degree), you lean into Conway's law and reap benefits with other costs like dealing with eventually consistent behaviour.
Typed vs Untyped languages? Answer is use the language you know when starting out. A lot can be done with either, in most cases it comes down to preference and adeptness of what you know. For large-scale standard software (e.g. database, API, front-ends) using a statically-typed language will allow larger groups of developers to work on the same codebase with fewer surprises (like a typo in an unexercised codepath). But the sunk-cost is not a fallacy (or is very high so tread carefully), you can't stop and rewrite your entire business in Rust and compete to survive.
Blah blah blah...
Even if you work at each company for several years at a time, if you're paying attention you can see that a thing they did many years ago is tech debt on current development and operation. You don't have to learn in real-time, learn past history of the codebase you're working in. If you only work at early startups, try something different...
Like what some other comments are saying, try different things, expand your horizons, gain a wider perspective than what folks who are doing exactly what you're doing are talking about. Most of this focus on code and packaging is plumbing as far as I'm concerned. The actual thing software does is transform data from one thing to another: datastructures, algorithms. A higher level view, databases and SQL. The other stuff is a moderate puzzle of filling in the blanks.
Stop trying to find answers by appealing to authorities, f#@*-around and find out.
Edit: I actually entered this into GPT-4o and got expected results.
"The following is a post on Hacker News. I want you to look at the examples of unknown things given, and for each one, get to the crux of the matter providing a concise why/why-not, when/when-not, pros/cons.
Specifically for the Expressiveness of different languages (including static- or dynamic-ally typed) I use this post[0] as a counterexample to any dogma.
[+] [-] sausagefeet|1 year ago|reply
[+] [-] zmgsabst|1 year ago|reply
[+] [-] ChicagoDave|1 year ago|reply
I think the most significant aspect of building software that is rarely discussed is the business’s appetite for change.
I can solve any architecture problem, but I can’t lead a horse to water.
By far the biggest hurdle to building good software is gaining buy-in and trust from everyone.
The actual architecture is like skiing a double black diamond. If you’re at that level of skiing, you can ski anywhere.
[+] [-] MrMcCall|1 year ago|reply
All they know is that the longer it takes us, the more money it costs them. And they don't want to know why, they just want us to wave the magic wand and deliver our systems, even though our best estimates are really just "guess a number, then multiply by three and add five."
Their entire job is to wring money out of the peasants, even when we're well-paid, well-intentioned, and hard-working engineer-wannabes who love what we do. Hell, most people (including us) don't realize that every new significant software project is an sublime artistic endeavor cut from whole cloth with rusty, bent scissors in the dark on a bumpy train ride, under fire.
It doesn't help that many of our peers are just paycheck-earners who only try their best to do the least they can to deliver the barest-minimum of quality, for the sole purpose of getting a better job somewhere else.
I've never looked for a job while I had one. I call that "being honestly committed to the job"; the mediocre of the world (most people) call it "not playing the game".
"So sick of complacence." --RATM
[+] [-] yard2010|1 year ago|reply
[+] [-] sebazzz|1 year ago|reply
When for a client we have a choice in hosting environment, we still choose Windows because a shared IIS hosting environment or Az App Service in both cases allow deployment though MSDeploy and don't require docker because on Windows you can run many apps side-by-side without issue. This saves a whole lot of hassle.
For frontend, any library or build system needs to be justified. No webpack because it causes more problems than it solves. A simple gulp build suffices.
In terms of software architecture, a simple webapp-database architecture works fine for 80% of the use cases. No need to introduce extra parts with extra complexity. Boring architectures work best. Any complexity can and will be a source of headaches.
I could go on and on.
[+] [-] TacticalCoder|1 year ago|reply
As opposed to Linux which would have issues when running apps side-by-side?
Linux took over the entire world and now run on billions of devices and there has to be a reason for that.
One example of devices running several applications side-by-side that we all use would be smartphones: Android or iOS. No Windows to be seen.
If a part of the world moved to containerization, it's not because OSes had issues running applications side-by-side.
[+] [-] tmountain|1 year ago|reply
[+] [-] zug_zug|1 year ago|reply
I remember working at a place and our whole data-team (myself included) seemed like a useless waste a dozen engineers. I thought the company was adrift. A few years later it was bought for billions of dollars because the business people knew exactly how to threaten a dominant player in the market. And I realized my henny-penny attitude was complete noise, I just was out-of-the-loop about what the long-term play was.
I think a lot of this is that we each want to be the center of our own universe, we want our problems to be the THE problems, and to some degree understand that peddling our advice about tech X or Y is to some degree advancing our own influence.
[+] [-] lordnacho|1 year ago|reply
Everyone doing senior work in any field is doing judgement. What are the pros and cons of doing this thing? What are the short and long term consequences?
There's not actually that much we can generalise about judgement itself. Did you think about it, considering all the tradeoffs? Did things work out?
So a lot of the high level advice I see in the Internet is basically just turning the same stones over and over.
I feel like the most useful articles are actually about specific things like how to write a memory allocator. Those are more like sharing experience that can be used as the raw material of making good decisions.
[+] [-] utopicwork|1 year ago|reply
[+] [-] MrMcCall|1 year ago|reply
I'm not really impressed with what y'all are building anyway. More FANG-sh_t? Microsoft-adeverywhere-2030? Salesforce? Better insurance software or real estate collusion? More Google artificial-ad-f_ckery? Better social media disinformation bots?
"Know your enemy." --RATM
[And, nothing personal, my friend. I'm addressing the industry via the "Royal You", representing by YC et al.]
[+] [-] scott01|1 year ago|reply
> Only your last ~20 years of experience matters for these questions, because the basic landscape of software development changes so rapidly. [...]
… with an anecdote. I’ve recently skimmed through a “Thinking Forth” book, and, language-specific information apart, was surprised to read that the software structure they recommend resembles to what I’ve figured out over years of programming by intuition.
[+] [-] 082349872349872|1 year ago|reply
[+] [-] meiraleal|1 year ago|reply
I started to to code 25 years ago when I was 12 years old, creating chatbots to manage RPG sessions for a IRC server. Turns out that's the most up-to-date experience I have now with the advent of LLMs.
[+] [-] t8sr|1 year ago|reply
It's possible for organizations to get better, even good at building software. The foundations of the field haven't changed much, people just don't learn about them and go on to build towers of overwrought abstraction, which is the thing that keeps constantly changing.
If you think of React and Redux as foundational, then everything you say has water under it. Go open a TCP socket.
[+] [-] MrMcCall|1 year ago|reply
One thing that certainly has changed, over these years, is that the size of applications is much, much larger now.
And, certainly, we never had to think about security in the 90's, for regular-degular business apps, anyway. Now, the security dimension is it own barrel of worms, both affecting our software design and requiring network security specialists as well, configuring our boxen. I doubt very many of us are working on pure intranet apps.
So, yeah, the roots are the same, but the trunk is much larger, higher and much more expansively bushy, and its environment is considerably more dangerous.
[+] [-] bot403|1 year ago|reply
He touches on this point only to reinforce that you can only learn by experience, which is at least partially incorrect, even if I agree its a fantastic teacher.
It's a nice bit in humility and a reminder of the length of time it takes to reveal major effects of architecture decisions but it paints a bit of a false hopelessness.
[+] [-] jauntywundrkind|1 year ago|reply
A lot of software does take a lot of trying & stumbling through to get good.
Alas many companies simply allow the rubble to build up around them, are on to new features, rather than figuring out how better to stitch their systems together after the first bad pass or two. Sure, X11 was there... it wasn't good. Trying to be more than haphazard takes work, and time.
[+] [-] bot403|1 year ago|reply
It's a nice reminder to be humble and at the length it takes to see major effects from architecture decisions but he paints a kind of hopeless picture that just isn't there.
[+] [-] valval|1 year ago|reply
[+] [-] wiseowise|1 year ago|reply
And I do know how to build software. Whatever narrow definition I have of it.
And no, this is not coming out of defensiveness but frustration.
[+] [-] nunez|1 year ago|reply
[+] [-] cadamsau|1 year ago|reply
For example - a monolith has strong benefits but when you reach a certain size & team size it makes sense to split out some things - but you should still keep the monolith where it makes sense. And redux state storage makes sense for 99% of cases but the org should have flexibility to let teams run things their own way if they can make their case, depending what controls your org wants to have in place to keep a certain level of standardization. It’s about finding a balance.
The author seeks universal answers where none exist. All these different approaches have survived well enough to enter the zeitgeist so they each must have merit. The fact they’re contradictory suggests the appropriate mental model is more like a flowchart with many end states, than a path that seeks a holy grail.
I also strongly counter the author’s assertion that 20 years is not enough time to see all this play out. Of my 20 years’ software dev experience, 5 were at a company that went from less than 2000 employees to over 40000 while I was there. I saw the architecture evolve to meet the challenges of growth through many orders of magnitude of scale, and saw the hiring of people who’d done the thing in other companies at the level we needed and brought the leadership to implement it within our teams. 20 years is absolutely enough time to get in one of these 5 year experiences even if the other 15 years is throwaway. To maximize your chances, go and work in SF or Silicon Valley. Yes, it does happen elsewhere in the world; but with far less regularity. If you really want to hone your craft you have to go to the place it’s happening.
[+] [-] karmakaze|1 year ago|reply
Microservices? It's about parallelizing and scaling teams. By decoupling codebases, tech stacks, deployments (to a large degree), you lean into Conway's law and reap benefits with other costs like dealing with eventually consistent behaviour.
Typed vs Untyped languages? Answer is use the language you know when starting out. A lot can be done with either, in most cases it comes down to preference and adeptness of what you know. For large-scale standard software (e.g. database, API, front-ends) using a statically-typed language will allow larger groups of developers to work on the same codebase with fewer surprises (like a typo in an unexercised codepath). But the sunk-cost is not a fallacy (or is very high so tread carefully), you can't stop and rewrite your entire business in Rust and compete to survive.
Blah blah blah...
Even if you work at each company for several years at a time, if you're paying attention you can see that a thing they did many years ago is tech debt on current development and operation. You don't have to learn in real-time, learn past history of the codebase you're working in. If you only work at early startups, try something different...
Like what some other comments are saying, try different things, expand your horizons, gain a wider perspective than what folks who are doing exactly what you're doing are talking about. Most of this focus on code and packaging is plumbing as far as I'm concerned. The actual thing software does is transform data from one thing to another: datastructures, algorithms. A higher level view, databases and SQL. The other stuff is a moderate puzzle of filling in the blanks.
Stop trying to find answers by appealing to authorities, f#@*-around and find out.
Edit: I actually entered this into GPT-4o and got expected results.
"The following is a post on Hacker News. I want you to look at the examples of unknown things given, and for each one, get to the crux of the matter providing a concise why/why-not, when/when-not, pros/cons.
..."
[+] [-] karmakaze|1 year ago|reply
[0] http://thume.ca/2019/04/29/comparing-compilers-in-rust-haske...
[+] [-] unknown|1 year ago|reply
[deleted]