13 ms·

Why writing software is not like engineering (2008)

59 points by headalgorithm 5y ago

dang 5y ago
One past thread: Why writing software is not like engineering - https://news.ycombinator.com/item?id=1207721 https://news.ycombinator.com/item?id=1207721 - March 2010 (72 comments)
BadInformatics 5y ago
For a more nuanced and far more detailed counterpoint, see https://www.hillelwayne.com/tags/crossover-project/ https://www.hillelwayne.com/tags/crossover-project/ (discussed in https://news.ycombinator.com/item?id=25823907 https://news.ycombinator.com/item?id=25823907).
ineedasername 5y ago
Part of the problem is that software project decision makers view software projects as far more mutable than physical engineering projects. In a billion dollar construction project, everyone understands that if you want to change the design or significantly expand the scope halfway through, you're going to have a heck of a lot of increased costs & time. In software, it's very common to add scope or major design changes at any stage without understanding that the same cost and time increases will apply. For example saying 90% through the project: -Software: "we need a 2-way interface added between the complex software we're building and some other complex software" -Building: "We need an enclosed concourse built between our new building and the next building over across the street." It is obvious in the later case that there will be a lot of extra time & cost. While in the former, higher level decision makers on a software project don't understand the comparable difficulties.
- RNCTX 5y ago
  They do understand, they just want to not-pay. If construction companies figured out they could outsource labor to countries with far lower currency values and thereby not-pay for extra labor, they'd do the same.... oh wait...
  - ineedasername 5y ago
    They do understand Not in my experience, which may not generalize. Your experience and my experience together won't really give a complete picture. What I experience is this: Even on small projects I've had people say, "okay, can you just add this one thing in the next day or two?" And they don't understand until I walk them through in detail how that one thing is nearly as complex as the initial project, so they have to choose how important it is, and if it's important do they want to wait to release the whole thing or do a release in stages. Of course my experience is not necessarily going to represent the whole. Also when outside consulting groups are involved, I often see predatory behavior: they often agree to do any change asked for and don't bother to explain the costs and time involved until a deadline is missed and the budget is running out. At which point they say "the changes you requested have pushed us over the deadline and the extra time is going to cost $X".
deregulateMed 5y ago
I switched from engineering to programming because of pay, but I can tell you the word Software Engineering is not exactly real unless you are doing some safety critical C or assembly. Whenever you have abstraction, you have lost what it means to be an engineer. There is really only 1 way to engineer something as you end up optimizing for various quality metrics, most often cost. There's only 1 correct answer for a bracket. You want it cheap and as strong as it needs to be. How many correct answers in my code? Do we optimize for clean code? Fast code? Do we change programming languages or go with a familiar highly supported code? There are 2 similar libraries, which do we choose? Programming is a hybrid of science, art, tradition, and authority. I think it pays better because of this complexity. That being said, I'd trust an engineer to program something before I'd trust a programmer to build something.
- abainbridge 5y ago
  > Whenever you have abstraction, you have lost what it means to be an engineer. That's an interesting observation. I'd say engineering does have abstractions, but they're much better. For example, treating an RSJ as a simple uniform piece of material is an abstraction. In reality it is a crazily complex mesh of crystals. But the abstraction is simple and well studied, so it can be used reliably. Programming abstractions are less reliable. Even commonly used ones like "the filesystem" and "the heap" are vastly more complex. It is almost impossible to remember all the possible hazards when you use them.
cryptica 5y ago
IMO, software engineering won't exist for another 50 to 200 years because: - It takes several years for someone to prove themselves as a developer among their peers and this reputation does not usually spread outside the confines of a single company. People have to prove themselves all over again each time they change company. - Big, high-exposure, high-influence software companies like Facebook, Google etc... force arbitrary tests on prospective developers (candidates); but these tests say nothing about a person's skill as a software developer. These tests are reliable at selecting for status-oriented individuals who can regurgitate solutions to common programming puzzles and present themselves as fast-talking and quick-thinking (I.e. Ben Shapiro archetype). These companies have a huge impact on global software development tools and philosophies; their recruitment decisions have a huge impact on deciding industry best-practices. The huge influx of superficial, fast-thinking, fast-talking software developers within the centers of power is making the software industry look like the medical industry 200 years ago when all reputable doctors insisted that blood-letting, electroshock therapy and lobotomies were reasonable treatments for most ailments. Their arguments relied on superficial, smart-sounding observations and appealed to the authority of large medical institutions. Modern developers like to leverage their associations with financially successful corporations 'sources of authority' to project themselves as top experts and to promote their agendas. - Too many people who have no sense of curiosity at all joined this industry purely for financial reasons over the past couple of decades; these status-oriented people will end up running all the big tech companies and enforcing their ill-conceived philosophies onto others, silencing inquisitive minds. It's a numbers game; the voices of the many high-status, fast-talking, loud-mouthed idiots will drown out those of the few quiet, low-status geniuses. We are entering the dark ages of software development.
airbreather 5y ago
It is not just standards, you will find many engineering contracts these days refer to RAGAGEP - Recommended and Generally Accepted Good Engineering Practice. My take on this is to allow for rapidly evolving practices in an industry where key standards may not be updated to over a decade in some cases, or even cease to exist at all due to emerging fields. What this means is that a responsible engineer has to make a defendable decision, using experience and judgement to justify a particular course of action. As my engineering manager used to say to me, "Would you feel comfortable saying those words again, just adding on Your Honour'at the end?"
killingtime74 5y ago
Great points. Humans love to categorise don’t we, even if it doesn't change anything
nomy99 5y ago
Not sure why people consider it an art.. some software problems only have 1 correct solution that runs in a time constraint, proven by mathematical induction..Art is subjective no?
- von_lohengramm 5y ago
  Most programming isn't implementing the specific most efficient algorithm. Usually it's mostly architecting, bricklaying, and tweaking.
