10 ms·

This is fundamentally because our industry is built on opinions, not standards. You talk to one software engineer, and they'll say, "that's built in PHP, so it

This is fundamentally because our industry is built on opinions, not standards. You talk to one software engineer, and they'll say, "that's built in PHP, so it sucks; it should have been built with npm, obviously." Then you talk to another and they say, "I can't believe they built that with npm, the package management system is just terrible and the whole mess is bloated and there have been a ton of security issues. They should have used a static generator instead." And on, and on, and on. Now compare this to a mature industry with real engineers who are able to say things like, "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Nobody's bothered to do that work. We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects. This is absolutely shameful IMO, and the reason why I cringe a little inside whenever I see the words "software engineer".

pfraze 7y ago
Not that software can't improve on this front, but I'm pretty sure that every engineering profession has its fair share of opinions and disagreements around them. Heck, my dad's a general surgeon and he's constantly debating with other surgeons over things like whether a procedure should be out-patient or which procedure has the best outcomes. They have a better concept of outcomes, which helps them make data-driven decisions, but they also have a higher risk profile which slows down the innovation process. I agree with most of your premise, but I think you overstate it a bit. Like the GP's point above, it seems like you're describing bad engineers. In the good web dev agencies I've worked at, they work pretty hard to make informed decisions which stay within budget and timeline. It doesn't always happen, but that's not just due to poor practice.
testy3 7y ago
There are reasons why other industries are more mature, like: they've been waaaaaaaaay longer than CS/SE they do not change so robustly & fast in short peroids of time. >We can't even accurately estimate the cost of a complex project given our choice of tools Let's do not pretend as if that was limited to our industry.
- Frost1x 7y ago
  I think OP's point, or at least my agreement, is how many often pretend the software industry is like other engineering industries and make such implications in their job titles. There is still a lot of creative art and the more we stop pretending this isn't the case, the more people will be reasonable. There is still an high degree of technicality in the profession, but that doesn't mean its "engineering" -- you can be technical, not an engineer, and still respectable (heck, look at science in general). It's still a complex skill and makes lots of money for many businesses.
- Xelbair 7y ago
  >they do not change so robustly & fast in short peroids of time. Not really, rapid prototyping - especially due to 3d printing - is a thing now - you can iterate on a model as fast as you can in CS/CE. Also - a lot of engineering disciplines use simulations - civil engineering, avionics etc - so they too can iterate quickly. We are absolutely horrible at estimating. I had article somewhere that analyzed plenty of CS/CE projects and found that we are good at estimating median, and if something goes wrong in most complex part - the time to delivery can skyrocket 100x.
- goatinaboat 7y ago
  they've been waaaaaaaaay longer than CS/SE Nah, this isn’t really true. Consider all the technology that came out of WW2: digital computers are contemporaneous with jet engines for example.
nostrademons 7y ago
> "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." > That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field. The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware. This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.
- dhruvkar 7y ago
  >> internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms Would love to see that. For companies determining what's worth what, this would be great to see, even just for the format.
jacobsenscott 7y ago
Likely in that other industry the engineer built 100+ other basically identical items that are two or three orders of magnitude less complex and where all the costs and techniques are pretty well known. Also, those mature industries routinely overrun by millions of dollars and months or years, event though they are dealing with a fraction of the complexity and the costs and techniques are well known. Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.
- kjsthree 7y ago
  > Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries" I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
  - shkkmo 7y ago
    > I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge. That is because you are ignoring/left out the critical last part of the phrase you quoted: "and estimate it with an accuracy of 5 to 10 days and a few thousand dollars." This is particularly relevant because this is a direct response to the following: > We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
  - lexs 7y ago
    Some McDonnell Douglas DC-X engineers would probably have something to say about your comment too.
  - newen 7y ago
    It's especially hilarious because he is comparing projects done by bootcamp graduates to projects done by highly trained PhDs. Some people just don't have a clue about the massive difference involved in webdev type projects and complex engineering projects.
