4 ms·

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can d

But this isn’t engineering. This is the IT equivalent of building a bridge and driving successively larger trucks over it. In real engineering fields, you can do predictive analyses based on prior empiricism. There’s none of that in our fields until you’re talking about very small systems where, for example, the stack consumption can be determined in advance and the scheduler can give you guarantees about worst-case performance. And this is to the detriment of all of us. That’s why you’ll never hear me call myself an engineer.

sjburt 6y ago
If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. We don’t. We built wind tunnel models, we taxi them around at higher and higher speeds, we put them in machines that wiggle the wings at high loads. The first flight is a little hop and then right back down. Months later there might be a big ceremony with VIPs where the new plane takes a lap around the airport as it’s “first flight”. And there are mistakes song the way, giant ones that add years to the schedule and tiny ones that engineers argue over even telling their boss about. Sure there’s planning and experience, just like she knew to use epoll and not select, and that Linux can handle thousands of threads per process. But there’s no magic to it, just lots and lots of human attention and testing along the way.
- noir_lord 6y ago
  > If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. Didn’t Boeing just get caught trying that?.
  - acdha 6y ago
    The problems were identified early on but the NTSB, FAA, and their own engineers were overruled by the business people: see e.g. https://www.nytimes.com/2019/10/02/business/boeing-737-max-crashes.html https://www.nytimes.com/2019/10/02/business/boeing-737-max-c...
- wondringaloud 6y ago
  She developed a prototype based on a hunch and a whim. Great work, no doubt, but engineering isn't based on intuition and some experience. Real engineering has a goal or specification in mind, and then proves through modeling, analysis, and _finally_ testing that it meets those specs. Whipping something up and then seeing what it's capable of doesn't qualify.
  - kragen 6y ago
    "Whipping something up and then seeing what it's capable of" in simulation or prototype is also known as "modeling and analysis". Prototypes and testing are definitely a valid, even central, part of engineering.
ardit33 6y ago
What is stress load testing then? Most large companies do perform something to this.... Most large companies do some stress load testing first for any new system. Then they release to few percent of the users (less than 10%) and gradually increase to the rest of the userbase. I worked at Spotify, when Tidal was launched. They had failed to do proper capacity testing, and the service failed under the load the first week and it showed. But most mature large company tend to be really good on this. It is remarkable how many tech companies have managed to stay mostly up with very few outages, given this whole pandemic situation, where everybody is online. I'd say working in large scale deployment is proper engineering .... creating a simple webpage, maybe not. Deploying that webpage to millions of users, it is. Also, don't forget that bridges have been made since the dawn of time, while tech and the internet are very very young in human terms.
- EdwardDiego 6y ago
  > It is remarkable how many tech companies have managed to stay mostly up with very few outages, given this whole pandemic situation, where everybody is online. I must admit that it was very gratifying watching all our engineering decisions pay off when our system started seeing record high traffic every day and scaled effortlessly and with no outages - the traffic that came with lockdown is, even on our slower days, twice our planned for and tested for high water mark. But it took us about 4 years of consistent effort in changing our organisational mindset all the way through, devs, testers, product managers, c-suite members, to get here. 4 years ago, we would've been waking everyone up and going without sleep for a couple of days trying to get something back online, then fixing the next system down the line that failed because of the load, then the next one, and then writing long post-mortems for our business team.
wondringaloud 6y ago
I'm glad someone else sees this the way I do. What the blog writer did was tinker with something. They didn't engineer it. I was a mechanical engineer prior to switching to software. As a general rule, the things we do in software are very distant from engineering.
- zaphar 6y ago
  What the author did was build a prototype to demonstrate and explore what was possible. That is exactly what engineers do when exploring a problem.
  - Alupis 6y ago
    When you hear "Engineer", you often think of calculus, statistics, formal testing, requirements gathering, documentation, repeatable results, etc... along with a fundamental understanding of the problem space and possible solutions. I think this is akin to NASA working on the Apollo program vs. someone in their garage attempting to build a go-cart for the first time. When you just slap things together and see if they work - are you really engineering? Can you exactly repeat the process and achieve exactly the same result every time? I think we often cross "research and development" with "engineering". Exploring a problem space and tinkering with concepts isn't engineering. Taking what you've learned, planning out and executing a solution to a precise set of requirements, and being able to repeat your steps and achieve those results again and again - is engineering.
    - talaketu 6y ago
      Well I don't - maybe you do. I think more along the lines of "ingenuity" as described here: https://interestingengineering.com/the-origin-of-the-word-engineering https://interestingengineering.com/the-origin-of-the-word-en...
    - Rury 6y ago
      >When you just slap things together and see if they work - are you really engineering? Why not? That's basically what testing is. Which was one of the attributes you attributed to "Engineer" >formal testing >I think we often cross "research and development" with "engineering" My general take: Scientists primarily focus on learning and proving new knowledge & ideas. (i.e. they research) Engineers focus in using proven knowledge and applying it to design and create things or solve problems. When things are not perfectly certain, they can prototype and do tests similar to how scientists do experiments (e.g. aerodynamics in wind tunnels). (i.e. development)