- alfonsodev 5y ago
  Is like telling a story that is only correct if you get all the facts said, but there are so many styles to tell the same story, and people can’t agree in what’s best, there is always someone coming up and saying ... actually I can tell the story better to make it more enjoyable and easier to understand.
- Closi 5y ago
  Not all programming is art, just as not all painting is art. And some math formulas are considered beautiful, and art is in the eye of the beholder, so even the optimal solutions might be art to some.
- mannykannot 5y ago
  Subjectivity is mostly an aspect of fine art (and some coarser ones, depending on your definition of 'fine'.) Originally, art was a more general concept, making something artificial by using skills that don't just come naturally.
- ankurdhama 5y ago
  They have to put some label on it, if it doesn't fit engineering or science then art it is.
moksly 5y ago
Most engineering projects have standards. Not the cutting edge stuff, but most of it does. Many are from regulations and safety laws setting specifications for this and that, but some are simply there because they won by being the most popular. Software Development by contrast has no standards. You can hire two different enterprise sized companies with this and that certification in the exact same technologies, who claim to adhere to the exact same principles for best practices and what not. They mean it too, often they’ve even gone through the same sort or internal re-education processes with the same consultant companies at the same time, yet they still manage to build software projects so different that transferring ownership from one to the other, or setting up a multiple supplier open source project, is sooooo much work you wouldn’t believe it. If computer science wants to be engineering, I need to be capable of hiring an architect who makes plans that can be implemented by any supplier, and I need to be able to switch supplier/contractor 2-3 times during the process without issues because the plans can only be implemented one way. We’re probably a lot further away from that world today than we were 30 years ago. The only company that seems to have smelled the music on this stuff is Microsoft and their cloud.
- whateveracct 5y ago
  It shouldn't want to be engineering in most cases. What a waste if so.
- historyloop 5y ago
  Standards can only happen when an industry has matured and moves slow enough for these standards not to be obsolete by next year. We have plenty of laws and standards regarding handling private information, payment systems, independent pen testing and so on. So it's incorrect to say we have "no standards" at all. Where it matters, we do. But to try and standardize a process that's evolving faster than a standard can spread is pointless. This doesn't make software engineering any less engineering. Engineering isn't about standards. It's about the design, construction and use of systems.
  - moksly 5y ago
    It happens with slow technologies that ought to have standards as well. I do work with OS2.eu (Danish public sector owned open source software organisation) and we recently brought the first project into multiple supplier territory. It’s a Drupal PHP project, and as I understand that means that everything that gets build should follow Drupal standards that are pretty much set in stone. After 6 months of governance going this and that way, and the countries second largest city (and biggest PHP developer) as a mediator, we are only now moving into the blissful world of compliance where everyone has agreed to develop Drupal modules in the same way. Compare this to when we build a new city hall. A massive project involving almost 500 smaller local contractors, in a business that actually moves forward pretty fast. Some of the materials they ended up using weren’t even invented when they began. The project was finished a head of schedule and under budget. I know construction isn’t always like this. We’ve had our share of catastrophic projects, one elder-care center in particular, but compared to buying software it’s almost child’s play, even when things go wrong. So I think it’s perfectly fair to say that software engineering isn’t engineering. If you can even build a simple webpage, without two suppliers disagreeing so much on the “standards” that it takes 6 months of governance to achieve compliance, then there is just so far for the industry to go before it’s anything that even resembles engineering.
wombatmobile 5y ago
> The Economist magazine (Nov 27, 2004 p. 71) cites the Standish Group's estimates that "...30% of all software projects are canceled, nearly half come in over budget, 60% are considered failures by the organizations that initiated them, and 9 out of 10 come in late." In 2021 (as well as in 2004) it is meaningless to talk about "all software projects" without specifying domain, size, scope and project etymology. "Software" is too vast. It could be an app to tell the time with Mickey Mouses hands, or it could be the control software for a joint strike fighter.
- robertlagrant 5y ago
  > nearly half come in over budget That's much better than I would've thought.
