I don't think it would either. I think that, just like 'normal" engineering, you ought to have a certain guaranteed caliber at the top and a minimal functioning person at the bottom. It appears to work like this any ways, but the lines would get murky really fast.

A WP dev puts up a website and charges a client $150 to install plugins. The site gets hacked and now who's responsible? Should it be WP Engine, the hosting company, the developer who is likely unlicensed?

Also, what should a database person, embedded software, web designer have as their standards? Should there be an FE test like other disciplines with more specified licenses?

I'm not sure if this fits in at all, but here's a list of professions, of the top of my head, that the professional can get in a ton of trouble and possible face prison time for failure to comply with standards:

Bartender / Server -- If they serve a drunk and injures someone, he or she is liable and can face prison time.

Massage Therapist -- The licensing in CA is 700 hours of training, background check, finger prints, and tons of fees. Can be unlicensed for extra services, but offering anything that resembles medicine from headaches to cracking backs is a liability.

Licensed Construction Worker -- This law is skated around by calling themselves "handy man," but there are legal restrictions on how much a handy person can charge. A licensed construction worker has to have insurance, have certain amounts of experience, etc. Can lose license over many small reasons.

Personal Trainer. Yeah, that meat head at 24 Hour Fitness had to study a 1000pp book and take a 150 question test that cost hundreds of dollars. Can get in trouble for many reasons.

Security Guard -- There isn't a test unless you are carrying weapons, but the liabilities outside of "observe and report" can be severe.

At least in CA, a few of these items require continuing education, further fees, etc. On the one hand, I get it, but on the other hand, it can feel like a racket. The crazy part is that none of the above pays more than $30k / year.

But when you are talking about 6-figure incomes, I'm not really sure if there is any other profession at that pay scale that is unregulated to the level software development is.

No one is making this claim. The link I put up doesn't make this claim either.

Airplane and auto manufacturers are already in this world.

I only know from proxy that airplane software is a very slow process, laden with meetings, leaving no stone unturned. I think the threat of a class-action lawsuit is a very good deterrent for these companies, plus they have actual PEs working, so there is going to be that element ingrained in the entire process.

IMO, it's already well past the point. No one is suing companies** for dumping 1M passwords and bank account numbers, nor is anyone suing for companies offering computer-destroying adware, etc. I guess it depends on how you define cost. I see it as $x1 < $x0.

** (maybe people are suing, but the problem isn't large enough to cause regulations, etc)

Well, it's like everything else; mostly self-regulation and some stuff gets regulated by the state after enough damage is done that people demand it. There are plenty of examples where industry pays for security (e.g. you don't lose money if someone steals your credit card because a POS is hacked) and states are regulating self-driving cars (and I imagine quite a bit about aircraft software/interface design).

None of this really strikes me as that new; would it be better if improving security in medical devices wasn't driven by weird hedge funds? Maybe but at least that shows one way that your final question can get affirmed.

This is what you said:

So you're saying software engineering is engineering. Companies and people are absolutely liable for the software they sell.

It doesn't matter what's used - why do engineers keep signing off on designs that are insecure? The standard we're holding software engineers to when we talk about security issues in software, is rarely used anywhere else. Virtually nothing we do outside of software is secure in any kind of hostile situation, let alone when it's to an entire army of sophisticated adversaries all over the world.

I remember looking up material strength specs in big old reference books in my statics class in college. I assume mechanical, chemical, electrical and civil engineering has a lot of stuff like that. I don't feel like there's a programming equivalent to that. Which is one reason it's so much easier to be self-taught and productive right off the bat.

This seems like you're saying software engineering is not engineering is because it's too innovative. It's like saying that leading surgeons who are pioneering new surgical procedures and creating new processes and guidelines for other surgeons to follow are not doctors because they are not following existing processes and guidelines. Likewise, if the software industry was pretty much stuck in the 60's and 70's and it takes weeks to get one line of change in through the bureaucratic mess and all kinds of certified people manually "testing" and approving changes, maybe then software engineering would be engineering? Some of the worst jobs in software have this kind of "rigor" built into what they do.