modal-soul 6y ago
Saw an interesting talk just about this topic [1] The gist of it was: Other engineering disciplines use the techniques you've mentioned because of the the costs, both time and money, associated with getting it wrong. Software engineering lends itself to different methods of development and construction, as the costs associated with getting it wrong or making changes after the fact are much lower. (For most applications, anyways). As such, (this definition would be another sticking point) these less rigid methods should still be considered engineering, with engineering being a balancing of resources with outcomes, not fixation on mathematical models. [1]: https://www.youtube.com/watch?v=RhdlBHHimeM https://www.youtube.com/watch?v=RhdlBHHimeM
- 6510 6y ago
  *Assumed to be lower. What is actually happening we don't know. IT is dramatically changing everything. It's not all bad but it isn't all good either. I hate to give examples since it is really vague what goes in and what comes out and people tend to mistake an example for full coverage but... for example, we have no idea what drives suicide rates.
  - DanBC 6y ago
    > for example, we have no idea what drives suicide rates. This is a good point but I wanted to make it a bit more clear. Across a population we have a good idea of the risk factors and of the things that increase rates of suicide: deprivation, abuse, substance misuse[1], previous self harm. The bit we have no idea about is how to apply these to an individual person to see if they're high or low risk of suicide. There are a load of different tools that input lots of different information and put out a risk rating, and none of them are as good as just asking the person "what do you think your risk is?"
Minor49er 6y ago
I thought the author was referring to the kernel threading, not necessarily to the experiment that was put together
knolax 6y ago
> building a bridge and driving successively larger trucks over it. And that's not engineering?

sjburt 6y ago

If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. We don’t. We built wind tunnel models, we taxi them around at higher and higher speeds, we put them in machines that wiggle the wings at high loads. The first flight is a little hop and then right back down. Months later there might be a big ceremony with VIPs where the new plane takes a lap around the airport as it’s “first flight”. And there are mistakes song the way, giant ones that add years to the schedule and tiny ones that engineers argue over even telling their boss about. Sure there’s planning and experience, just like she knew to use epoll and not select, and that Linux can handle thousands of threads per process. But there’s no magic to it, just lots and lots of human attention and testing along the way.

noir_lord 6y ago
> If “real engineering” worked the way you described, we would test planes by filling them full of passengers and flying them around the world. Didn’t Boeing just get caught trying that?.
- acdha 6y ago
  The problems were identified early on but the NTSB, FAA, and their own engineers were overruled by the business people: see e.g. https://www.nytimes.com/2019/10/02/business/boeing-737-max-crashes.html https://www.nytimes.com/2019/10/02/business/boeing-737-max-c...
wondringaloud 6y ago
She developed a prototype based on a hunch and a whim. Great work, no doubt, but engineering isn't based on intuition and some experience. Real engineering has a goal or specification in mind, and then proves through modeling, analysis, and _finally_ testing that it meets those specs. Whipping something up and then seeing what it's capable of doesn't qualify.
- kragen 6y ago
  "Whipping something up and then seeing what it's capable of" in simulation or prototype is also known as "modeling and analysis". Prototypes and testing are definitely a valid, even central, part of engineering.

ardit33 6y ago

What is stress load testing then? Most large companies do perform something to this.... Most large companies do some stress load testing first for any new system. Then they release to few percent of the users (less than 10%) and gradually increase to the rest of the userbase. I worked at Spotify, when Tidal was launched. They had failed to do proper capacity testing, and the service failed under the load the first week and it showed. But most mature large company tend to be really good on this. It is remarkable how many tech companies have managed to stay mostly up with very few outages, given this whole pandemic situation, where everybody is online. I'd say working in large scale deployment is proper engineering .... creating a simple webpage, maybe not. Deploying that webpage to millions of users, it is. Also, don't forget that bridges have been made since the dawn of time, while tech and the internet are very very young in human terms.