historyloop 5y ago
The gist of the article is that software projects have more ad-hoc decisions and more flexibility. This is due to the nature of software. To claim this as a justification that software engineering is not engineering seems rather shallow to me. You have less repetitive process in software because once software is built, copying it and reusing it as-is is free. In construction if you need to build 10 twin buildings, each of them is a project on its own. In software that'd be building one piece of software and deploying it 10 times. Furthermore I question the notion that software projects can accommodate more "fundamental midcourse design changes". Can you spend 2 years writing a dedicated Windows desktop application and then midway suddenly switch it to being an Android application? That would be fundamental. Reskinning the UI or replacing a dependency with a similar one is not fundamental design change. Software can't sustain fundamental design changes, unless we misinterpret what is fundamental and what isn't. Basically we need to be careful with our analogies so we don't cross from trying to extract insight into flexing our useless cynicism about how software sucks because it's not like making a car in a superficial ways.
ChrisMarshallNY 5y ago
I consider software development an engineering discipline. In my weird, crazy world, engineering is all about discipline (sound of a riding crop slapping a leather-clad thigh), and follow-through. It's a lot less about slide rules and differential equations. I believe that the Romans that built aqueducts (often using coerced labor -otherwise known as "slaves") were engineers. They had a lousy numbering system, no concept of trig (although a few had heard of Pythagorus), and not even a slide rule; yet they were able to build massive, well-designed structures that still stand, to this day, nearly three millenia later. I can't use some Web sites that are just over a year old, because their components went belly-up. But I also consider software development to be a craft. That's really my approach. When I write software, I make a personal level of investment into the outcome. The project must complete. Even when I'm working with a test harness, on a project that is nothing more than an experimental platform, I treat it as if it were a shipping product, that I plan to display in the store window. In fact, I often revisit truncated experimental efforts, in order to scrounge snippets. Since they are already "ship" quality, those snippets tend to be quite useful. A basic habit of mine, is that all of my code "ships," even when it doesn't. That's a craftsman attitude. Getting the project to "ship" state is an engineering effort. But that's just me. YMMV.
- deregulateMed 5y ago
  You can't be both a craft and engineering. I think the issue is misunderstanding what it means for something to be engineered. There is a correct answer. (Especially because you can always optimize for cost or a different quality metric)
  - ChrisMarshallNY 5y ago
    I see things differently. I believe that they can both coexist. I think that the prior art is centuries old.
  - jbluepolarbear 5y ago
    You are so wrong. Software is both a craft and engineering. All software fits your definition of cost and quality optimization. It is a craft in that a software engineer isn’t taught how to write the software you want, they’ve built a toolbox from crafting different types of solutions because their existing tools didn’t fit.
fortyrod 5y ago
This seems to broadly conflate CS and Software Engineering. The differences have been covered elsewhere. Stuff like cognitive vs. physical science, (mostly) thinking about thinking instead of thinking about things, or quotes like "A computer is to computer science as a telescope is too astronomy." To be fair, the fact that a lot of us got CS degrees, but really ended up doing software development probably doesn't help clarify matters. The university I went to had a separate degree for Software Engineering and, frankly, it looked pretty boring to me. Even though I was a full-on coder before I got there. Perhaps there is no hope?
- analog31 5y ago
  The difference is, one is not a science, and the other is not engineering. ;-) There has always been a dilemma about what to do with bright young people who want to become computer programmers, but who also want to get a college degree. My mom taught a programming course at a satellite campus of a state university in the 80s. The course was listed in the computer science department, but it was basically Programming 101. Her students were mostly grown-ups. Her students didn't face the dilemma because they already had college degrees, or they didn't. They were getting programming jobs after one year in the course. My mom's advice to me was that programming was too easy to justify 4 years of college level training, and that I should major in something "real" to use her words. (She has a masters in chemistry). But actually her idea was to use college as a way to build up domain knowledge that could add value on top of programming skill. She thought there would be a need to be able to differentiate myself from the likely flood of people who were taking the 1 year course and getting programming jobs. This post would come close to trolling if it weren't for the fact that there remain ongoing debates to this day, even in HN threads, about the merit and need for college level training to become a programmer. I'm not the only person wondering about this -- it's a real and hard problem. I actually like the idea of a decent career path for someone who is not interested or cut out to succeed in the college environment, even though I thrived in that environment myself.
louthy 5y ago
I’ve always considered programming to be equal parts: science, craft, and art. Trying to fit it into a pure engineering discipline misses many of the other benefits of the craft and art of development. Much of what we do involves not just telling the computer what to do, but communicating with other programmers (through code). This is where elegance and craft can make a significant difference to the success of a project
alejohausner 5y ago
There is a major difference between engineering and software development: liability. If a civil engineer designs a bridge, and it crashes and people die due to a design flaw, he or she can be sued, and even put in jail. On the other hand, software comes with a license that explicitly makes its authors not liable for design flaws. When was the last time you had to agree to an end user license agreement before crossing a bridge?
- the_rectifier 5y ago
  EE here. In electronics there are hardly liabilities but still the design work is way more based on evidence and understanding rather than fads, hype and opinions.
- pjmlp 5y ago
  Well, in Portugal it is illegal to call yourself Software Engineer like on US after 6 month US codecamps. It is a professional title and while it isn't usually validated, thus only those that sign projects with legal liabilities do make the final exam, every single university in the country is only allowed to have certified engineering degrees. I am aware of similar practices in other countries as well.
- magicsmoke 5y ago
  It might also be instructive to compare with medicine or law. These practitioners are also liable for their actions, have to be licensed by a professional organization, and can have their credentials revoked in the event of gross incompetence. Software designers have none of these burdens.