robertAngst 7y ago
This is good that you are calling this out. I've seen non-science in Healthcare, and I've spoke out against it. I don't really understand why people are stubborn when there is data, and the data is solid. If I could wish anything in software engineering- follow the data.
icxa 7y ago
I think a more eloquent way is to say fundamentally creating long lasting software structures is more of an art rather than a science, and you can't just tell someone "go practice these 5 things and you'll be the next Picasso" you just have to do it a lot of times, over and over, learning from your mistakes. There are no shortcuts. You have to build a ton of software, and make a lot of mistakes, and most importantly, learn from them. Then there's the other half of the equation and some people just have the creative mind to imagine the right framework, or tool or library or abstraction or architecture for the problem at hand.
- sgift 7y ago
  The important thing is: Picasso knew what to study. Over time art had established a canon of things which helped people to get better at classical arts. Only after he studied that canon in depth and for a long time he could then break into new territories and start breaking rules intentionally to develop his own style/school. Our craft is very bad at providing such a canon. It is even anti-intellectual in parts ("what do you mean you cannot be a master after x weeks? You are a gatekeeper! you suck"). That and we are still not sure what is important and what isn't (i.e. what should be part of the canon). Our medium of study changes all the time. Arts medium of study is reality and reality, for all our advances, doesn't really change.
  - icxa 7y ago
    We absolutely have a canon. You show me someone who has studied Dikjstra, Turing, Hoare, who has taken the time to pour over the Art of Computer Programming and Structures and Interpretations of Computer Programs, and poured over Ivan Sutherland, is familiar with the early days of IBM, Fairchild, Xerox PARC, and hundreds of other classics we consider to be "canon" that I am surely missing (just shooting from the hip here), and you'' be showing me, more likely than not, a damn good programmer. We have a canon, we just don't have the same studios, detail-oriented attention spans we once had, and the technology we have built is partly to blame. Maybe related, you were once considered an ignorant brut in this country and others if you haven't read a library of literary classics, now we have kids growing up who barely know Shakespeare, or the rich body of the writing of the abolitionists or slave narratives (how many people you think in this country that even know 1/100th of what Henry Louis Gates Jr knows?) Do you think W.E.B Du Bois and Booker T Washington are common names anymore? I remember when everyone had the preamble of the Constitution and the Gettysburg Address burned into their minds, now we can't be expected to remember questions for a simple AWS Certification Exam, it's pathetic.
quickthrower2 7y ago
Software is an interesting animal because what PHP and NodeJS have in common is they were created as hobbies, as were a lot of the frameworks and software tech the world relies on. Maybe there is a bit of us software engineers liking the shiny new thing? There are a lot of dynamics going on. One is programmer's curiosity but then there is a financial incentive to be on the latest tech. If you see React jobs paying more than Angular jobs, it might be a sign to jump ship which has nothing to do with technical merits. Then there is things like Blockchain that excites investors and techies alike, even when it's a useless solution for something. People sitting in a room deciding the genuine best thing to do is going to be hard with all these dynamics going on.
siruncledrew 7y ago
The "opinions" part is true, and has implications on whoever is paying for the software and whoever is maintaining it (with their own opinions, of course). A company/client will often make decisions based on "opinions" too. "We need a website, what should we use to make it?" It's a bit of a blank canvas situation at first where a developer/engineer could come in and say "We should do it X way with Y libraries because <some opinion on why it's the best stack>". Devs could have totally different takes on the same canvas by a matter of opinion. If I were to ask people "What type of car should I buy?", I would likely get a whole variety of answers from hybrids to SUVs to European and Japanese cars based on who I asked and what their own preferences and tendencies are. I may end up happy or I may end up unhappy depending on which opinion I'm swayed by and how much rigor I put into investigating the different opinions. Software can be very similar when people providing the "opinions" are caught up in looking to use specific tools over trying to figure out an appropriate solution. When developers/engineers/designers/managers immediate choose tools as a blanket solution over understanding the scope and use-case for context, it's a sign to heavily question the authority of their opinions.
hvidgaard 7y ago
> We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects. No industry can, unless it's something that has been done repeatedly before. If you ask a frontend designer specializing in WordPress to make a theme for WordPress and implement it, they can estimate it accurately. What is thoroughly missing from this debate is the age old project management terms of scope and risks. As soon as you enter unknown land, the risk goes up. And risk means uncertainty and probably expenses. And if the people writing the checks change the scope, the original estimates goes out the window. If you're making a building, it's easier to understand that you cannot just change the scope after the blueprint is made. You have to get an architect to remake it, and everything done and ordered so far may or may not be salvageable. It happens in all industries, but just more so in software development.
dagw 7y ago
We can't even accurately estimate the cost of a complex project given our choice of tools We've been building bridges for thousands of years, and still the relatively simple bridge they built down the road from me took 2.5 years to complete instead of the estimated 9-12 month.

