3 ms·

It's almost like we live in different world, I could not disagree more. * Software is extremely expensive. Software engineers are expensive, and for a good sof

It's almost like we live in different world, I could not disagree more. * Software is extremely expensive. Software engineers are expensive, and for a good software project you need a tech lead, a manager and probably a few developers. These are all people you need to pay tons of money for. * Software is constantly changing, something that worked 2 years ago can be broken beyond repair today. You need a team that can keep up with this. * Software needs maintenance. You can't just build an app an call it a day, you need to employ a team to maintain it continuously. You can build a massive, gargantuan bridge and maintain it maybe every few years/half a decade to keep it safe for 30+ years, you cannot do that in software. * Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades. What a developer focuses on while writing code is mostly ideas developed in the last few years. Although you think you're building a simple app with 3 devs, what you're missing is you have your own tiny research lab studying how to develop this simple app the cheapest way possible while making it maintainable. * Software by its very nature is hard to make money off of. Its complexity is opaque to most people, they're not willing to pay. You'll always have people pirating it, eating away from your bottom line. Moreover, each new software means changing workflow, so even if you have the best product on the market, decent amount of people won't switch from the industry standard. * Modern software engineering methodology focuses on, among other things, time to ship, feature richness and maintainability. It does not focus on correctness -- partially because our theories on software correctness are lacking (even if you decide to use novel/extreme approaches such as Dependently Typed Programming, formal proofs etc it's unclear/unknown if you'll reach a significantly better correctness metric). This makes your product inherently frustrating to the customer. No matter how much money you spend, you'll always have a product that's a little bit buggy. This means the product is very sensitive to the amount of money you throw at it. If you throw Apple level of money, it'll be less buggy, if you have a barebones team it'll be more buggy.

jkepler 3y ago
> * Software needs maintenance. You can't just build an app an call it a day, you need to employ a team to maintain it continuously. You can build a massive, gargantuan bridge and maintain it maybe every few years/half a decade to keep it safe for 30+ years, you cannot do that in software. > * Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades. As a nonpracticing civil engineer, you're underestimating the ongoing maintence that goes into any large bridge. Also, though the techniques may be more established, every bridge must still be designed to fit the specific characteristics of its local geology and geography. But come to think of it, fundamental computer science algorithms are pretty well established, like bridge-building techniques. Software engineering is simply fitting the code to each unique problem, as bridge design fits a bridge to each unique place.
- dcow 3y ago
  The dirty secret is that you rarely need to invest in new, novel, software engineering techniques which is what you need actual software engineers for. In reality you can just get a few software developers to propose a design for a thing, have a software engineer consultant review the design and sign off, and then go on your merry way building the software. Kinda like how architecture/construction vs engineering works in meat space.
ndriscoll 3y ago
> Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades. What a developer focuses on while writing code is mostly ideas developed in the last few years. Most (all?) of the ideas I see are at least 20 years old, if not 40-50. Something like Spring wouldn't be my ideal choice, but it can certainly get the job done for most people, and it's 20 years old. MVC dates back to the 70s. Postgresql is 27 years old and is a fantastic choice. SQL and RDBMSs date back to the 70s. The term CRUD itself dates back to the 80s. Server rendered pages are still easy to do, perform way better than most React-based abominations, and are as old as the web. If anything, software is plagued by these "research projects" that are mostly just to scratch smart people's itches.

jkepler 3y ago

> * Software needs maintenance. You can't just build an app an call it a day, you need to employ a team to maintain it continuously. You can build a massive, gargantuan bridge and maintain it maybe every few years/half a decade to keep it safe for 30+ years, you cannot do that in software. > * Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades. As a nonpracticing civil engineer, you're underestimating the ongoing maintence that goes into any large bridge. Also, though the techniques may be more established, every bridge must still be designed to fit the specific characteristics of its local geology and geography. But come to think of it, fundamental computer science algorithms are pretty well established, like bridge-building techniques. Software engineering is simply fitting the code to each unique problem, as bridge design fits a bridge to each unique place.

dcow 3y ago
The dirty secret is that you rarely need to invest in new, novel, software engineering techniques which is what you need actual software engineers for. In reality you can just get a few software developers to propose a design for a thing, have a software engineer consultant review the design and sign off, and then go on your merry way building the software. Kinda like how architecture/construction vs engineering works in meat space.

ndriscoll 3y ago

> Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades. What a developer focuses on while writing code is mostly ideas developed in the last few years. Most (all?) of the ideas I see are at least 20 years old, if not 40-50. Something like Spring wouldn't be my ideal choice, but it can certainly get the job done for most people, and it's 20 years old. MVC dates back to the 70s. Postgresql is 27 years old and is a fantastic choice. SQL and RDBMSs date back to the 70s. The term CRUD itself dates back to the 80s. Server rendered pages are still easy to do, perform way better than most React-based abominations, and are as old as the web. If anything, software is plagued by these "research projects" that are mostly just to scratch smart people's itches.