jasonhansel 5y ago
I would add: engineers are required to adhere to a code of ethics, and in most places are licensed professionals.
agentultra 5y ago
It is engineering. We do all the same things engineers in other fields do. It’s a recognized discipline by many licensing organizations around the world. It’s engineering and there’s no need to wring our hands about it.
CrimpCity 5y ago
I designed buildings for 5 years and switched into software for cultural reasons. Traditional engineering and software are extremely similar. The mindset of successful engineers and developers are virtually identical to the point where if you showed me a great developer I would be willing to bet that they would be a great traditional engineer and vice versa [all else being equal]. Even the organization of how people work together while not exactly the same is quite similar in that many traditional engineering firms will have a technical PM or project lead role and several junior engineers etc. Both industries have the same notorious technical vs management fork. Trad jr engineers will need to work cross-functionally with other non-technical groups like architects and contractors just like their developer counterparts work with marketing/sales people etc. The way we approach problems is the same. We are not doing research or science. We are using our judgment to pick a particular solution from a large solution space to a problem(s) that must meet different user specifications/requirements. Don't get me wrong there are massive differences but IMO they are largely cultural and macro economic related. I'll get to this in a bit but first I want to rant about what the author misses. The author is conflating levels of design abstraction. He sees that traditional engineering has coordinated on common engineered components for example the Bethlehem Steel plant was so prolific it became the de facto standard for steel wide flange shapes for the whole country. So the author is correct in that now since engineers aren't busy designing every single minutia of every beam like they did back in the day when there were no standards they can start from a higher complexity point and focus on more complex designs. However, software developers can do the exact same thing. Software definitely has "engineered components" we call them frameworks, libraries, modules etc. They allow us to "spin" up new tools and working concept level designs very quickly since we're not busy coding all of our data structures from scratch every single time. I'm not going to get into his risk argument since I'm already ranting too much, am lazy and it's a complex topic but I'll just say that the ability to revert a software project back a couple months means you only really lose labor/productivity and not capital. Reverting a building or part of one back a couple of months is a nightmare scenario and on average "rework" is ~25% of a typical construction project's final cost (this includes both capital and labor costs but the point still stands). The midcourse design change argument is flat out wrong. I've been on several large projects that never got built or were unrecognizable from beginning to the final product. There are many reasons for this but traditional engineering design software is mostly to blame since there's more flexibility now (compared to the 1960s) in how people can render buildings so as a fraction of a projects lifespan projects stay in the "development" phase much longer as opposed to the "building" phase which means designers can change A LOT of the project before they need to get buy in from all construction parties and agree on what they're all building. This is one reason among many why construction productivity has gone down and costs have gone up. Alright so what are the biggest differences between traditional engineering and software development? IMO the macro economic moment means that software is higher reward financially which means that software developers have TONS of room to grow in their field either technically, managerially, operationally, professionally etc. There's A LOT of choice and room on where you can take your software development career. This is not so on the traditional engineering side of things. There is limited growth so many many firms are top heavy and put in de facto brakes, check boxes and licensure requirements on the career ladder since there simply isn't enough room for the new incoming grad class every year. It's essentially a pyramid scheme. This makes the work culture very traditional, stagnant, and risk averse. Nobody wants to fall out of line because they can be replaced. There aren't interesting niches to explore or exploit since everything is very full and competitive. The growth in software allows developers the breathing room to sharpen their skills and generally the culture in software really encourages this self improvement. Not so in traditional engineering. Gaining productivity in some new skill means rocking the boat and challenging orthodoxy. The margins are already slim and the boss really needs the reliable bonus he's been depending on so why take a chance on something new? Just wait your turn in line like he did. Allowing developers the time to build technical skill means there's incentive for employers with larger margins to leverage those skills. So developers get more responsibility this is a virtuous cycle which leads to faster career growth. IMO junior devs get much more responsibility earlier in their career than their traditional engineering counterparts. My take is on the pessimistic side but I can't in good faith encourage a smart, ambitious, technical/analytical person to go into the traditional engineering disciplines. EE/CS as far as I can tell is still the best route.
hwayne 5y ago
Earlier this year I wrote a piece interviewing ex-traditional engineers to compare and contrast with software engineering. [1] Pieces like this were a lot of my inspiration: there's big difference between how we conceive of trad engineering and how it's actually practiced. Couple of misconceptions from this piece: > Engineering is less risky than software because engineering experiences fewer constituent component interactions. While minor changes to one part of a car's structure can easily affect the crash robustness of another, it would be unusual for a design flaw in the dome light to cause intermittent engine stalls. In a home construction project, you would have to work pretty hard to make a toilet flush every time someone rang the doorbell. While software has more "component interactions", each component is also more consistent than physical components can be. One example: using stainless steel screws on an aluminum plate can cause your building to collapse. [2] That's a bit of an extreme case, but many fields of engineering, like electrical and chemical, regularly struggle with small changes leading to wild differences in the emergent phenomena. > The final reason that software is more difficult to get right than engineering projects concerns midcourse design changes. The physical world is not as malleable as the insubstantial world of software and, consequently, clients simply have lower expectations. Congress does not go to NASA halfway through a moonshot and ask them to go to Mars instead. Most engineering projects are able to actually use the waterfall design method: determine functional requirements, design, implement, test. For most software projects, this is a recipe for disaster. Very few projects are built using "waterfall", and everybody I interviewed had horror stories of requirements changing mid-construction. At least a couple people I talked to had to move buildings after they were built. One ex-industrial engineer worked for Boeing and his sole job was to manage midcourse design changes. One story I didn't put in the essays: a naval engineer worked on an oil rig. They needed to add a new piece of equipment, but it would have caused the rig to violate certain liveability constraints. It could stay on for short periods of time, but not 24/7. So they built a nearby platform to store the equipment, and then airlifted it in by helicopter every time they needed to use it, and airlifted it out immediately right after. > Writing software is most similar to writing fiction novels. Almost everybody I interviewed said that writing software was very similar to their old work in engineering. A lot of people I've talked to outside the project said it was most similar to cooking, or planning an event, or doing surgery, or whatever. Most fields are like other fields, which is why interdisciplinary studies teach us so much. [1] https://www.hillelwayne.com/tags/crossover-project/ https://www.hillelwayne.com/tags/crossover-project/ [2] https://www.fastenal.com/en/70/corrosion https://www.fastenal.com/en/70/corrosion
johnnyy 5y ago
that's true, writing software is not so easy task.
hentymiller 5y ago
Useful article, I'm into software development right now.