pfraze 7y ago

Not that software can't improve on this front, but I'm pretty sure that every engineering profession has its fair share of opinions and disagreements around them. Heck, my dad's a general surgeon and he's constantly debating with other surgeons over things like whether a procedure should be out-patient or which procedure has the best outcomes. They have a better concept of outcomes, which helps them make data-driven decisions, but they also have a higher risk profile which slows down the innovation process. I agree with most of your premise, but I think you overstate it a bit. Like the GP's point above, it seems like you're describing bad engineers. In the good web dev agencies I've worked at, they work pretty hard to make informed decisions which stay within budget and timeline. It doesn't always happen, but that's not just due to poor practice.

testy3 7y ago

There are reasons why other industries are more mature, like: they've been waaaaaaaaay longer than CS/SE they do not change so robustly & fast in short peroids of time. >We can't even accurately estimate the cost of a complex project given our choice of tools Let's do not pretend as if that was limited to our industry.

Frost1x 7y ago
I think OP's point, or at least my agreement, is how many often pretend the software industry is like other engineering industries and make such implications in their job titles. There is still a lot of creative art and the more we stop pretending this isn't the case, the more people will be reasonable. There is still an high degree of technicality in the profession, but that doesn't mean its "engineering" -- you can be technical, not an engineer, and still respectable (heck, look at science in general). It's still a complex skill and makes lots of money for many businesses.
Xelbair 7y ago
>they do not change so robustly & fast in short peroids of time. Not really, rapid prototyping - especially due to 3d printing - is a thing now - you can iterate on a model as fast as you can in CS/CE. Also - a lot of engineering disciplines use simulations - civil engineering, avionics etc - so they too can iterate quickly. We are absolutely horrible at estimating. I had article somewhere that analyzed plenty of CS/CE projects and found that we are good at estimating median, and if something goes wrong in most complex part - the time to delivery can skyrocket 100x.
goatinaboat 7y ago
they've been waaaaaaaaay longer than CS/SE Nah, this isn’t really true. Consider all the technology that came out of WW2: digital computers are contemporaneous with jet engines for example.

nostrademons 7y ago

> "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." > That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field. The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware. This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.

dhruvkar 7y ago
>> internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms Would love to see that. For companies determining what's worth what, this would be great to see, even just for the format.

jacobsenscott 7y ago

Likely in that other industry the engineer built 100+ other basically identical items that are two or three orders of magnitude less complex and where all the costs and techniques are pretty well known. Also, those mature industries routinely overrun by millions of dollars and months or years, event though they are dealing with a fraction of the complexity and the costs and techniques are well known. Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.

kjsthree 7y ago
> Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries" I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
- shkkmo 7y ago
  > I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge. That is because you are ignoring/left out the critical last part of the phrase you quoted: "and estimate it with an accuracy of 5 to 10 days and a few thousand dollars." This is particularly relevant because this is a direct response to the following: > We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
- lexs 7y ago
  Some McDonnell Douglas DC-X engineers would probably have something to say about your comment too.
- newen 7y ago
  It's especially hilarious because he is comparing projects done by bootcamp graduates to projects done by highly trained PhDs. Some people just don't have a clue about the massive difference involved in webdev type projects and complex engineering projects.

robertAngst 7y ago

This is good that you are calling this out. I've seen non-science in Healthcare, and I've spoke out against it. I don't really understand why people are stubborn when there is data, and the data is solid. If I could wish anything in software engineering- follow the data.

icxa 7y ago

I think a more eloquent way is to say fundamentally creating long lasting software structures is more of an art rather than a science, and you can't just tell someone "go practice these 5 things and you'll be the next Picasso" you just have to do it a lot of times, over and over, learning from your mistakes. There are no shortcuts. You have to build a ton of software, and make a lot of mistakes, and most importantly, learn from them. Then there's the other half of the equation and some people just have the creative mind to imagine the right framework, or tool or library or abstraction or architecture for the problem at hand.