EdwardDiego 6y ago
> It is remarkable how many tech companies have managed to stay mostly up with very few outages, given this whole pandemic situation, where everybody is online. I must admit that it was very gratifying watching all our engineering decisions pay off when our system started seeing record high traffic every day and scaled effortlessly and with no outages - the traffic that came with lockdown is, even on our slower days, twice our planned for and tested for high water mark. But it took us about 4 years of consistent effort in changing our organisational mindset all the way through, devs, testers, product managers, c-suite members, to get here. 4 years ago, we would've been waking everyone up and going without sleep for a couple of days trying to get something back online, then fixing the next system down the line that failed because of the load, then the next one, and then writing long post-mortems for our business team.

wondringaloud 6y ago

I'm glad someone else sees this the way I do. What the blog writer did was tinker with something. They didn't engineer it. I was a mechanical engineer prior to switching to software. As a general rule, the things we do in software are very distant from engineering.

zaphar 6y ago
What the author did was build a prototype to demonstrate and explore what was possible. That is exactly what engineers do when exploring a problem.
- Alupis 6y ago
  When you hear "Engineer", you often think of calculus, statistics, formal testing, requirements gathering, documentation, repeatable results, etc... along with a fundamental understanding of the problem space and possible solutions. I think this is akin to NASA working on the Apollo program vs. someone in their garage attempting to build a go-cart for the first time. When you just slap things together and see if they work - are you really engineering? Can you exactly repeat the process and achieve exactly the same result every time? I think we often cross "research and development" with "engineering". Exploring a problem space and tinkering with concepts isn't engineering. Taking what you've learned, planning out and executing a solution to a precise set of requirements, and being able to repeat your steps and achieve those results again and again - is engineering.
  - talaketu 6y ago
    Well I don't - maybe you do. I think more along the lines of "ingenuity" as described here: https://interestingengineering.com/the-origin-of-the-word-engineering https://interestingengineering.com/the-origin-of-the-word-en...
  - Rury 6y ago
    >When you just slap things together and see if they work - are you really engineering? Why not? That's basically what testing is. Which was one of the attributes you attributed to "Engineer" >formal testing >I think we often cross "research and development" with "engineering" My general take: Scientists primarily focus on learning and proving new knowledge & ideas. (i.e. they research) Engineers focus in using proven knowledge and applying it to design and create things or solve problems. When things are not perfectly certain, they can prototype and do tests similar to how scientists do experiments (e.g. aerodynamics in wind tunnels). (i.e. development)

modal-soul 6y ago

Saw an interesting talk just about this topic [1] The gist of it was: Other engineering disciplines use the techniques you've mentioned because of the the costs, both time and money, associated with getting it wrong. Software engineering lends itself to different methods of development and construction, as the costs associated with getting it wrong or making changes after the fact are much lower. (For most applications, anyways). As such, (this definition would be another sticking point) these less rigid methods should still be considered engineering, with engineering being a balancing of resources with outcomes, not fixation on mathematical models. [1]: https://www.youtube.com/watch?v=RhdlBHHimeM https://www.youtube.com/watch?v=RhdlBHHimeM

6510 6y ago
*Assumed to be lower. What is actually happening we don't know. IT is dramatically changing everything. It's not all bad but it isn't all good either. I hate to give examples since it is really vague what goes in and what comes out and people tend to mistake an example for full coverage but... for example, we have no idea what drives suicide rates.
- DanBC 6y ago
  > for example, we have no idea what drives suicide rates. This is a good point but I wanted to make it a bit more clear. Across a population we have a good idea of the risk factors and of the things that increase rates of suicide: deprivation, abuse, substance misuse[1], previous self harm. The bit we have no idea about is how to apply these to an individual person to see if they're high or low risk of suicide. There are a load of different tools that input lots of different information and put out a risk rating, and none of them are as good as just asking the person "what do you think your risk is?"

Minor49er 6y ago

I thought the author was referring to the kernel threading, not necessarily to the experiment that was put together

knolax 6y ago

> building a bridge and driving successively larger trucks over it. And that's not engineering?