The main reasons the software industry at the cutting edge doesn't appear to have standard processes and guidelines are as follows - 1) they are creating for the most part some of the most complex things mankind has ever created[1] and there are no existing processes and guidelines, just new things to invent. 2) what would otherwise appear to be processes and guidelines have been automated in a way that they are more rigorously followed than in any industry. For any critical applications, not some one-off internal apps, the amount of thought that goes into testing is absurd and the rigor with which the components are isolated and how even the smallest change triggers every test to rerun is rarely matched in other industries.

With all due respect, much of engineering is just repeating simple things over and over and that's why failures can be rare (though not uncommon by any means). Software engineering, again, at the highest level, is creating absurdly complex new things from scratch. This is inherently hard, which is why despite drawing from a pool of talent that cannot be matched by any other engineering field, we see lots of failures. At the bottom, we do have people without any real training doing programming, whereas "engineering" requires some minimal certification. But at the top, this is reversed, top-tier talent in software engineering, whether Jeff Dean, Dave Cutler, Anders Hejlsberg, Linus Torvalds or John Carmack, simply doesn't have equivalents in most engineering fields.

[1] There's a simple reason for this - complexity of most hardware is limited by physical constraints. Complexity of software is generally only limited by our capacity to scale software engineering teams.

You are paying good money to people to be a little more diligent than setting up an insecure Mongo cluster without RtFD. This is opening yourself up to script kiddies, not an army of sophisticated adversaries.

The Bay Bridge is widely considered a disaster of civil engineering, but even so, no one is falling into the ocean. It isn't going to be able to handle a nuke from North Korea, but it can still take a few million cars a day and it can still stand after a decent earth quake.

The difference is that, the hapless developers can lose a load of data, still be employable, and not face prison time. This doesn't happen with licensed professionals.

Statics is sophomore-level stuff.

If you ever want to have fun, try taking some free FE and PE prep tests. I once got 2 questions right, and that was right on the heals of 2 calculus courses.

Wouldn't the programming equivalent be like big-O notation, algorithms, other discrete math, computability theory, etc? Or source control, testing methodologies, object-oriented design, programming languages, functional programming, distribute systems, operating systems, networking, etc? There's absolutely no shortage of stuff to study in software engineering.

I'm not even sure if this is true - all kinds of hardware "engineering" is done by self-taught "engineers" (though I'm told they aren't engineers). Tons of people are able to build a house for themselves. Wozniak built some of the first personal computers in history without any real formal training. Where there's a barrier, I think most of it has to do with access to equipment and learning material than anything else.

I guess what I'm getting at here is that software engineering being a more fluid discipline with no clear distinction of where "programming" ends and "engineering" begins, where people being able to move across the spectrum and do different things based on what the situation calls for is a more natural state of affairs and one where good engineering in a true sense is likely to happen than other established "engineering" fields where craftspeople do X and engineers do Y and factory workers do Z, based on some rigid notion of credentials - that seems to me more like a sign of a stagnant, established field that stopped innovating and is filled with bureaucratic rule-following paper-pushers. Woz, the Wright Brothers, Bell, Edison, Faraday - these guy were all basically self-taught right?

I know about 4 of those things which I learned on the job by trial and error. You can't do that with real engineering. Show me a non-software engineer who didn't go to college.

Yeah I'm sure back in the day all that stuff was a lot more like software engineering is now - fly by the seat of your pants, trial and error, everything constantly changing. But the other engineerings have had much more time to mature and codify things. Also failure tends to be more catastrophic and permanent than a fixable bug (exceptions of course).

I'm fine with calling software engineering a very new discipline of engineering. But luckily for people like me - at present you don't have to know what big-O notation is to have a very nice career at it.

I'm saying software engineering isn't engineering because it doesn't know how to handle "the most complex things" created whereas engineers do it routinely. I'm saying it because 15 years ago when I started in IT over 50 percent of software projects failed and now today that number hasn't changed. I'm saying it because the latest magic process is based on what software "engineers" can't do; define what you're going to do and tell someone how long it will take to do it.

