Why are we so bad at software engineering?
bitlog.com
bitlog.com
1. Software is easy to fix. Compared to other construction disciplines, software is the cheapest to fix.
2. The consequences of failure are typically minimal. Most software is not mission critical. Failure means minor inconvenience for a lot of people. Moreover, since your competitors are no more reliable than you are, you don't even stand to lose customers by having an occasional failure. (This is the one the article discusses.)
3. Software has more degrees of freedom. Unlike physical building disciplines where the types of materials are limited and generally well known, and where the number of physical dimensions is at most three, software takes place in an extremely complex and multidimensional operation space. Moreover, we have no evolved intuition about how things behave in that space.
4. Comparatively minor errors result in comparatively major failures. If you forget one rivet on a building, the engineering tolerances will make it such that the building will not fail as a result. But it is not really possible to make a server resilient to null pointer exceptions. It either works or it doesn't. Software fails partially much less often than physical things.
If you're laying down the bricks for a house, there really aren't any cheap tricks or shortcuts. Building two houses takes twice as many bricks as building a single house, and so on. We could say that brick usage scales linearly with house construction. This is a bit of a bummer for bricklaying enthusiasts, but on the other hand, a single brick out of place is probably not going to bring your roof crashing down.
Software is different. Often, the distinction between processing 100 files and 1,000 files is minimal at best. This ability to scale effortlessly is often the best thing about software, but the same non-linearity is also the price we pay for power. A single subtle programming error can cause millions of dollars' worth of damage and bring massive systems to a grinding halt.
Overall, I think this is what makes software interesting and exciting to work with, but I can understand how it can pose a steep challenge once things like reliability and security become major concerns. The way I see it, much of research and development into better programming languages and tools has been to see how we can systematically mitigate these kinds of propagating errors and make our systems more robust to mistakes.
Oh, there are plenty of them. Substandard bricks, substandard mortar, inadequate foundation prep, walls not being straight and plumb, etc.
It's just that brick construction is both easy to inspect and well known how to do it.
Software doesn't fail so dramatically - small annoyances, for example, is easily dismissed. Even if there are many of them.
This stuff is easy, just look over the code- I mean blueprints before commi- I mean building and you'll be fine. Everyone knows you're supposed to put the weep holes in, so make sure to do that.
The collapse may be after some years. I can't find any evidence that the builders have even had to pay for remediation, let alone compensation.
The Grenfell fire has an even more egregious problem in that the builders are being granted immunity from prosecution before testifying.
That's not where the troubles come in. The problems we face are generally those of design.
Contrast that with high-complexity engineering projects, e.g. fighter planes or Apollo project, where it usually turns out the official design specs tell at best half of the story, and most of the knowledge was contained in the heads of the builders, encoded in the shape and adjustments to tooling they used to build those vehicles. Which of course creates a problem today, now that both the tooling and the builders are long gone - but it demonstrates clearly how a build process made of people can fix a lot of errors in the design.
Actually,software's production process is a mess that's designed to mitigate the colossal mess that's the typical engineering culture observed in software development. I mean, the only reason that a procedure needed to be devised to deliver automatically and immediately any fix to a software system is the fact that there was a need to repeatedly and systematically fix the product that was being delivered to production. That shit doesn't fly in engineering fields.
You could just as easilty as say software is extremely costly to fix. Software is labor intensive so fixing it can cost a lot of labor of extremely high paid people.
But really, I think the way to put it is "software seems much easier to fix than a physical object." It seems that way to the software engineer and to the manager talking to the software engineer.
Not only are there no physical reminders of how difficult changing a given piece of software is but the challenge is primarily in the unexpected and the illogical. Fixing routine X would be easy if it wasn't unexpectedly and/or illogically tied into a variety of other functions. And this stream of unexpecteds is extremely easy to forget/discount.
Doing a recall on a popular hardware product is orders of magnitude harder than issuing a software update for that same product.
There have been a few scenarios at my job where it was easier to just solve a problem in hardware, but once a bunch of hardware gets shipped, only software can save us.
But my comment above wasn't really to say software was more was less costly than hardware. It was mostly say that software is more unpredictable than hardware.
Developing a fix for a software issue can be expensive, deploying the fix is relatively cheap in today's world with automated software updates.
Compare to e.g. fixing a design flaw in a car, where the development of a fix can be relatively cheap but deploying it (recalling all affected cars to the dealer to have new parts installed) is pretty much always expensive.
This problen has been solved 30 years ago. Maybe we should pay more attenntion to improvements in our ecosystems...
That alone makes software more critical than we give it credit for. Especially if there's many people.
Let's say you've got some mildly popular piece of software, with 10,000 users. Let's say a particular inconvenience means they each waste like 10 seconds per day. Total waste is 100,000 seconds per day, or 28 hours. Per day.
This adds up pretty quickly.
[1]: http://www.leparisien.fr/info-paris-ile-de-france-oise/metro...
I'm certain that even the current Windows 10 search bug doesn't come close to that kind of impact.
I have chosen the small end of the scale, but let's think about Microsoft Word for a second. Or how much time Adobe Photoshop takes to start up.
... but a systemic design error can cause it to fail, and this happens a lot when new techniques are developed and deployed. Change implies the increased possibility of failure.
I don't know why people keep holding up the construction industry as the paradigm here. Large civil engineering projects are notorious for cost overruns. The industry used to routinely get people killed during construction; only really post WW2 in the West has this been solved. It's still possible to have big post-construction disasters. One of the big political issues in the UK at the moment is the deployment of flammable cladding on multistorey buildings - this turns a fire in a single unit into potentially the loss of the whole building and many of its occupants.
You've all seen the Tacoma Narrows bridge video, right? But all sorts of innovations have their problems, mostly invisibly to the public. The last time someone attempted to disrupt tunneling before the "boring company", the "New Austrian Tunneling Method", it turned out to have serious problems: https://www.hse.gov.uk/pubns/natm.htm
The fact that materials used in construction are not that plenty, thus generally well known, is not a law of nature. In fact, it's the direct result of a radically different engineering culture. In construction, you only use building materials and techniques that are well known and demonstrably robust and performance. Even in new building elements and materials and techniques, before they can be adopted by the public first they need to be subjected to a whole batch of certification procedures and approved by a bunch of regulatory bodies.
Hence, a brick is a brick is a brick, because bricks are standardized and all the bricks you have contact with are actually certified and must comply wiht standarda such as
https://www.astm.org/Standards/C62.htm
The fact that software development is a mess is precisely due to all the shortcuts and refusal to follow common practices established in engineering.
For better and worse. Most older building materials do not pass current building codes¹, even though many of them are perfectly safe and robust, while being way more ecological. Usually more labor intensive yet often still cheaper.
¹ depending on region
That's primarily because they had to comply with the requirements of that time instead of requirements created in the future.
Nevertheless, rigorous compliance is not the point. The point is that the whole industry is focused on standardization, complying with specs, and use only tried and true technologies and techniques. That's not what the software development industry is about.
I was merely pointing out it has significant and serious downsides as well (which may be overwhelmed by the upsides).
If we were to apply similar principles to software development, it would have benefits and also downsides, both of which should be considered.
Shut them all down, watch the average quality of software improve dramatically, immediately.
Next have someone qualified on every single board of directors and have each board create an appropriate sub committee. The same way you have a qualified accountant and audit sub-comittee. Have someone with proper CS & IT credentials and an IT oversight comittee. (Sure mostly the initial massive win is warding of the vampires mentioned in the previous paragraph but there is huge, huge value beyond that.)
Having ignorant people making the resource allocation decision is idiotic in the extreme and leads to overpriced, rubbish quality outcomes. Like deciding to use some garbage vote countinga app that doesn't and can't work - who did that? Can we just say they are utterly ignorant of the field they made important decisions concerning or do we need to get their name and demonstrate it.
Why are we so bad at software engineering? We are not! We just aren't. We do amazing things. We can do it reliably. We can do it economically. Software is f*&king awesome.
Why is there so much corruption in the decision making process leading to garbage quality overpriced, risky and idiotic software? Now that is a better question to ask.
Why is the idea of actually regulating foolhardy risk-taking startups (self-driving, privacy invading, turn-key facist state surveiling etc) so controversial? Because we can't even make good decisions about CRUD development at a policy level in a fortune 500 company - forget a policy decsion at a government level, you know it's going to be awful and redolent with regulatory capture.
We just need to grow up and stop blaming the geeks for the utter manure shoveled at us by ignorant jocks on golf courses determined to exclude anyone with actual understanding, insight and knowledge. And the manure shoveled by the actual geeks with a massive risk appetite and zero care for externalities beyond their startup making cash. Really. That's it. That's all.
Software is FINE. Decision making about software is SO bad, so awful, so hideous we try not to think about it lest it rots our minds with despair.
And to add the icing to your cake, more often than not there are no consequences for those making these bad decisions.
Not for the folks making the bad decisions, anyway.
How is making software more political than doing maths?
The gp is talking about: requirements; allocating budget between research, salaries, testing, development, support, marketing, exec's pockets, shareholder's pockets, etc.; decisions about which standards to support or not; agreements with other firms; etc. etc. etc.
Software is the automation of processes. Processes are intensely political, because they effect the world.
Creating software, whether in a corporation or in an open source project, is more often than not a process that involves many stakeholders, processes, and yes irrational traditions or even "religious" ideology (spaces vs. tabs, etc.). So any time you have more than one person writing a program, things will get political. The decisions behind software-making is a political process.
Mathematics, in contrast, is probably not political except in the higher levels of academia.
I agree with you that the software industry seems to struggle more with these kinds of political issues.
However, there are many human endeavours that also require input from large numbers of stake holders and they seem to cope (i.e. going to the moon, building a bridge, building a skyscraper etc.).
That suggests the problem is not so much the large number of stake holders, but rather the software industry struggling to cope with situations requiring large numbers of stakeholders.
That's an explicitly political position.
Besides, the software engineering process is full of political decisions. What does an “unbiased” search engine mean? When you build a recommendation service, do you intentionally reinforce bias of the user or expose the user to other points of view? How do you define and handle abuse of your service? I could go on and on.
Which they would be inclined to do given this scenerio.
Which company is making good Quality software in your view?
Look at all the successful startups disrupting industry by writing software. Note the total lack of vampire-squid consultancy in their codebase.
Look at the public service orders of magnitude cost blowouts and non-functionality that is the norm. Look at the domination of vampire-squid consultancies right there.
It's really not difficult to see unless you're determined to keep your eyes shut. The vampire-squid consultancies should not exist and are a symptom and proof of the prevalence of misallocation of resource in decisions made by the wholly ignorant.
So what did they do right, and what are they continuing to do right other than infecting large organizations with their blood sucking tentacles in a manner which closely resembles a Hokusai woodblock-print and removing some of the favored organs of the management end of the org chart that to be honest, they probably weren’t using anyway?
It has nothing to do with Hokusai.
Excusing vampire-squid consultancies on the basis that the conditions are ideal for their horror is simply unconscionable.
They are a disgrace to our industry. They desperately, desperately need everyone to believe "We are bad at sofware engineering" to continue their con. But we are NOT. We can do software engineering and have done it well, so many times, so publically with such spectacular success disrupting powerful incumbants from the garage with nothing more than software. We will continue to do so. Who is next? You? Me? Absolutely not anyone hiring a vampire squid. Guaranteed.
I get rafted in as a vendor for part of a package that several of them offer to Fortune 500s. They provide negative value - it would be massively easier if I could just hook up directly with the end-customer's IT and do what needed to be done with competent people who know their job and what they want. But I have to play telephone through two or three layers of project managers in Delhi and Bangalore and an ever-shifting array of other people of indeterminate status and role.
You seem to be equating 'disrupting an industry' with (high) quality software. Could you please elaborate how this holds?
I would also appreciate examples of high quality software, I don't care about the impact of said software.
You're never going to see that from IBM. You will get an email from a marketing team telling about all the other services you may enjoy.
I think it makes sense to note that corporations don't adhere to GAAP voluntarily, or because it makes good business sense. They do it because they will be de-listed from stock exchanges and shut down by the government if they do not.
The stock exchanges won't do this for "tech malpractice." From a financial standpoint, tech malpractice is just another calculated risk. Versus financial malpractice, which creates an unlevel playing field on the stock exchange itself. And history has shown that the fallout from "tech malpractice" ends up costing comparatively low dollar amounts anyway.
This leaves me at: this won't improve without government regulation.
On the other hand, lack of government regulation has tended towards software costing $0.00 and very rapid evolution and innovation.
But the point is taken. So what proportion of $0 software, rapid evolution and innovation has come out of vampire-squid consultancies and their billion dollar revenue streams?
The upper limit of my estimate is 0%.
Having an IT committee on the board of directors is a pretty light regulation. Start with the banks. Your money is just bits on their disk.
Just having some people who get fired when the project costs a billion and fails is useful.
Disagree. The cost is instead pushed to the consumer.
How many man hours were involved in fixing HeartBleed?
How much time/money have people lost due to security/tech malpractice at Equifax?
I've never been in a position where _lives_ were on the line, but I have been on projects where bugs would cost the company real money. The engineering mindset changes quickly.
Just because the company found a clever way to shift the cost off their balance sheet doesn't mean it's gone. It's just been hidden.
> Shut them all down, watch the average quality of software improve dramatically, immediately.
This is naive. All of those organizations hire extremely smart people and pay them well.
The issue isn't them existing; instead, it's companies wanting "bodies" of developers/operators at the lowest price, hundreds of millions of folks in more impoverished areas willing to answer the call, regardless of the stipulations, and this being extremely profitable when done at scale. Blame executives continuing to think that tech is a cost to be optimized, not an investment to care for.
This pendulum is starting to swing in the other direction (paying for quality not quantity), but it's a slow adjustment.
And what even counts as "software engineering"? If I want to write a VBA script in my spreadsheet am I supposed to ask some anointed expert for approval? It's just ridiculous and totally unworkable.
If you are running a fortune 500 company and your vba spreasheet is a material expenditure in your financial statements then YES get it approved by the IT committee. (If you get a vampire-squid consultancy to build it for you it probably will be too!) Non-material expenditure? No, who cares if it's not material? (Material has a GAAP definition and is deemd to be something like 5% of the balance of the asset or liabiltiy or impact more than 5% of revenue or expenses). Someone who has studied more recently than me can probably tell us what GAAP says is material for audit purposes.
This is not true everywhere. In my country, accounting is regulated [0] and can only be performed by credentialled professionals, registered on the Federal Council of Accountants.
[0] http://www.portaldecontabilidade.com.br/legislacao/resolucao...
My experience has been that devs would much rather not make estimates because they know they can't do it, and when their management is itself made of engineers, they aren't asked to. Engineering-led businesses find other ways to avoid the need for estimates.
Heartbleed should be the equivalent of the Kansas City Hyatt disaster for our profession. It is a failure mode that is so elementary, so obvious, so easily avoidable that its occurrence should be a sign of deep failure in several processes meant to avoid it, and it should be grounds to open an investigation into criminal negligence. And yet... OpenSSL had no process for catching this stuff. Very few software projects do--I suspect yours do not either.
And let me guess, the sub-committee should have its own sub-committee, to hold meetings to prepare for the meetings to prepare for the meetings?
It reminds me of the company (which one? Philips?) which got so fed up with these people that it put all of them in a new department. Then, they got to hold their meetings and the rest got to do their work and everyone got along.
"Software engineer" today is just a job title. It makes us sound cool, but it has about as much to do with engineering as "Scrum master" has to do with rugby. In lots of places, you don't need to have an engineering degree or be a certified engineer to claim the title.
Teams that actually practice Software Engineering, like the famous Lockheed shuttle group, are as good at it as we are at any other branch of engineering.
It's wildly misleading to use the same word for an app written by a few programmers in a couple of months (like the Iowa Caucus app) and the Space Shuttle control software (maintained by hundreds of people, with an average of 1 bug per release), and everything in between. It'd be like letting anyone call themselves Doctor.
Upd: is there AutoCAD for software?
Of course tethering to education requirements doesn't mean much. I think a formal guild where you build your representative value by the endorsement and status of others, and if you fail, not only are you brought down, but those that endorsed you will lose cred as well. Setting up such a system would be difficult and take time, and I'm unsure if it would ever reach critical mass.
Also, unlike doctors and other fields, I don't think you should have to be formally licensed to work in software. Most initial developers are, were, and continue to be cross trained from other fields.
That’s what my question is about!
Building engineer knows or reads N54.s-1e/624 “on public safety in a first floor lobby” to design it. It may specify various requirements like no sharp edges, glass walls need stripes on them, non-slippy floors, etc. Then when they need to add an electronic lock to all main entries, they contract with a seller whose locks are licensed with LS9-41.3/FLL. Then firefight inspection validates these entries for public safety again, involving standardized legal rules.
I don’t even try to describe the actual building from the ground to the concrete structure process, because that will be too naive. Lots of standards, requirements, ready-to-use plans, or a project approval process that requires half a year for a shallow review of all documents in many controlling departments.
What I’m interested in, is there such a level of engineering in software at all. I don’t know about anyone who did something like a regular building engineer does at the / before the construction site, but in software. Is there such a thing like Software Engineering at all? All popular software doesn’t seem to have signs of no-dog-house, when you read their code.
In terms of the dog-house, there's that rule "Build one to throw away". Since no two software projects are similar, the only way to truly know what you're building is to build it, see what works, throw it away, then build it properly.
Part of what makes software so good is that you _can_ upgrade the skyscraper while people are in it, metaphorically hardening floors or adding new levels.
And yes, good software engineers are expected to know those practices.
Unfortunately, the efforts on some of these systems are much harder to work through in practice than something created more organically.
You mean like, a tech firm? Or a software consultancy business? :)
Bob screws up big time... complaint filed with guild board for review... board revokes Bob's master status (back to journeyman) and notes on Steve and Phil's record.
If Steve and/or Phil get too many hits, they lose their status as well.
Bob was trained by the great manager Tim. Tim endorsed Bob from internship to junior engineer to senior architect. Steve and Phil both later recommended Bob for promotion to CTO.
Then Bob screws up big time. The board of directors gets involved. Bob is fired and eventually gets a new job as a middle-manager or lower in some other firm, or if the screwup is large enough, takes early retirement.
The "guild" is doing the same things as a company does. But judging skill, success and failure is quite subjective. That's why we need so many competing firms to get results. A single guild would be like everyone working for a single company. It'd yield very poor results.
JetBrains IDEs?
Now, I don't think apprenticeships are unmitigated positives - another function they serve is to limit field entry. But they are, I think, far better than what "we" do, and sorry, pair programming is not a substitute.
I don't know what does AutoCAD have to do with anything. I use it for modeling parts that I machine as a hobby; that doesn't make me a structural engineer.
>But they are, I think, far better than what "we" do
They should be far better, but an engineer is not an abstract position. If all it needs to be an SWE is to know 3-book algorithms and some patterns (just my uneducated guess), then it is not engineering. See my other comment for details. Yes, a CS degree adds to ones competence, but it is like saying that physics degree allows you to build an elevator. It doesn’t, it will be just a nice science-grade dog house level elevator, because learning physics doesn’t make you know all standards that elevators require, legally and practically.
I do think software engineering as a discipline exists. Looking at the definition written by the American Engineers' Council [1], there have definitely been teams I've worked on where we met this criteria. There are teams like the Lockheed shuttle group who average 1 bug per release that clearly embody this criteria too.
Also, my CS Masters is accredited as meeting the educational requirements for Chartered Engineer status (which I'm hoping to achieve once I finish) so it's clearly accepted by some in the engineering community!
[0] https://hydra.iohk.io/build/789825/download/1/ledger-spec.pd...
"[M]any"? Outside of a handful of really anal jurisdictions like Canada I am not aware of any where this is a requirement. I chose not to go this route because I didn't see the value in it for the type of electrical engineering I was interested in.
https://www.merriam-webster.com/words-at-play/the-history-of...
Someone who can make a boxy UI, hook those boxes up to {{text templates}}, and make GET/POST/PUT/DELETE calls (to RESTful API just thinly wrapping a SQL DB) can recreate a shocking number of popular web and mobile apps. Those are CRUD apps.
Non-CRUD apps have an unusual (non-boxy) UI, non-trivial backend processing/integrations, or both.
edit: although looking back at the article and paying closer attention to the title, I can see why the point I replied to was made.
I’m not sure that’s true, or perhaps more accurately, I’m not sure that bar is high enough.
No other branch of engineering, at least none that come to mind, have to deal with the number of variables that any medium-sized software application does. Software, being infinitely malleable and running on a seemingly infinite variety of hardware in an infinite number of environments, is vastly harder than any other engineering.
I'm not going to argue if this is right or wrong as I don't have a Software Engineer's perspective. My background is in chemical and materials engineering in heavy industry (mining and manufacturing sectors).
I've worked in Operations and Process Engineering positions (https://en.wikipedia.org/wiki/Process_engineering) and in more recent years I've been employed as a "Technology engineer" which is essentially integrating new technology and process improvements and optimizations into existing industrial applications.
The scope and complexity of what Engineers deal with daily might surprise you, software is complex so to is something like a smelter or refinery.
Also, your definition of software is really far from reality. 99% of software don’t have to deal with hardware directly and are compatible with a number of environments I can count on one hand.
Computer engineering was probably slower and deeper thought out. Or am I imagining an ideal past ?
Ease of development was an utopian dream.
You are drawing a distinction here between two vastly different project types—not between the roles of people on the projects.
Of course something that has a million times the budget has the potential for significantly higher reliability.
Additionally, the particular requirements of the space shuttle software project make reliability extremely important.
If a computer programmer were to allocate similar priority to reliability in an app for chatting with friends, I'd argue this would make them less qualified for the title of engineer.
My understanding of what characterizes an engineer is that they make effective decisions about technical tradeoffs, and come up with plans that can be realistically executed while optimizing a set of project requirements (technical and non).
In my experience, software engineers are (often) appropriately labeled as such, insofar as the work they do matches that definition (if the definition is inadequate, that's another matter—happy to hear an alternative).
My hypothesis is that people start getting fussy about the 'software engineer' label for two reasons:
1) There's a lot of variety in software work being done. Not everyone writing code is an engineer. Not sure about the situation at large companies, but at least in the startup world, in my experience, everyone I've worked with who had the title deserved it in the sense that they were doing engineering work according to the above definition.
2) The requirements for software projects—especially in terms of the importance of reliability—are very different from those in more traditional engineering domains, which can create a superficial appearance of poor/non-existent engineering. But this is exactly what you'd get if the engineer did an extremely good job, but with project requirements that don't place high value on e.g. reliability.
It would be great if every app could have formally verified code etc.—but the reason they don't has to do with businesses funding these projects, not with the engineers working on them.
You can look at it from the company's point of view: Net profit would go down if they formally validated everything. Put that way, it sounds horribly selfish of the business. But you could also look at it from society's view: Net value to society would go down if everything was formally validated. Why? Because much less software would be created. And, for something like a chat app, we (society) don't actually need the level of reliability that we'd get from formal verification. Don't waste the effort doing it, because it's a net loss. Go spend the time building something else.
The result is that we get chat apps that crash. But we also get much more total stuff. I think that's a net win, even though it's annoying when the chat app crashes.
I'm not convinced this is necessarily a bad thing.
While it's entirely correct for an engineer to use different materials in different circumstances, I don't think I've seen professional engineers in other fields choose methods which they know will fail under expected stresses simply because it's not considered an important project. There's still a safety factor.
> Of course something that has a million times the budget has the potential for significantly higher reliability.
I've seen software projects with funding everywhere between $0 and $outrageous, and the latter never use their extra funding for reliability. It's always for scope. They build software in exactly the same flimsy way -- just a lot more of it. You never see a press release that says "We took $5M in funding so we can finally upgrade from SCRUM to SEI 3, and fix all those dang bugs."
It's not that the project is unimportant so the engineer doesn't care about it, it's that the project's requirements have a certain tolerance for failures. The project dictates that tolerance, not the engineer; the engineer develops and implements a plan that works within the tolerance.
And no, typically there is not a safety factor, which is part of why the tolerance is higher for these projects.
> They build software in exactly the same flimsy way -- just a lot more of it
Again, this is not something determined by the engineers—it's just part of the project requirements the engineers are employed to work from.
I think your gripe is more with something like software product managers than it is with software engineers.
BTW, chat apps are a bad example. Not sure why this thread is using them. WhatsApp has higher uptime than the telephone system itself, if I recall correctly. Making highly scalable and available message switches is a solved software/computer engineering problem.
A better example is most bespoke business software. If it collapses in a messy heap because a microservice ran out of disk space, people shrug and put in alerts to make sure disk space doesn't run low again without an operator being notified. Job done. Not exactly a rigorous approach to failure but it'd make no sense to spend weeks or months on making the entire system fail gracefully in that situation when it's easily avoided.
Also SWEs do a lot more "on-the-fly" modifications than physical engineers, simply because it's so much easier in software.
We are great at software engineering, and our field is the best at engineering generally.
Engineering isn't about how reliable or high quality the system is.
Engineering is about balancing the costs and the benefits.
It can be great engineering to make a running shoe that wears out after 2 races, if it wins marathons.
People who think software engineering is bad, are actually bad engineers, who think engineering is all about quality or reliablity, rather than about optimizing tradeoffs. Software engineering is doing an amazing job at producing products that balance cost and benefit, which is why software is eating the world.
Engineers from traditional disciplines would struggle here, because it's a lot easier to follow super expensive tried and true process, than to situationally make tradeoffs like we do.
The Big Dig cost ~20B over the course of a decade. The Apollo Program clocks in at ~25B The Large Hadron Collider at a svelte 10B.
Software isn't cheap it's just that no one pays attention to the costs.
As a counterpoint, Wikipedia's operating costs are ~40M a year, 1000 times less, and I know which one I'd rather keep!
They created the commons.
It didn't exist before and several companies tried to do what they did. They all failed. MySpace had a huge head start. Didn't matter. Everyone shit on the Instagram acquisition for $1B when it was first reported and years afterwards (in fact Zuck made the decision without even consulting the board and right before a risky IPO where the public was sure to take it as a negative signal). He saw the value and invested in it. Today Instagram is a $100B entity that does more revenue than YouTube.
Credit where credit is due.
That’s not to say there aren’t issues. There obviously are and they’re well documented.
> It can be great engineering to make a running shoe that wears out after 2 races, if it wins marathons.
Sure, but it is bad engineering if it fails halfway through the first marathon and injures your runner. See Iowa. Nobody is complaining about the fact that tradeoffs are made (strawman), what people are complaining about it is that software engineers make tradeoffs unknowingly/don't understand what they are doing.
This is the difference between "we built a bridge that will last two years, because that is all we need" and "To our surprise the bridge already failed after two years, whoops".
I suspect that software is just ridiculously hard. The complexity ceiling for programming is insanely high, and there is very little tolerance for oversights. If I'm designing a drill for instance, I don't have to consider every possible use the drill will be put to. I can just overbuild the crap out of it, and cover 95% of my bases.
Can you think of an analogous man made thing that is as inherently complex and fragile as a major distributed system?
And importantly it never really stops. As soon as a reliable solution to a problem has been discovered we immediately use it to build a billion complex new systems on top of it.
And testing is hard.
And programmers rarely get to truly specialize. We spend a great deal of time learning on the go because it would be nearly impossible to truly be an expert in a field where the tools and goals change so rapidly.
I'm sure I could come up with more if I kept thinking about it.
This is a good point. Earlier drafts of my post did include "the unbelievable depth and complexity of the modern technical stack" as a factor. I deferred it until a future post because I think that we accept that we don't fully understand the systems and stack because of our incentives. Imagine if the stakes were much higher: if our software was hooked up to pacemakers that stopped pumping blood when the software was down. This isn't so crazy: people who design airliners go on the test flights. We would band together as an industry to produce guidelines and recommendations around safe ways to run sites. We'd quit rather than work on a doomed project for a paycheck. Any work would require something equivalent to expert certification and design validation at every layer of the stack. We'd do everything in our power to avoid creating these emergent systems. But the situation is reversed - in many circumstances, the cost of failure couldn't be lower. We tolerate the fact that we don't understand the emergent systems that we create because it doesn't matter enough for us to care.
But I don't want to make it sound like I'm dismissing you're point. You're right and it's super important. I think there's a better angle that I can use to explore this. It might be "Why do so many websites get hacked and lose our personal data?", but I feel like that doesn't fully capture it. I have to think about it. But this seems less relevant to the election case, which is what I wanted to address - that these projects fail because "launch and iterate" has become so ingrained in our process that it's difficult to recognize when it doesn't apply.
It's essentially the main weakness of the open source ecosystems too. The many eyes theory falls apart when the LoC reach many millions. There will never be enough eyes finding bugs or poor practices. Maybe in the future machine learning could help reduce this gap.
If I'm building a plane, I'm going to understand every last little piece going into it.
If I'm building a web app, I'm mostly ok if I do not understand every line of Rails, and the C code in the Ruby interpreter.
There are embedded systems where people have that kind of understanding. And they do fewer things than systems where people happily throw libraries in and whip out new features regularly.
If I built a web app with the same kind of line by line control as that embedded system, it would get outcompeted by someone playing more 'fast and loose'. Maybe mine would have a 99.999% uptime (or maybe not, because AWS or someone might have problems too) and theirs has 99.95, but way more features, so the market will gravitate to them.
Could we make the tools change less rapidly?
I have a larger theory of the tech world right now that there's way too much change, in every corner of the industry. Computers don't have fundamentally different capabilities than they did a decade ago, so outside of security patches, why do so many software projects release major feature updates more-or-less annually?
Make no mistake, most of these updates contain legitimate improvements—it's just that change itself has a high cost, for both developers and users. Most of the time, I don't think the improvements are worth the change.
There are numerous cultural and business reasons for the rapid pace of change in the software world, but I don't think any of them are inherent to how software is created.
From mechanical to electrical engineer, to material fatigue, moulding, durability .. costs
I'm no tool engineer, I'd be curious to see how it really goes at Makita or DeWalt.. how much preemptive failure mode analysis and system thinking is done even for a drill.
-- Outside FAANG type companies, most businesses are not willing to actually put in the investment it takes to do engineer software. They want a "solution" as cheap and fast as they can get it. I'm not even passing judgment here, as in some cases that approach is entirely justified.
-- Software is a world of eternal September, where the industry memory is only about five years long. Lots of us move on to other fields or roles and the memory is forgotten, and here comes another generation to reinvent the wheel all over again.
-- Education: Computer science is not software engineering. Code schools are teaching programming more than software engineering. Thus, software engineering is something learned through doing rather than something studied as a discipline.
1) The FAANGs that I've seen have significantly more robust practices than the non-FAANGs. Everything from office conditions to build / test / release systems. The reason for this is:
2) Incentives. When your business is completely focused around software technology, you are incentivized to build out systems and processes that other places would not, because it is core to your business.
Anecdata from many years in and out of various kinds of companies, as both an employee and/or road-warrior consultant.
What's your error budget? Not spending your error budget is velocity left on the table.
A large part of the perceived competency of the FAANGs is their ability to casually and repeatedly achieve 5+ nines of availability. When HN is unavailable, that's no big deal; when google.com is unavailable, users act as if an apocalypse has begun. That difference in reliability changes a service from something that people consider as an option into something that people rely upon.
Also, I think you're underestimating the effects of having a lot of code. This pushes limits that smaller companies don't have to worry about.
That was the most consistent top caliber colleagues I’ve ever worked with. (I’ve worked with other excellent colleagues, but Desco was uniformly very good. Our office manager had a PhD. Our recruiter had a masters degree. It was crazy.)
Probably the easiest path is to be referred in from a current employee. Next would be outstanding achievement in some academic or technical field (if applicable). You don’t have to be an autodidact or a savant. You need to be competent, intelligent, and willing to work hard and then to find a way to get a warm intro to recruiting.
Most startups that I hear about have rather shitty software quality because they're focused on velocity. VCs don't care about sustainability since they don't even know whether the business is even worth sustaining.
Look at the white papers for the foundational systems at Google and FB, most of them are authored by the same few teams. Jeff Dean had a hand in designing a ton of large scale Google systems, just because he came up with some brilliant solution, does not mean Joe programmer at google who can implement A* in 30 mins is in the same league.
People aren't paying (only) for stable and correct software. They actively seek out fancy UIs for example. I noticed that in a former company. We had the best algorithm and the most correct numbers (for what we were selling) but the customers didn't like them because they were lower (and more realistic) than some competitors' numbers. Also they had better and shinier UI, they won the market.
https://www.howtogeek.com/369631/microsoft-is-killing-skype-...
btw the list is much longer: twitter, facebook, adsense ... visible bugs in all
Wolfram famously gives Rule 30 as an example, where you cannot know what each line of squares will look like before you do the computation, but he goes on to cover many other phenomena, like prime numbers and tag systems.[1]
One conclusion is that complexity stemming from simple rules is relatively common in our Universe and that historically, humans have done a good job of solving the narrow pool of problems where you can know the end solution with a simple calculation (say predicting the location of a ball as you toss it up in the air).
The implication is that there’s a whole “universe” of problems where we cannot know the end solution until we’ve done the work necessary to compute it.
And in that sense, it wouldn’t be surprising if software engineering was a bit like Rule 30: an endless array of patterns we can’t predict until we’ve actually created the code or computed what it can do.
It’s not so much that we’re bad at software engineering. It’s just that emergent complexity is part of our reality (assuming Stephen Wolfram’s insights apply to software engineering. Maybe they don’t. But it sure feels like it).
I think the ancients knew this well. The Tower of Babel story is pretty old. Details the problems humans run into when they try to scale and work with many different elements: Something nobody could predict and possibly, catastrophe.
> As the saying goes, there is much here that is new and true, but what is true is not new, and what is new is not true; and some of it is even old and false, or at least utterly unsupported.
Unfortunately, our industry is dominated by an obsession over "use the latest, cuz is the greatest" mindset, where if you're not using the hottest new language or sexy framework, you're already behind somehow.
I can imagine maybe it was this way when the romans were trying to figure out how to build roads. "Oh hey, did you hear how Steve built his road? Yeah, they compacted gravel an inch out of time underneath the bed. Something about water drainage. Oh and they're waaaaaay more productive. Yeah, productive. Lets do use that framework for building our roads!"
> There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself. https://en.m.wikiquote.org/wiki/Alan_Turing
I believe one of the examples for extreme reliability used in the XKCD cartoon included in the article is air travel, which is about as old as computers.
I was told once that the reason air travel is so reliable is because they have mechanical backup systems for when the electronics inevitably fail. Is that true?
How reliable are electronics as a whole?
Given sufficient time, budget and management will very reliable system can be made. The probes have software too, so there’s that...
What a lot of people fail to do when making comparisons with software is to look at the act of coding in isolation from everything that surrounds it. That leads to a very skewed perspective.
Airplanes reuse and refine, reuse and refine the same system, more so with elevators. Software is often greenfield.
Realistically, software projects get budgeted for half/third of the time they actually need to be anywhere near complete. Then following the "delays" that should have originally been budgeted in, you might be over or under that more realistic estimation, but the software is worse for it. Why? Because the engineers were stressed/crunched/whatever into performing worse under the false pretense that "we're almost there," when that is not the case.
If companies put a greater emphasis on correctness and budgeted time/money/testers/etc for it, things would be better. This low grade output is what the industry wants and that is what it is getting. People in charge of scheduling may say they care about correctness, they never really do, they care about fast and the appearance of some facsimile of function ("it looks like it works").
Imagine if you went to your higher up and said that the 6 month greenfield voting app, would actually take 1.5 years and require more resources just to ensure correctness. You would just get taken off the project. "It's just a voting app, one screen and server." But that misses the point, because it's a voting app, it needs to be hardened, just like an airplane.
So you learn to shut up and either produce worse output, or work overtime to make something halfway decent. Either way it basically goes unnoticed until something blows up.
Every group I've worked with seems to start in a defensive state projecting confidence but I casually admit to my struggles with everyone on the team and folks start to open up. By the end, you have a team of developers who can help set more realistic expectations. The less developers communicate amongst themselves honestly, the more they can be exploited by unrealistic expectations for development.
It's a much nicer environment when everyone knows and admits they're slinging garbage code because of resource constraints than everyone pretending they're not.
Software engineer? We assume lots of software. But, this would be akin to assuming all of the other engineers were simply "mechanical engineers." To an extent, true. And there will undoubtedly be polymaths good at many.
However, if you want someone to ship a Todo App on time, get someone that has done one before. A financial app? Same. ML Pipeline? Same.
Instead, we get someone that succeeded at getting an app in some field out, and assume they know how to get the same in another field. And are then shocked when they are unable to estimate something they have never done before. Or why they spend their time shaving yaks that they know, without typically providing new value to their users.
You want someone to do good at delivering what you are building? Make sure this is not their first time building it.
2. The tools that help make software really, really good are really, really baroque and remain that way because the people who invent them are subtly incentivized to be the high-priest of an esoteric technology church rather than making them for the masses. Which ensures that making really, really good software doesn't get cheaper with time and also ensures that you'll only reach for these tools if _you absolutely have to_ because of #1.
3. Software Programmers/Engineers see their jobs, and appear to derive most of their joy, from doing the actual coding. Not in using rigorous design tools ahead of time which are unmoored from their implementation, nor in doing the testing & verification of the implementation after the fact.
3a. Software Designers/Architects have made a bad name for themselves by spending more time pontificating at whiteboards than writing down verifiable specs & models.
3b. Software Testers/QA folks are treated as lower-class than Programmers/Engineers, and don't get paid nearly well enough, so they're setup to follow rote scripts and procedures rather than empowered to deploy sophisticated testing methods like property-based testing or mutation testing.
4. All those factors appear to have created a feedback loop which has become self-reinforcing.
Perhaps software is somewhat unique that we don't appreciate experience.
Upfront I'll say I know the people at Shadow and worked right next to them at HFA. They're super competent (they worked on some of the more critical things) and some of the best people I know. Just so you know where I'm coming from. I haven't talked to them about any of this.
Political software is very wild west. There are dynamics that are just impossible to anticipate, like every Saturday this vendor's response time drops to nothing because they do weekly backups, or we're coordinating all the votes through this person but they've never used a smartphone before. There are some fundamental truths here:
- these systems and processes are underfunded, ad-hoc, and run by people who are compromised in significant ways (haven't slept more than 3 hours in 2 weeks, no experience with technology, responsible for literally 30 things, downright incompetent but bodies were needed, drug/drinking problems).
- we're now in an age where these systems have to be secure against state-level actors, and we are woefully unprepared for that in every way you can think of.
- very little in our political system can hold up to scrutiny. Caucuses in particular are and always have been junk, but even elections are... maybe impossible to verify. And even if we could perfectly record every vote, externalities (weather, voter suppression, malfunctions) and people's bad memories ensure there will always be a gap between the will of the people and the results of an election. They (and everything else about this process) are fundamentally imperfect.
At HFA we dealt with this by planning for it from the beginning, and when you're the presidential campaign you can do a lot to combat these fundamentals (run drills, hire super competent people for pennies who will work for you out of patriotism, run red teams, strongarm and replace vendors, etc). We still made mistakes that haunt me. It's just how it goes.
Nowhere else in politics is like that. So you do your best: don't put your app on the app store, subject to anyone downloading it and review by Apple/Google, use MFA even though it will undoubtedly confound 80% of your volunteers. Hope the internet holds up in rural areas or gyms with satellite trucks and crowded APs/towers. Hope no one learns the numbers of your backup hotline. Hope people know the rules of the caucus and count perfectly so the results aren't tainted and called into question ad nauseum on national news media. Hope no one thinks you're part of a conspiracy to cheat their favorite candidate and doxxes you. Make your app as simple as possible. Accept your client's insistence on secrecy in the name of security even though you know training and testing are essential. Hope there's no quirk in the vendor's API that will reject results on caucus night.
This whole thing is like a Rorschach test. Are you a person who thinks tech has no place in elections? That's what you see here. Are you a Sanders supporter who thinks there's a conspiracy (not for no reason) against him? Do you think Democrats are fundamentally incompetent? Do you lament the state of software robustness? Etc etc. I would implore people who are falling into into this stuff to recognize these mental reflexes. Very few people know anything about how any of this works (I certainly didn't) or the details of what happened in Iowa, and if you don't, well probably shouldn't extrapolate from this situation then.
If the argument is that those items weren't considered, that is definitionally bad engineering and I think GP is dead-on in their assessment of Shadow's development.
If the argument is that there were unknown unknowns that caused the app to malfunction and the items you listed were just examples, and we don't actually know what went wrong - well, I'll be happy to read the post-mortem.
But that's not what happened here. This wasn't an "unreliable vendor on Sunday" situation, or a "we couldn't budget for offline local storage for rural internet". This was a "our app literally doesn't even let users log in" scenario, and I find that really difficult to excuse under the blanket of "political software is hard."
Basically everything else you wrote is outrage at the state of software robustness, so I'll refer you back to my last paragraph.
This has been going on as long as I've been active with computers. I think a part of the driving force behind this was the speed with which computers became faster. There simply wasn't time enough to absorb the lessons before the 'old' stuff looked small and obsolete in view of our new powers.
But if you look at old and mature software systems (Common LISP, Erlang, D and others of that vintage) you'll find that the degree of thought that went into them and making them bullet-proof is still very much absent of that which drives a large portion of the software industry today. We're probably destined to go through this sort of cycle at least a couple of more times, if not forever.
The overall post was okay, but the lead-in was too topical to be relevant more than a few months from now, and also wasn't really about software quality at all. What happened in Iowa was a lot of bureaucratic cock-up -- they got the wrong people (because favors or political or personal connections) to do entirely the wrong thing, and didn't bother to consult any of the people who could have helped them make better decisions. It's not substantially different from someone buying the shittiest available used car from a private party and the wheels falling off on the highway, and then trying to use that as an indictment of automotive build quality.
But.
Clearly software suffers from far more issues than other technical disciplines, and that is 100% because there are no common standards and, thus, no certification process or professional licensing.
When software developers and managers compare big software projects to big civil engineering projects, they keep missing the obvious educational and certification process required to become a civil engineer. Galloping Gerties and John Hancock Towers still happen occasionally, but then they become case studies for every prospective new engineer. Contrast this to software, where we all slang out code until we're bored and then self-educate by reading other people's war stories online.
The average man or woman that can build a porch for your house is subject to more licensing requirements than the developer that builds voting software. Let that sink in for a minute.
Programmers are quick to screech at the thought of being subjected to any kind of licensing or certification process, and yet we all have the horror stories of being forced to build and deploy utter garbage by upper management. Professional licensing would really help us here. We'd have a defense that would go, "I can't do that, it would make my license get reviewed."
I don't think this will ever happen though. The majority of programmers don't want it and nobody knows how to do it. They'd rather write and share navel-gazing articles from time to time, wondering about what could possibly be so very different in software from every other engineering discipline. 'Tis a mystery.
What could work would be licensing for software engineers in certain specific domains. For example, we could require election systems software engineers to be certified for that field. Same with automotive software, power plant software, etc. etc. I agree that we should do this. But it's going to apply to only a small fraction of all software engineers, because licensing Web app developers is not practical.
And the average company that can build a porch for your house has stronger insurance and bonding requirements than the average company that builds voting software - or any software, for that matter.
We've also produced "move fast and break stuff" software organizations, who have realized moving fast and failing is a better financial outcome than safely arriving at a suboptimal destination (Facebook, Twitter, tons of startups). Let's call them Type 2 teams.
Neither Type 1 nor Type 2 teams are Bad or Evil. They are simply suited to different applications. What happened here is, an organization that was unable to distinguish between these types of teams hired a Type 2 team for a Type 1 job.
Generalized example, usual caveats apply.
The Voting software cost $60K I believe, that includes distribution.
That about sums it up for me, if you want reliable software it costs a lot of money.
The reason for a lack of planning, is because tremendous planning increases time to ship, which effectively costs money.
I've read with the space shuttle every line of code was reviewed in a meeting - its described here https://history.nasa.gov/computers/Ch4-5.html
That's just blatantly false. Agile is about adjusting to the changing environment.
Even wiki says: "Agile software development comprises various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s)."
You can take a positive spin on "We'll just figure it out iteratively as we go", but I think ultimately you get orders of magnitude less actual "planning" by kicking the can down the road. YMMV though, as with everything.
And going by recent events (i.e. 737 MCAS) it would appear Boeing is not that great at creating reliable software.
Thing we struggle more with is "Must work correctly on first REAL use". So we now have the PITA world of other engineering disciplines where adapting is often not an option once "deployed", though even there those disciplines look for ways to get "soft".
Having spent a lot of my career doing Embedded Systems/Industrial Control Systems the approach to getting things correct is very different from developing web/backend/mobile software. Lots of rules are introduced, design approaches are limited to certain ways of doing things and many techniques are avoided. Functionality is carefully considered on how difficult it is to build correctly. Testing is more convoluted. Robustness and Performance are far more pressing concerns. But again, in this environment it is often desired to be more "soft" and various things are done to try and achieve that. It can be handled much like other engineering and often is managed as part of a multi disciplinary effort of mechanical/electronic/software engineering and treated as a "system"
Getting some mobile app developers to make something that is supposed to be "robust" on first deployment is mainly a problem in not recognizing what skills and experience are needed to be employed to get what you want.
I have never seen perfect software, have you? They always end up with bugs that make you vulnerable...
if you don't change the inputs or any other variables, it is different from a program deployed in the wild... but yeah not very many things are perfect (even the sun will die one day).
Conclusion: More software engineering research should concern itself with:
- emergence phenomena
- how engineering trade offs are made
- the assumptions underlying research works
- creating certain taxonomies.
Such work would also allow software engineering to become more evidence-based.
Software is young, things move very fast, and new practices can emerge quickly (and older get canned).
Imagine if aerospace company was to design, test, and build a new airplane in only 6 months. It would probably end up as a disaster. In the realm of software, it is very likely that you need to come up with something new, very fast - you don't always get the luxury to step back and lay the proper groundwork - you're doing it on the go.
Oh and you can make a name (and pile of money) for yourself if you manage to promote some mediocre beta-quality-at-best tool and trick enough other people into using it, and if people call you out on it they're the assholes.
Every thought experiment that immediately comes to mind, in which other professions of various sorts had to deal with some similar situation on an ongoing and apparently never-ending basis, read as absurdist comedy. Yet here we are.
[EDIT] ok here's a fun one: imagine if framers had to use a different hammer depending on the brand of wood at the job site. Like, hammer weight is different and you even hold it differently. For some you can use air nailers, others you can't, some of them only work with air nailers that have a second person working the trigger while one holds them, all the different air nailers need different compressors, some of those take different voltage, shit like that. Imagine it's like that for all their tools and that these differences manifest in all sorts of ways based on the combinations of materials & tools.
We wouldn't say "gee why are house-builders so bad at building houses, and LOL they can never even tell us about how long it'll take", we'd say "holy shit how do any houses get built, it's practically a miracle, we should fix it so it's not so hard—for no good reason—to build houses"
“[Kelly Johnson] sought and received permission to set up his own experimental department, which he based in a hangar next to Lockheed's wind tunnel. With his team working 10-hour days, six days a week, the prototype was ready just 143 days later. That plane was the P-80 Shooting Star. It arrived too late to have an impact in WWII, but (renamed the F-80) it went on to serve in Korea”
Building an aircraft has many layers of bureaucracy behind it, and the cost that goes with it. In the end, software is practiced as a craft more than an engineering discipline. And that's okay. It's usually when politics and management decisions override the needs of the software/product that things tend to go sideways.
There are also more than a handful of software developers that don't really care about the quality or maintainability of the software. Let alone learning and using the methods for interfacing with said software.
Just the past couple days, I was looking for a React + Material UI template to work from. Many looked great, but actually following the code was a byzantine mess. Mirrored trees of files are my biggest pet peeve in front end projects. Let alone not even using the methods available for use and extension. That's just a recent example.
I've seen others, where a given set of methods is copy/pasted across dozens of case statements... Worse still is when you see a schema design that makes no sense and/or variables that are lost and meaningless, that everything around it loses all context. Such as the passwords having the variable w23 and the value is stored in the "Phone2" table under "extra1" columns.
Managers give lip service to "quality" and "testing" but when push comes to shove you skip testing to ship on time, and have to deal with bugs several years into an initial 9-month project timeline.
No real client-side code; lean on the HTML platform for everything it can be used for. HTML is the simplest, most stable, and most battle-tested client-side framework ever created, and it's stateless and runs on all devices without even an installation step. Toss some CSS on there to make it look pretty; CSS is stateless too so it won't introduce any real bugs. It doesn't have to look perfect; you're not marketing it to anyone. You're just collecting input from users who don't have a choice of product.
For the back-end use something dead-simple like PHP or NodeJS. The business logic can't be that complicated; I assume it's really a very simple CRUD app. Just accept form submissions, authenticate, validate, drop it in the database. Done.
Spin up a couple of hand-managed VMs on DigitalOcean or the like for hosting both the databases (probably just one database?) and the web servers. It's not a small user load, but it's much smaller than the typical internet company, and it only needs to run for a few hours. You don't need automated scaling and restarting while you sleep. Sit a task force at their desks during the event to repair any outages as they happen.
Use the right tool for the job. Your stack should be exactly as complicated as the task demands, and no more.
The biggest predictor of bugs is "Organizational Structure", the main problems sound like they're not in the computer(s)
Yes, a lot of the progress we've made is just an illusion driven by Moore's law and lots of bloatware that it enabled, but a lot of it is genuine and needs to be taken into account.
There is a bubble. Companies with half a product, no distinguishing technology, and no path to profitability are getting valuations of billions.
Therefore the big guys - the FANGS - become worth trillions, and can afford to hire the best of the best and pay them millions (over the last 5 years, with stock, yeah, that's what sr engineers make in Seattle/Silicon valley)
So, you've got the best software engineers in the world making adtech.
Which means the only ones the Iowa Democrats can find for a 60k budget aren't inept, but they're certainly not in the top tier. See also: The Obamacare online rollout.
What will fix it?
A market correction. One, as a well paid sr engineer, I am not looking forward to. But it will make a bunch of actually competent software devs available for smaller market projects, and suddenly the quality of government software will increase dramatically as lower-paid-but-outstanding-benefits government jobs seem way more cushier all of a sudden.
For safety critical applications, technical decision makers need to have reason to say "no, we can't do this, and we won't because my career and possibly freedom are at stake if we do."
Right now a huge portion of the risk of software failure to software builders is reputational. This can be sufficient, as pointed out in many cases in the article, but as we see in these examples is often not.
My grandma was 20 when a guy named Claude Shannon in 1949 invented/popularized the concept of a "bit" and described what information is, the way Newton described matter and how to model physics with mathematics.
Really, "information" was a just vague concept until Shannon and this was just 70 years ago!!1
It's only natural that a lack of generations of craftsmanship in this industry makes it pretty low quality/hard to master. On the other hand, imagination is the limiting reagent, since (arguably) the bottleneck is good ideas, specially with all these decades of Moore's law.
Computer science programs don't teach students how to build good software, they teach computer science. CS professors wouldn't even be qualified to teach good software engineering practices if they had to.
Code is also difficult. It's one thing writing your own code and understanding it, but understanding someone else's code is very difficult since you have no idea what was going on in their head when they wrote it. Of course there are practices you can follow to make things simpler, but it's never going to be as easy as say reading plain English.
Oh, I don't know. I have a bachelor of Software Engineering that is accredited by the Australian Institute of Engineers.
The vast majority of my degree was on the discipline of SE, so rigorous testing standards, theory of large scale system design, hard real time systems, Improving your personal software process.
For our final year project 16 of us worked for a very large company to design and build them a piece of software. It was awesome.
Hell, even here on HN not having had any formal education of any kind is seen as some sort of badge of honor.
Good article. We're not really that bad at it, we just optimize differently than building airplanes or elevators, for most things. No one cares if the site I built for the local bookseller goes down at 3 am for an hour or two. Or even for a few minutes during business hours.
Just look at the world software engineers play in. In a world of 7 billion people, nearly all of us use one of a tiny number of compilers on computers running one of just three or four kernels, atop one of two processor instruction sets.
Yet look at the plethora of programming languages. The fundamental building blocks of our industry are apparently so terrible that many of our brethren devote years trying to replace them.
That's hardly the end of the debate, and I'm still undecided, but it seemed worth lobbing in before hitting the rack.
(Dijkstra on software engineering)
Some well known examples are:
- major programming languages such as C don't do enough to help with memory safety issues
- lack of explicit types in python function arguments can lead to surprising bugs which recur again and again
- operating systems and platforms, such as different web browsers, adhere to widely different conventions about how dependencies on other libraries and code is managed
And running a train over a floating bridge has serious problems, but it is done. These software "problems" are trivial compared to algorithmic complexity when analyzing 10billion events a day in countless ways realtime.
"Why are we so bad at apps and websites software engineering?" might be a more appropriated title.
My hard drives never stopped spinning. I am sure there is some amount of software engineering on them. Last night I finally finished The Witcher 3. It never hanged up and was a joy to see and play.
Please, when referring to software engineering, stop assuming is just shitty phone apps and rushed webapps. That's just a small tiny fraction.
1. https://www.stilldrinking.org/programming-sucks 2. https://mickens.seas.harvard.edu/wisdom-james-mickens (I love The Slow Winter, but To Wash it All Away is probably more relevant here)
1) People typically die when things go wrong and are heavily regulated. Most software that works in this space are tested in accordance to those industry standards. Your desktop browser doesn't need to be engineered to those standards.
2) Other engineering disciplines have in certain cases had 100s if not 1000s of years progress. We've had less than 60 years.
I don't see how software doesn't put human lives at stake. Honestly, the number of lives at stake is increasing with each new self-driving car hitting the road.
Everyone claiming tooling or funding or this or that is missing the forest for the detail of trees in the client spec.
The alternative to nearly all software solutions is "bunch of people do that thing" or "hire costly expert." Software is usually a combination of transitory, relatively quick to implement, mostly opaque, and very inexpensive in up-front costs in comparison to the alternative, which both reduces the perceived risks as well as makes it unusually attractive as a means to achieve some goal. That combination also lowers the bar for what qualifies as "a goal," providing a much larger universe of possible actions available for those who are establishing the goals.
With the lowered bar of what constitutes a goal, given that the overall costs are perceived to be so very low, the decision maker feels unburdened enough to choose goals without vetting the decision and its consequences against the standards that would be applied to "hire a bunch of people to do that." You've taken what used to be a decision that carried with it all the forethought and examination that one would usually apply to purchasing an automobile or home and replaced it with a decision that has no more consequential cost than to decide whether one wants fries or carrot sticks with a sandwich.
As with the choice of fries, it's not the single instance of such a choice that lays you out on a cardiac surgeon's table but instead the repeated accumulation of what seemed to be inconsequential decisions to get fries. If you asked someone if eating fries with every meal could set someone up for a heart attack they'd most likely say "of course, that's obvious." But our patient did not encounter the situation in which they had to make the decision as to what side they will have with every forthcoming meal, and all the forethought answering such a question would entail. They only made one little decision whose importance was as fleeting as a single meal. Until it wasn't.
This effect on decision-making, with regards to software, almost always spreads to the entire organization (and often beyond, to infect customers and the general public as well). The CEO, the VPs, the Directors, the Managers, not to mention the programmers themselves, all make decisions and set goals that meet the lowered standard (or at least a standard lower than what should or used to be the standard).
When you lower the standards for decisions and goals, you get results commensurate with those standards.
2) There's not enough specialisation (most software shops will tackle any project and IT people tend to specialise in technologies, not business areas).
"I am not putting my breakfast behind a locked door, he will say. I always carry it with my backpack and my backpack is always on my back."
How many generations of people have passed since computers are around?
Not enough that we can pragmatically reflect upon it.
See, we can say we collectively have some understanding of what the invention of the printing press, and its consequences on societies, cultures, and history. As well as, before it, writing.
I think we still can't say much the same about computers. We barely see (and not everyone yet) how much it impacted and enabled to impact our societies, public & private discourse, political endeavours and regimes.
Voting apps are basically political money laundering schemes. Using them to make comments about software vs other industries suggests either stupidity, laziness, or malice.
And that's more because of the practicalities involved in that particular idea rather than something about software enginering as a whole. What's necessary for a secure and trustworthy voting system puts it at odds with any attempt to provide such via a machine/app/program/website.
Ask the same people about say, reliable hashing/encryption libraries or what not, and their attitudes would probably mirror those of the aircraft designer or building engineer.
There are probably also examples of things in aircraft design or construction that would have people in those fields freak out too.
They optimize for a compromise between short-term gain and long-term gain. In essence, a startup can mathematically proof its software and go bankrupt before they even reach a prototype stage. Or they can shell out utter crap quickly, get some early feedback, funding and beta testers and slowly figure out what to improve first for the biggest bang.
Same goes for giants, like Google. They technically have the resources to prove SOME projects and they DO. For instance, Amazon proves their hardware virtualization software and other core pieces, where bugs would undermine the safety of the entire cloud.
I am getting a bit sick of "Why is software engineering so bad compared to XYZ". All the people asking are either not in this field or are junior engineers who just don't yet understand why things are the way they are and why writing bug-free, mathematically proven software is infeasible, unnecessary, impractical, undesired, etc.
Consider another analogy. When building a house, how expensive is it to decide that you actually want to have a ceiling with 5 meters high in the second floor, because the buyer of that floor wants higher ceilings? Simple: Tear down the building and start over...
In software? Usually it comes down to adding an IF-statement or some such. Software follows completely different economic principles and serves completely different needs.
There is at least one dimension though where this problem currently shines through: Self-Driving Cars.
I think auto-pilots in self-driving cars SHOULD follow the same rigor as airplane auto-pilots and they are most certainly not doing that, which will and already has resulted in lost lives.
Hey! Author here. This is the exact point that I make in my essay. I don't compare it to any other fields, and certainly don't mention airplanes or elevators. I explain how this compromise is deliberately reached for people who aren't familiar with the dynamics of software projects. I recommend that you read the post! It sounds like we agree on a lot.
The idea of simplicity and unity is an important guiding ideology of scientific research. It can be found from the knowledge of various disciplines:
the more universally applicable a unified theory, the simpler it is, and the more basic it is, the greater it is.
[The Pure Function Pipeline Data Flow v3.0 with Warehouse/Workshop Model] systematically simulates integrated circuit systems and large industrial production lines. It perfectly achieves simplicity and unity. It must be the ultimate programming methodology.
In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from `Lisp language-level code and data unification` to `system engineering-level software and hardware unification`.
It brings large industrial production theory and methods to software engineering. It incorporates IT industry into modern standardized large industrial production systems, This is an epoch-making innovative theory and method.
1. The replaceability, insertability, observability, and readability of the pipeline are very strong.
2. The observability, standard, fairness of the dataflow are very strong. Data standards (data interfaces, data specifications) are better than code interfaces. and non-IT practitioners can understand.
3. The warehouse/workshop model is widely adaptable, simple, and reliable, and the workshops are isolated from each other.
There are only five basic components:
1. Pipeline (pure function)
2. Branch
3. Reflow (feedback, whirlpool, recursion)
4. Shunt (concurrent, parallel)
5. Confluence.