59 points by headalgorithm 5y ago

dang 5y ago

One past thread: Why writing software is not like engineering - https://news.ycombinator.com/item?id=1207721 https://news.ycombinator.com/item?id=1207721 - March 2010 (72 comments)

BadInformatics 5y ago

For a more nuanced and far more detailed counterpoint, see https://www.hillelwayne.com/tags/crossover-project/ https://www.hillelwayne.com/tags/crossover-project/ (discussed in https://news.ycombinator.com/item?id=25823907 https://news.ycombinator.com/item?id=25823907).

ineedasername 5y ago

Part of the problem is that software project decision makers view software projects as far more mutable than physical engineering projects. In a billion dollar construction project, everyone understands that if you want to change the design or significantly expand the scope halfway through, you're going to have a heck of a lot of increased costs & time. In software, it's very common to add scope or major design changes at any stage without understanding that the same cost and time increases will apply. For example saying 90% through the project: -Software: "we need a 2-way interface added between the complex software we're building and some other complex software" -Building: "We need an enclosed concourse built between our new building and the next building over across the street." It is obvious in the later case that there will be a lot of extra time & cost. While in the former, higher level decision makers on a software project don't understand the comparable difficulties.

RNCTX 5y ago
They do understand, they just want to not-pay. If construction companies figured out they could outsource labor to countries with far lower currency values and thereby not-pay for extra labor, they'd do the same.... oh wait...
- ineedasername 5y ago
  They do understand Not in my experience, which may not generalize. Your experience and my experience together won't really give a complete picture. What I experience is this: Even on small projects I've had people say, "okay, can you just add this one thing in the next day or two?" And they don't understand until I walk them through in detail how that one thing is nearly as complex as the initial project, so they have to choose how important it is, and if it's important do they want to wait to release the whole thing or do a release in stages. Of course my experience is not necessarily going to represent the whole. Also when outside consulting groups are involved, I often see predatory behavior: they often agree to do any change asked for and don't bother to explain the costs and time involved until a deadline is missed and the budget is running out. At which point they say "the changes you requested have pushed us over the deadline and the extra time is going to cost $X".

deregulateMed 5y ago

I switched from engineering to programming because of pay, but I can tell you the word Software Engineering is not exactly real unless you are doing some safety critical C or assembly. Whenever you have abstraction, you have lost what it means to be an engineer. There is really only 1 way to engineer something as you end up optimizing for various quality metrics, most often cost. There's only 1 correct answer for a bracket. You want it cheap and as strong as it needs to be. How many correct answers in my code? Do we optimize for clean code? Fast code? Do we change programming languages or go with a familiar highly supported code? There are 2 similar libraries, which do we choose? Programming is a hybrid of science, art, tradition, and authority. I think it pays better because of this complexity. That being said, I'd trust an engineer to program something before I'd trust a programmer to build something.

abainbridge 5y ago
> Whenever you have abstraction, you have lost what it means to be an engineer. That's an interesting observation. I'd say engineering does have abstractions, but they're much better. For example, treating an RSJ as a simple uniform piece of material is an abstraction. In reality it is a crazily complex mesh of crystals. But the abstraction is simple and well studied, so it can be used reliably. Programming abstractions are less reliable. Even commonly used ones like "the filesystem" and "the heap" are vastly more complex. It is almost impossible to remember all the possible hazards when you use them.

cryptica 5y ago

IMO, software engineering won't exist for another 50 to 200 years because: - It takes several years for someone to prove themselves as a developer among their peers and this reputation does not usually spread outside the confines of a single company. People have to prove themselves all over again each time they change company. - Big, high-exposure, high-influence software companies like Facebook, Google etc... force arbitrary tests on prospective developers (candidates); but these tests say nothing about a person's skill as a software developer. These tests are reliable at selecting for status-oriented individuals who can regurgitate solutions to common programming puzzles and present themselves as fast-talking and quick-thinking (I.e. Ben Shapiro archetype). These companies have a huge impact on global software development tools and philosophies; their recruitment decisions have a huge impact on deciding industry best-practices. The huge influx of superficial, fast-thinking, fast-talking software developers within the centers of power is making the software industry look like the medical industry 200 years ago when all reputable doctors insisted that blood-letting, electroshock therapy and lobotomies were reasonable treatments for most ailments. Their arguments relied on superficial, smart-sounding observations and appealed to the authority of large medical institutions. Modern developers like to leverage their associations with financially successful corporations 'sources of authority' to project themselves as top experts and to promote their agendas. - Too many people who have no sense of curiosity at all joined this industry purely for financial reasons over the past couple of decades; these status-oriented people will end up running all the big tech companies and enforcing their ill-conceived philosophies onto others, silencing inquisitive minds. It's a numbers game; the voices of the many high-status, fast-talking, loud-mouthed idiots will drown out those of the few quiet, low-status geniuses. We are entering the dark ages of software development.

airbreather 5y ago

It is not just standards, you will find many engineering contracts these days refer to RAGAGEP - Recommended and Generally Accepted Good Engineering Practice. My take on this is to allow for rapidly evolving practices in an industry where key standards may not be updated to over a decade in some cases, or even cease to exist at all due to emerging fields. What this means is that a responsible engineer has to make a defendable decision, using experience and judgement to justify a particular course of action. As my engineering manager used to say to me, "Would you feel comfortable saying those words again, just adding on Your Honour'at the end?"

killingtime74 5y ago