Surgeons doing cutting edge research are basing that research on generations of previous surgeons. Engineering has a body of work showing how to do things with what materials should be used. Software is just beginning to have such things but isn't there yet. Yeah, rock star developers do great things but FFS there still isn't an agreed upon way to handle dates across the industry. If only the top tier talent in the industry can be successful it's still more artistry than engineering.

Practically every house is at this level of security - who is signing off on these designs? Any random kid can get into any house on the street. Also, expecting random developers to be experts in securing production deployments is like expecting the guy who signs off on the boiler (I believe a professional engineer) in an apartment building to build a large bridge. This has to do with somebody wanting to do things on a shoestring budget and has nothing to do with the maturity of the software engineering as a profession. It's like criticizing civil engineering as a field after hiring a bunch of guys off the street to build a 5-story apartment. It's not gonna work and that has nothing to do with civil engineering.

Again, this would be true in any field - maybe outside of the military or something, I can't imagine anyone would face prison time for designing something that was insecure against an attack. Virtually all computer hardware fails this test and there are very few physical systems that provide this kind of guarantee. If somebody cracks my file cabinet opens and steals all my secrets, do you think whoever was involved in the design will face prison time? Prison time would bev extremely rare even for gross medical malpractice.

Well... not every person who's had their house robbed...

We're focusing on the maturity of the discipline. But another big facet imo is the ability to relatively easily fix mistakes. Doesn't work as well for a bridge, circuit board, thresher, etc.* You really need to get that stuff 100% right the first time - hence the need for much more rigor. Yes rigor is important for good software engineering. But it seems not quite as mandatory.

*I have no idea what chemical engineers do.

Shrink-wrapped software pre-internet might be closer to what the other engineerings do. Or embedded programs that can't easily be updated. I remember the day I realized you could now download drivers over the internet - MAGIC.

Difficulty of change isn't a factor. The bugs you're describing after the equivalent of hanging drywall crooked. It happens in almost every building and then someone comes by and patches it up with putty.

That type of stuff is an implementation detail. And that's where having these distinctions gets difficult. Most of us are doing both engineering and craftsmanship.

You're moving the goal-post here - no one is saying all of software development is equivalent to engineering, merely that at the top end, the practice easily clears the highest bar you could reasonably set for engineering. What you're saying is like saying most houses are poorly built so civil engineering isn't engineering. Or that nursing assistants don't know how to perform surgery so the whole medical profession is a failure. Software projects fail because software is hard, but extremely valuable, which means some projects will be worked on by people who are unqualified. This has to do with economics and has nothing to do with the field as a whole. If you're willing to pay for top-tier talent, you can get it. It's going to be expensive because what they can do is extremely valuable.

Also, you will find that a lot of the places that are failing have "engineering"-like processes than and a lot of places that are advancing the state of the art don't. There's a reason why hardware companies have done extremely poorly in doing anything software related while software companies don't have much problem competing in the hardware space. Google, Microsoft and Amazon all have had great success with hardware products. Samsung, Sony, HP, Dell, Intel, etc, can't seem to compete in the software space for the most part. The kinds of things people are talking about as being important for "engineering" only work for the simplest things - problems don't solve themselves at the sight of credentials, standards and processes. More importantly, these are slowly going away - engineering is increasingly replaced by software engineering and typical engineering processes are being replaced by processes that come from software engineering. Features are moving from hardware to software and design of hardware is moving from design documents that are intended to be interpreted by humans to source code in hardware description languages. You don't need to keep solve the same old problems again and that's what traditional engineering does for the most part.

So are software engineers doing cutting edge research just making stuff up from scratch?

