And this is to the detriment of all of us. That’s why you’ll never hear me call myself an engineer.
And this is to the detriment of all of us. That’s why you’ll never hear me call myself an engineer.
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.
Didn’t Boeing just get caught trying that?.
Whipping something up and then seeing what it's capable of doesn't qualify.
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.
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.
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?"
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.
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.
And that's not engineering?
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.
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.
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)
We don't run test suites on our software to see what it does. We run test suites to validate it operates as it is supposed to.
I think the way you described testing is more in line with tinkering and research rather than engineering. It's experimentation, not testing.
When the outcome is unknown and unreliably unpredictable, it's research (tinkering). When it's predictable and has a known, repeatable outcome, it's engineering.
Yeah that's fair.
I had originally skimmed the article, but after re-reading it the author apparently admits they didn't put any careful thought into what they made. No real goal. Just slapped stuff together so to speak. Which I'd agree doesn't quite sit as engineering to me...
As the title says, this is dumb code. But it makes use of years of engineering effort to deliver a result which can get you very far without thinking about the low level.
A seasoned engineer notices that everyone is only building suspension bridges all of a sudden.
They point out that you can span a stream with some bricks or rocks and a bit of mortar, and are ridiculed.
Next, they build a highway overpass out of concrete pylons, and stress test it to 10x the necessary engineering load, and point out it cost 10% as much as a typical contemporary suspension bridge. That’s this article.