Great points. Humans love to categorise don’t we, even if it doesn't change anything

nomy99 5y ago

Not sure why people consider it an art.. some software problems only have 1 correct solution that runs in a time constraint, proven by mathematical induction..Art is subjective no?

von_lohengramm 5y ago
Most programming isn't implementing the specific most efficient algorithm. Usually it's mostly architecting, bricklaying, and tweaking.
alfonsodev 5y ago
Is like telling a story that is only correct if you get all the facts said, but there are so many styles to tell the same story, and people can’t agree in what’s best, there is always someone coming up and saying ... actually I can tell the story better to make it more enjoyable and easier to understand.
Closi 5y ago
Not all programming is art, just as not all painting is art. And some math formulas are considered beautiful, and art is in the eye of the beholder, so even the optimal solutions might be art to some.
mannykannot 5y ago
Subjectivity is mostly an aspect of fine art (and some coarser ones, depending on your definition of 'fine'.) Originally, art was a more general concept, making something artificial by using skills that don't just come naturally.
ankurdhama 5y ago
They have to put some label on it, if it doesn't fit engineering or science then art it is.

moksly 5y ago

Most engineering projects have standards. Not the cutting edge stuff, but most of it does. Many are from regulations and safety laws setting specifications for this and that, but some are simply there because they won by being the most popular. Software Development by contrast has no standards. You can hire two different enterprise sized companies with this and that certification in the exact same technologies, who claim to adhere to the exact same principles for best practices and what not. They mean it too, often they’ve even gone through the same sort or internal re-education processes with the same consultant companies at the same time, yet they still manage to build software projects so different that transferring ownership from one to the other, or setting up a multiple supplier open source project, is sooooo much work you wouldn’t believe it. If computer science wants to be engineering, I need to be capable of hiring an architect who makes plans that can be implemented by any supplier, and I need to be able to switch supplier/contractor 2-3 times during the process without issues because the plans can only be implemented one way. We’re probably a lot further away from that world today than we were 30 years ago. The only company that seems to have smelled the music on this stuff is Microsoft and their cloud.

whateveracct 5y ago
It shouldn't want to be engineering in most cases. What a waste if so.
historyloop 5y ago
Standards can only happen when an industry has matured and moves slow enough for these standards not to be obsolete by next year. We have plenty of laws and standards regarding handling private information, payment systems, independent pen testing and so on. So it's incorrect to say we have "no standards" at all. Where it matters, we do. But to try and standardize a process that's evolving faster than a standard can spread is pointless. This doesn't make software engineering any less engineering. Engineering isn't about standards. It's about the design, construction and use of systems.
- moksly 5y ago
  It happens with slow technologies that ought to have standards as well. I do work with OS2.eu (Danish public sector owned open source software organisation) and we recently brought the first project into multiple supplier territory. It’s a Drupal PHP project, and as I understand that means that everything that gets build should follow Drupal standards that are pretty much set in stone. After 6 months of governance going this and that way, and the countries second largest city (and biggest PHP developer) as a mediator, we are only now moving into the blissful world of compliance where everyone has agreed to develop Drupal modules in the same way. Compare this to when we build a new city hall. A massive project involving almost 500 smaller local contractors, in a business that actually moves forward pretty fast. Some of the materials they ended up using weren’t even invented when they began. The project was finished a head of schedule and under budget. I know construction isn’t always like this. We’ve had our share of catastrophic projects, one elder-care center in particular, but compared to buying software it’s almost child’s play, even when things go wrong. So I think it’s perfectly fair to say that software engineering isn’t engineering. If you can even build a simple webpage, without two suppliers disagreeing so much on the “standards” that it takes 6 months of governance to achieve compliance, then there is just so far for the industry to go before it’s anything that even resembles engineering.

wombatmobile 5y ago

> The Economist magazine (Nov 27, 2004 p. 71) cites the Standish Group's estimates that "...30% of all software projects are canceled, nearly half come in over budget, 60% are considered failures by the organizations that initiated them, and 9 out of 10 come in late." In 2021 (as well as in 2004) it is meaningless to talk about "all software projects" without specifying domain, size, scope and project etymology. "Software" is too vast. It could be an app to tell the time with Mickey Mouses hands, or it could be the control software for a joint strike fighter.

robertlagrant 5y ago
> nearly half come in over budget That's much better than I would've thought.

historyloop 5y ago

The gist of the article is that software projects have more ad-hoc decisions and more flexibility. This is due to the nature of software. To claim this as a justification that software engineering is not engineering seems rather shallow to me. You have less repetitive process in software because once software is built, copying it and reusing it as-is is free. In construction if you need to build 10 twin buildings, each of them is a project on its own. In software that'd be building one piece of software and deploying it 10 times. Furthermore I question the notion that software projects can accommodate more "fundamental midcourse design changes". Can you spend 2 years writing a dedicated Windows desktop application and then midway suddenly switch it to being an Android application? That would be fundamental. Reskinning the UI or replacing a dependency with a similar one is not fundamental design change. Software can't sustain fundamental design changes, unless we misinterpret what is fundamental and what isn't. Basically we need to be careful with our analogies so we don't cross from trying to extract insight into flexing our useless cynicism about how software sucks because it's not like making a car in a superficial ways.

ChrisMarshallNY 5y ago