Again, this has to do with the complexity of software - fully describing the functionality of even fairly simple software is exceedingly difficult. It also has to do with how absurdly flexible software is and how unbelievably productive software engineers are when they are able to reuse software. Other fields where reuse is more difficult or all work is assumed to be integrating existing components, are going to have more stable estimates. It's not even that different from home building - if your customer insists on a schedule and a budget that assume stock components but his requirements can only be met by custom-building everything, your estimates are going to be way off. Only this is much more difficult to express or anticipate because the capabilities of software modules so much more difficult to understand and requirements are far more likely to be poorly expressed or even changed in a way that drastically changes the implementation.

There still isn't an agreed-upon way to do AC power sockets across the industry and don't get me started on USB/HDMI/etc.

I mean, even now, if you work on COBOL programs running on mainframes doing batch transactions and reconciliation for banks or something, I bet the procedures are more engineering-like and changes require a series of sign-offs and people feel all self-important for having complex manual processes.

But on the other hand, at the top of our profession, there are places like Google and Amazon whose infrastructure absolutely cannot fail on a large scale without extremely large financial and reputational repercussions. While web applications and services are easier to patch for simple bugs, they come with significant operational responsibilities and losing customer data on a large scale or being unavailable for a period of time can be catastrophic. The general level of reliability of services we're seeing at this scale is absolutely amazing and is one of the most significant engineering accomplishments of our time.