sgift 7y ago
The important thing is: Picasso knew what to study. Over time art had established a canon of things which helped people to get better at classical arts. Only after he studied that canon in depth and for a long time he could then break into new territories and start breaking rules intentionally to develop his own style/school. Our craft is very bad at providing such a canon. It is even anti-intellectual in parts ("what do you mean you cannot be a master after x weeks? You are a gatekeeper! you suck"). That and we are still not sure what is important and what isn't (i.e. what should be part of the canon). Our medium of study changes all the time. Arts medium of study is reality and reality, for all our advances, doesn't really change.
- icxa 7y ago
  We absolutely have a canon. You show me someone who has studied Dikjstra, Turing, Hoare, who has taken the time to pour over the Art of Computer Programming and Structures and Interpretations of Computer Programs, and poured over Ivan Sutherland, is familiar with the early days of IBM, Fairchild, Xerox PARC, and hundreds of other classics we consider to be "canon" that I am surely missing (just shooting from the hip here), and you'' be showing me, more likely than not, a damn good programmer. We have a canon, we just don't have the same studios, detail-oriented attention spans we once had, and the technology we have built is partly to blame. Maybe related, you were once considered an ignorant brut in this country and others if you haven't read a library of literary classics, now we have kids growing up who barely know Shakespeare, or the rich body of the writing of the abolitionists or slave narratives (how many people you think in this country that even know 1/100th of what Henry Louis Gates Jr knows?) Do you think W.E.B Du Bois and Booker T Washington are common names anymore? I remember when everyone had the preamble of the Constitution and the Gettysburg Address burned into their minds, now we can't be expected to remember questions for a simple AWS Certification Exam, it's pathetic.

quickthrower2 7y ago

Software is an interesting animal because what PHP and NodeJS have in common is they were created as hobbies, as were a lot of the frameworks and software tech the world relies on. Maybe there is a bit of us software engineers liking the shiny new thing? There are a lot of dynamics going on. One is programmer's curiosity but then there is a financial incentive to be on the latest tech. If you see React jobs paying more than Angular jobs, it might be a sign to jump ship which has nothing to do with technical merits. Then there is things like Blockchain that excites investors and techies alike, even when it's a useless solution for something. People sitting in a room deciding the genuine best thing to do is going to be hard with all these dynamics going on.

siruncledrew 7y ago

The "opinions" part is true, and has implications on whoever is paying for the software and whoever is maintaining it (with their own opinions, of course). A company/client will often make decisions based on "opinions" too. "We need a website, what should we use to make it?" It's a bit of a blank canvas situation at first where a developer/engineer could come in and say "We should do it X way with Y libraries because <some opinion on why it's the best stack>". Devs could have totally different takes on the same canvas by a matter of opinion. If I were to ask people "What type of car should I buy?", I would likely get a whole variety of answers from hybrids to SUVs to European and Japanese cars based on who I asked and what their own preferences and tendencies are. I may end up happy or I may end up unhappy depending on which opinion I'm swayed by and how much rigor I put into investigating the different opinions. Software can be very similar when people providing the "opinions" are caught up in looking to use specific tools over trying to figure out an appropriate solution. When developers/engineers/designers/managers immediate choose tools as a blanket solution over understanding the scope and use-case for context, it's a sign to heavily question the authority of their opinions.

hvidgaard 7y ago

> We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects. No industry can, unless it's something that has been done repeatedly before. If you ask a frontend designer specializing in WordPress to make a theme for WordPress and implement it, they can estimate it accurately. What is thoroughly missing from this debate is the age old project management terms of scope and risks. As soon as you enter unknown land, the risk goes up. And risk means uncertainty and probably expenses. And if the people writing the checks change the scope, the original estimates goes out the window. If you're making a building, it's easier to understand that you cannot just change the scope after the blueprint is made. You have to get an architect to remake it, and everything done and ordered so far may or may not be salvageable. It happens in all industries, but just more so in software development.

dagw 7y ago

We can't even accurately estimate the cost of a complex project given our choice of tools We've been building bridges for thousands of years, and still the relatively simple bridge they built down the road from me took 2.5 years to complete instead of the estimated 9-12 month.