I consider software development an engineering discipline. In my weird, crazy world, engineering is all about discipline (sound of a riding crop slapping a leather-clad thigh), and follow-through. It's a lot less about slide rules and differential equations. I believe that the Romans that built aqueducts (often using coerced labor -otherwise known as "slaves") were engineers. They had a lousy numbering system, no concept of trig (although a few had heard of Pythagorus), and not even a slide rule; yet they were able to build massive, well-designed structures that still stand, to this day, nearly three millenia later. I can't use some Web sites that are just over a year old, because their components went belly-up. But I also consider software development to be a craft. That's really my approach. When I write software, I make a personal level of investment into the outcome. The project must complete. Even when I'm working with a test harness, on a project that is nothing more than an experimental platform, I treat it as if it were a shipping product, that I plan to display in the store window. In fact, I often revisit truncated experimental efforts, in order to scrounge snippets. Since they are already "ship" quality, those snippets tend to be quite useful. A basic habit of mine, is that all of my code "ships," even when it doesn't. That's a craftsman attitude. Getting the project to "ship" state is an engineering effort. But that's just me. YMMV.

deregulateMed 5y ago
You can't be both a craft and engineering. I think the issue is misunderstanding what it means for something to be engineered. There is a correct answer. (Especially because you can always optimize for cost or a different quality metric)
- ChrisMarshallNY 5y ago
  I see things differently. I believe that they can both coexist. I think that the prior art is centuries old.
- jbluepolarbear 5y ago
  You are so wrong. Software is both a craft and engineering. All software fits your definition of cost and quality optimization. It is a craft in that a software engineer isn’t taught how to write the software you want, they’ve built a toolbox from crafting different types of solutions because their existing tools didn’t fit.

fortyrod 5y ago

This seems to broadly conflate CS and Software Engineering. The differences have been covered elsewhere. Stuff like cognitive vs. physical science, (mostly) thinking about thinking instead of thinking about things, or quotes like "A computer is to computer science as a telescope is too astronomy." To be fair, the fact that a lot of us got CS degrees, but really ended up doing software development probably doesn't help clarify matters. The university I went to had a separate degree for Software Engineering and, frankly, it looked pretty boring to me. Even though I was a full-on coder before I got there. Perhaps there is no hope?

analog31 5y ago
The difference is, one is not a science, and the other is not engineering. ;-) There has always been a dilemma about what to do with bright young people who want to become computer programmers, but who also want to get a college degree. My mom taught a programming course at a satellite campus of a state university in the 80s. The course was listed in the computer science department, but it was basically Programming 101. Her students were mostly grown-ups. Her students didn't face the dilemma because they already had college degrees, or they didn't. They were getting programming jobs after one year in the course. My mom's advice to me was that programming was too easy to justify 4 years of college level training, and that I should major in something "real" to use her words. (She has a masters in chemistry). But actually her idea was to use college as a way to build up domain knowledge that could add value on top of programming skill. She thought there would be a need to be able to differentiate myself from the likely flood of people who were taking the 1 year course and getting programming jobs. This post would come close to trolling if it weren't for the fact that there remain ongoing debates to this day, even in HN threads, about the merit and need for college level training to become a programmer. I'm not the only person wondering about this -- it's a real and hard problem. I actually like the idea of a decent career path for someone who is not interested or cut out to succeed in the college environment, even though I thrived in that environment myself.

louthy 5y ago

I’ve always considered programming to be equal parts: science, craft, and art. Trying to fit it into a pure engineering discipline misses many of the other benefits of the craft and art of development. Much of what we do involves not just telling the computer what to do, but communicating with other programmers (through code). This is where elegance and craft can make a significant difference to the success of a project

alejohausner 5y ago

There is a major difference between engineering and software development: liability. If a civil engineer designs a bridge, and it crashes and people die due to a design flaw, he or she can be sued, and even put in jail. On the other hand, software comes with a license that explicitly makes its authors not liable for design flaws. When was the last time you had to agree to an end user license agreement before crossing a bridge?

the_rectifier 5y ago
EE here. In electronics there are hardly liabilities but still the design work is way more based on evidence and understanding rather than fads, hype and opinions.
pjmlp 5y ago
Well, in Portugal it is illegal to call yourself Software Engineer like on US after 6 month US codecamps. It is a professional title and while it isn't usually validated, thus only those that sign projects with legal liabilities do make the final exam, every single university in the country is only allowed to have certified engineering degrees. I am aware of similar practices in other countries as well.
magicsmoke 5y ago
It might also be instructive to compare with medicine or law. These practitioners are also liable for their actions, have to be licensed by a professional organization, and can have their credentials revoked in the event of gross incompetence. Software designers have none of these burdens.

jasonhansel 5y ago

I would add: engineers are required to adhere to a code of ethics, and in most places are licensed professionals.

agentultra 5y ago

It is engineering. We do all the same things engineers in other fields do. It’s a recognized discipline by many licensing organizations around the world. It’s engineering and there’s no need to wring our hands about it.

CrimpCity 5y ago