Or if we go back a little, read about what Microsoft did to ensure compatibility across Windows versions (https://blogs.msdn.microsoft.com/oldnewthing/) and tell me that's not engineering.

Or consider how much of physical engineering these days is driven by software - all this engineering rigor and processes and what not are no good without the software that's performing bulk of the work, written by those darn non-engineers.

blackize, candybar - not arguing with any of that stuff. But there are still some fundamental differences between building software vs. hardware (hard stuff). Whether or not that means you should call it something different is a fun semantic debate I guess.

for the engineer debate.

I am a computer engineer who also took chemical engineering for 2 years before switching to CmpE, worked in civil engineering (dad's company for summer job), has worked as an electrical engineer and also worked extensively in software. Mainly I write code for scientific/engineering research applications.

So I guess I have a different perspective on the subject "is software engineering?".

In short - yes, software development is a lot like engineering and I think the term software engineer is applicable.

I will lol a little bit at some of the grandiose claims about software being the most complex/challenging/etc. Be proud of how talented a skilled software developer is - but hold off on claiming supremacy without any substantial exposure to engineering.

I don't really care either way but my point is that we don't really have a much better name - developer/architect is also borrowed from another field and programmer is at this point almost a pejorative and comes from a time when most of the work was rote and didn't encompass the design aspect. The other thing I'm arguing is that software engineering at its best is well ahead of the other engineering fields in terms of best practices and the most likely change we will see is other engineering fields becoming more like software engineering, in terms of tools and processes than the other way around, and or being gradually subsumed by software engineering. What I'm most strenuously arguing against is this notion that software engineering is behind other engineering fields in obvious ways and the field can advance by incorporating their rituals into our practice.

https://en.wikipedia.org/wiki/Hoover_Dam

Such a large concrete structure had never been built before, and some of the techniques were unproven. The torrid summer weather and lack of facilities near the site also presented difficulties. Nevertheless, Six Companies turned over the dam to the federal government on March 1, 1936, more than two years ahead of schedule.

****

With all due respect, what is the obsession with house locks?

Yes, in your usual 'burb, said locks are fine because the general population in said area is honest enough to not break into a home. The same can't be said in the ghetto, where they have very different styles of doors, plus bars on their windows. You are also more likely to see fences and mean dogs. These are stronger security measures than bay windows, open yards, and lap dogs.

This is called a plumber, not an engineer.

Yes, he is probably licensed and insured.

Yes, he will get in a ton of trouble if said boiler blows up due to improper wiring and piping, and he will face severe penalties if he is unlicensed. Someone has to cover the cost of repairs and it isn't the home or building owner.

Why wouldn't I expect a person I'm paying loads of money to properly secure a website? What would I be paying for, exactly, if he isn't capable of reading docs?

The amount of fraud needed to pull this one off is pretty incredible. I could barely switch out a window without the police showing up and asking to see permits.

The point is about licensing and liability:

http://www.cslb.ca.gov/Contractors/J...sequences.aspx

Those who are caught contracting without a license likely will have to appear before a Superior Court judge to answer to misdemeanor charges that can carry a potential sentence of up to six months in jail and/or a $5,000 fine, as well as an administrative fine of $200 to $15,000. If illegal contracting continues, the penalties become more severe. A second offense results in a mandatory 90-day jail sentence and a fine of 20 percent of the contract price or $5,000.

The get said contracts, you have to have a minimal set of skills, then you need to have insurance, etc.

Your dresser drawer may well be good enough to hold some of your documents. If you really have secrets, you have the option to buy a high security cabinet, a 400 lb safe, etc.

Going back to the door handle example, you don't need locks at all in certain areas of the country, and that is good enough for these people. Other people don't have it so secure, so they have to buy stronger mechanisms.

There is good enough, and there is utter neglect.

Example:

I built a server, set up the proper firewalls, made sure my ports are behind iptables, use strong passwords, made sure the database has proper configs, etc.

This is following good practices. Granted, I'm not a professional and probably missed something, but my liability is my own server. I wouldn't go around calling myself an engineer nor would I ever consider my work liable. I also care enough about doing this right that I just use Heroku.

****

I open an account with DO, leave root open to login, set the database to trust, and don't bother sanitizing my inputs.

This is neglect, pure and simple.

***

and to be clear again:

I am NOT claiming all software is not engineering. I am claiming that the general state of software is not engineering, and I don't think it will ever be engineering without some minimal set of rigor and responsibility.

I stand corrected.

Another thing to consider - a lot of software used by engineers is written by engineers. Software is a skill - and many many engineers have very broad skill sets beyond their design specialty.

https://www.nytimes.com/2017/04/30/b...ight-fine.html

It's a fairly simple statement. Let's set aside the malleability of software and simply consider the cost of the following software:

Google Search
Windows
Microsoft Office
Facebook

And also the revenue they've earned and their current value. These are ongoing projects some of whom have been in active development for decades. Now consider that with software very few of these hours were spent were spent on fighting physical constraints and almost of them were spent on adding and dealing with pure information complexity. From an information-theory perspective, it's really not close between these largest software projects and anything else. I didn't work on any of these and I'm trying to feel important by association - their achievements have nothing to do with what I've worked on. But it's simply true that software engineering does deal with the most complex problems of any domain - and this trend will accelerate since the complex, inherently irreducible parts are moving towards software.

I think we should make all software engineers go through at least 1000 hours of study and a series of ridiculously hard tests, like actuaries, before they are allowed to touch a computer.

True story: one of my many many **** jobs was mailboy for a summer at Wausau Insurance. For you kids, back in the day memos were the only way to distribute information to multiple people - and those yellow envelopes were vitally important. I already had a degree by this point but no ambition or job prospects. My friends and I were the model for the show Workaholics.

Anyway after working there a while, I decided that maybe I should become an actuary. I'm good at math, seemed like an interesting enough job. Asked around - expect 1000 hours of study to pass the actuarial exams.

Huge revenue can support quite the bloat in diminishing return features. Most of the functionality of those platforms was accomplished in the first fractions of the effort. Accommodating larger scopes of redundant information isn't all that impressive.

I am more impressed by networks of modern road systems if you are going to set accomplishment = effort and cost. And at least physical systems are not near as far down the diminishing return curve as mature software platforms.

FWIW - The physical internet is impressive (but mainly built by engineers).

Software is unique that the distribution/production cost of unit n+1 is pretty much zero. Which means it can afford negligible utility features when the user base is hundreds of millions. Thus it can bloat and bloat and bloat (saturate) yet not become counterproductive - in a manner physical platforms cannot. So measuring accomplishment in man hours is very misleading for software.

The Interstate Highway System - largely built in about a decade - has to win some kind of award.