Unacceptable. Software development needs to be treated as engineering. We need to finally rid ourselves of the concept of "quick and dirty". If that means all the people who live off of that style of development leave the industry, fantastic! It would be great if every manager who told his devs "I don't need it to be perfect, it just needs to kind of function and be ready by EOB today" could end up financially liable.
>Shirley the intern who didn't know what she was doing
What was she doing working on a production system unsupervised? A plumber-in-training may get to work with the pipes on his own a bit but you can be sure the certified plumber will inspect everything before signing off.
The IT industry needs a shakeup and if it takes something like this to accomplish it, good.
A small subset of these kinds of systems end up at big companies, because they're acquired, or because the company grows, etc etc. How do you draw a line in the sand where everyone stops the world and re-implements all the "quick and dirty" stuff?
I briefly worked in construction and I've seen plenty of "quick and dirty" there, also, particularly in suburban renovations. Time is money in these projects, and corners are often cut. I'm not saying all engineering works this way, clearly building bridges is a different matter, but I am pointing out that there is a spectrum.
Quite frankly, it seems like you nailed the point when someone should be re-implementing the quick and dirty stuff; the moment it gets acquired and integrated. I do understand what you're saying, but I cannot agreed that just because something is difficult to do means that one can hand-wave responsibility. In the case of large companies that have been subject to breaches recently, the only reason they get by after the fact is because they can afford to; if it were to happen to any of the small shops running in "Quick and Dirty" mode and something happened, the shop would more or less take a hit it could not recover from.
I see this in action and hear the same excuse every single day with my clients, and it doesn't matter if they're a multi-national whose infrastructure spans continents or some dude with a pirated hyper v host in his room, the excuse is always the same: "Oh we had to do it that way, and didn't have time to fix it."
Quite frankly, it's non-sense, infinitely moreso in virtual environments. The workflow and technology available for patch-testing, deployment, and rollback has never been faster, safer, or easier than it currently is; companies just aren't doing it, and no one is holding people accountable for negligence. If the aforementioned construction workers who did a quick and dirty job cause major damage to the house as a result, they would be liable for damages due to their negligence. I'm not sure why we in the Tech community somehow think we're above responsibility for our negligence.
I understand that money is on the line - I deal with clients where every minute of down-time has a substantial dollar figure attached, and there's always the attitude of "we'll deal with it later"; and yet, this attitude always ends up causing more trouble in the end, and naturally costing far more.
Edit: Changed "...responsibility for our own negligence" to remove "own"
How would you propose doing this, though?
In other branches of engineering, there's licensing and certification processes - but only after you have gone thru and passed an accredited course (ie - university engineering degree).
This is fine for the majority of engineering, because most of it is fairly settled knowledge, and doesn't change on a nearly weekly or faster basis; unlike what we call "software engineering".
We could say that current university computer science or similar degrees could be the initial thing to allow you to get certified and/or licensed - but how would that translate into the testing for certification/licensing?
Especially when "best practices" might (will) change almost literally overnight? How could any company know that Bob Jones MSE (Masters in Software Engineering) has and knows everything there is to know and is 100% up-to-date with the latest software engineering, security, database, etc practices needed for his craft (especially those items that changed last week)?
With other engineering fields, such change doesn't happen anywhere near as quickly (and in some, it may be years or decades between new updates).
Also - how would propose "grandfathering" in existing software engineers and other similar professionals? While on the surface I would like to see such a change to a more professional attitude, I don't want to see myself personally "left out in the cold": I don't have a degree in the field; my knowledge is self-taught and/or learned on the job over the past 25+ years.
I don't know anywhere near everything, and in many cases I am always learning something new (or learning the name of some "pattern" that was something I had been taught years or decades ago before it had a name). I honestly find the learning aspect to be one of the things I immensely enjoy about my software engineering career.
But I don't want to find myself tossed aside because I don't have a degree, or find that I have to go back to school just to keep my career (indeed, going back to school for this reason would likely leave me without a job in the end because of many businesses balking at hiring older developers like myself - which is also why I tend to always stay abreast in my skills and knowledge).
I'm not expecting any answers - just wanting to throw out some food for thought.
And I wouldn't expect someone to need this certification before a compiler would run. I would envision something more along the lines of: a company cannot have a "badge of software engineering" or some such unless all the developers working on their production systems have these certifications. If it's a small company running a PHP website then they probably don't need certified people and probably their clients won't (initially) care that they're missing the saftey badge.