I designed buildings for 5 years and switched into software for cultural reasons. Traditional engineering and software are extremely similar. The mindset of successful engineers and developers are virtually identical to the point where if you showed me a great developer I would be willing to bet that they would be a great traditional engineer and vice versa [all else being equal]. Even the organization of how people work together while not exactly the same is quite similar in that many traditional engineering firms will have a technical PM or project lead role and several junior engineers etc. Both industries have the same notorious technical vs management fork. Trad jr engineers will need to work cross-functionally with other non-technical groups like architects and contractors just like their developer counterparts work with marketing/sales people etc. The way we approach problems is the same. We are not doing research or science. We are using our judgment to pick a particular solution from a large solution space to a problem(s) that must meet different user specifications/requirements. Don't get me wrong there are massive differences but IMO they are largely cultural and macro economic related. I'll get to this in a bit but first I want to rant about what the author misses. The author is conflating levels of design abstraction. He sees that traditional engineering has coordinated on common engineered components for example the Bethlehem Steel plant was so prolific it became the de facto standard for steel wide flange shapes for the whole country. So the author is correct in that now since engineers aren't busy designing every single minutia of every beam like they did back in the day when there were no standards they can start from a higher complexity point and focus on more complex designs. However, software developers can do the exact same thing. Software definitely has "engineered components" we call them frameworks, libraries, modules etc. They allow us to "spin" up new tools and working concept level designs very quickly since we're not busy coding all of our data structures from scratch every single time. I'm not going to get into his risk argument since I'm already ranting too much, am lazy and it's a complex topic but I'll just say that the ability to revert a software project back a couple months means you only really lose labor/productivity and not capital. Reverting a building or part of one back a couple of months is a nightmare scenario and on average "rework" is ~25% of a typical construction project's final cost (this includes both capital and labor costs but the point still stands). The midcourse design change argument is flat out wrong. I've been on several large projects that never got built or were unrecognizable from beginning to the final product. There are many reasons for this but traditional engineering design software is mostly to blame since there's more flexibility now (compared to the 1960s) in how people can render buildings so as a fraction of a projects lifespan projects stay in the "development" phase much longer as opposed to the "building" phase which means designers can change A LOT of the project before they need to get buy in from all construction parties and agree on what they're all building. This is one reason among many why construction productivity has gone down and costs have gone up. Alright so what are the biggest differences between traditional engineering and software development? IMO the macro economic moment means that software is higher reward financially which means that software developers have TONS of room to grow in their field either technically, managerially, operationally, professionally etc. There's A LOT of choice and room on where you can take your software development career. This is not so on the traditional engineering side of things. There is limited growth so many many firms are top heavy and put in de facto brakes, check boxes and licensure requirements on the career ladder since there simply isn't enough room for the new incoming grad class every year. It's essentially a pyramid scheme. This makes the work culture very traditional, stagnant, and risk averse. Nobody wants to fall out of line because they can be replaced. There aren't interesting niches to explore or exploit since everything is very full and competitive. The growth in software allows developers the breathing room to sharpen their skills and generally the culture in software really encourages this self improvement. Not so in traditional engineering. Gaining productivity in some new skill means rocking the boat and challenging orthodoxy. The margins are already slim and the boss really needs the reliable bonus he's been depending on so why take a chance on something new? Just wait your turn in line like he did. Allowing developers the time to build technical skill means there's incentive for employers with larger margins to leverage those skills. So developers get more responsibility this is a virtuous cycle which leads to faster career growth. IMO junior devs get much more responsibility earlier in their career than their traditional engineering counterparts. My take is on the pessimistic side but I can't in good faith encourage a smart, ambitious, technical/analytical person to go into the traditional engineering disciplines. EE/CS as far as I can tell is still the best route.

hwayne 5y ago

Earlier this year I wrote a piece interviewing ex-traditional engineers to compare and contrast with software engineering. [1] Pieces like this were a lot of my inspiration: there's big difference between how we conceive of trad engineering and how it's actually practiced. Couple of misconceptions from this piece: > Engineering is less risky than software because engineering experiences fewer constituent component interactions. While minor changes to one part of a car's structure can easily affect the crash robustness of another, it would be unusual for a design flaw in the dome light to cause intermittent engine stalls. In a home construction project, you would have to work pretty hard to make a toilet flush every time someone rang the doorbell. While software has more "component interactions", each component is also more consistent than physical components can be. One example: using stainless steel screws on an aluminum plate can cause your building to collapse. [2] That's a bit of an extreme case, but many fields of engineering, like electrical and chemical, regularly struggle with small changes leading to wild differences in the emergent phenomena. > The final reason that software is more difficult to get right than engineering projects concerns midcourse design changes. The physical world is not as malleable as the insubstantial world of software and, consequently, clients simply have lower expectations. Congress does not go to NASA halfway through a moonshot and ask them to go to Mars instead. Most engineering projects are able to actually use the waterfall design method: determine functional requirements, design, implement, test. For most software projects, this is a recipe for disaster. Very few projects are built using "waterfall", and everybody I interviewed had horror stories of requirements changing mid-construction. At least a couple people I talked to had to move buildings after they were built. One ex-industrial engineer worked for Boeing and his sole job was to manage midcourse design changes. One story I didn't put in the essays: a naval engineer worked on an oil rig. They needed to add a new piece of equipment, but it would have caused the rig to violate certain liveability constraints. It could stay on for short periods of time, but not 24/7. So they built a nearby platform to store the equipment, and then airlifted it in by helicopter every time they needed to use it, and airlifted it out immediately right after. > Writing software is most similar to writing fiction novels. Almost everybody I interviewed said that writing software was very similar to their old work in engineering. A lot of people I've talked to outside the project said it was most similar to cooking, or planning an event, or doing surgery, or whatever. Most fields are like other fields, which is why interdisciplinary studies teach us so much. [1] https://www.hillelwayne.com/tags/crossover-project/ https://www.hillelwayne.com/tags/crossover-project/ [2] https://www.fastenal.com/en/70/corrosion https://www.fastenal.com/en/70/corrosion

johnnyy 5y ago

that's true, writing software is not so easy task.

hentymiller 5y ago

Useful article, I'm into software development right now.