December 10, 2015 at 7:57 am
Iwas Bornready (12/10/2015)
Gary Varga (12/10/2015)
There have been a number of incidents that could have kick started it. Regardless, governments could have put a framework in place and demanded that all individuals working on government projects are "certified and regulated".That process should have been used when the government built the national healthcare software.
Great shout!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 10, 2015 at 8:11 am
I think we are more like mechanics than engineers.
Like mechanics we tend to start off with some level of training but the acquire skills on the way. Mechanics have to adapt to changes in Motor vehicle technology (contact breakers aren't used in ignition systems for example) and you get a whole range of skills and abilities from the "elite" Rolls-Royce/Mercedes trained mechanics down to backstreet bodgers who really shouldn't be let near a peddle-car let alone one with a motor .
December 10, 2015 at 8:13 am
I am a business application developer, no engineer. I could write a program to capture a license plate number from an image. If you need it to do 10k license plates per hour, you need an engineer.
December 10, 2015 at 8:19 am
Manic Star (12/10/2015)
We're janitors.We clean up the place, take out the trash and keep the mechanism humming along with regular maintenance that no one sees, appreciates or cares about until its not done.
I've referred to myself as a data janitor plenty of times.
December 10, 2015 at 8:28 am
cjb110 (12/10/2015)
Yes we are, and are we striving to reach the same standards as physical engineering, yes I think most of us are.I think that article was a disservice to both professions.
However there are some things to remember that makes our engineering harder to achieve that standard:
1) its a new industry, only ~30-40 years old, not the 250+ years of industrial engineering (let alone the 3000 years of actual engineering), why would we magically reach this standard any quicker?
2) multitudes of solutions to one problem, if your building a physical structure you've got physical constraints this greatly reduces the amount of solutions, therefore each of those solutions can be studied in depth and best practises used and revised. Computer engineering doesn't have that, almost all problems have multiple solutions, there are patterns true, but the solution space is far far larger than physical engineering.
Could we help ourselves? sure, standardising on languages would obviously be a great start to this, but we're still no where near this.
I think there's some truth here. Certainly we face many less limitations than physical engineers do. We have more ways to work, and we can adapt to changing situations.
However I'm not sure standardizing on languages is the key. There is power in different languages and are we saying that Java is better than C# in some fundamental way? We shouldn't use Scala because FORTRAN will do and is better known?
I would say that it's more that our fundamental practices should be known and documented. We should have methods of testing and verification, both of which we do poorly in many systems. I think the point about documentation, with well known ways of describing interactions and effects, might be a good place for us to start calling ourselves engineers.
December 10, 2015 at 8:33 am
Most operating systems disclaim use in safety-of-flight applications. I wonder why. ;^)
December 10, 2015 at 8:35 am
Geoff.Sturdy (12/10/2015)
I think we are more like mechanics than engineers.Like mechanics we tend to start off with some level of training but the acquire skills on the way. Mechanics have to adapt to changes in Motor vehicle technology (contact breakers aren't used in ignition systems for example) and you get a whole range of skills and abilities from the "elite" Rolls-Royce/Mercedes trained mechanics down to backstreet bodgers who really shouldn't be let near a peddle-car let alone one with a motor .
Hmm, at least for my career the machines I build have never been built before, thus engineer is closer in that analogy.
December 10, 2015 at 8:45 am
I think we're alchemists (most of us anyway) in terms of where we are in the profession's evolutionary development. Others in this thread have astutely pointed out that we are more like craftsmen in a relatively new profession. We may just simply need more time to develop and mature the discipline until it resembles something comparable to modern chemistry; at least I think chemistry/chemist might be a more accurate model than engineering is for software development given the complexity, volatility, and unknown unknowns, etc. Software production support seems more like a traditional engineering endeavor given it's relative predictability if the proper controls are in place.
December 10, 2015 at 8:47 am
ccd3000 (12/10/2015)
I think we're alchemists (most of us anyway) in terms of where we are in the profession's evolutionary development. Others in this thread have astutely pointed out that we are more like craftsmen in a relatively new profession. We may just simply need more time to develop and mature the discipline until it resembles something comparable to modern chemistry; at least I think chemistry/chemist might be a more accurate model than engineering is for software development given the complexity, volatility, and unknown unknowns, etc. Software production support seems more like a traditional engineering endeavor given it's relative predictability if the proper controls are in place.
I like that. Maybe we are more alchemists than engineers or craftsman.
December 10, 2015 at 8:49 am
Maybe in the pure administration tasks we could be considered engineers, in that aspect there's usually a clearly defined right way and wrong way to do things and the wrong way usually has clearly defined and understood reasons why(for example not insulating wiring properly). Our administration tasks are similar in that regard, for there's a clearly defined way to set up users for example the drawbacks of the various options are well known and can be taken into consideration while building a system.
When it comes to development however I tend to feel much more like an inventor, typically I'm doing something that's never been done before so while there might be guide lines on how to use the tools I need there's no guideline on how to do what I'm trying to do with them. Very often when I develop it's with a poke it and see what happens approach as that's the only way to find out the results.
There's definitely a certain art in how we develop but sadly it's something people rarely get to see(or would appreciate anyways) as if it's all done right very few people will every see the details.
December 10, 2015 at 8:57 am
I know a few voodoo priest like DBAs
December 10, 2015 at 8:58 am
Manic Star (12/10/2015)
barry.mcconnell (12/10/2015)
How do I wrap my new bridge in a TRY ... CATCH? 🙂
The same way Roman engineers did. Put your entire family underneath and march an army across the bridge four times. Is it any wonder Romans over-engineered everything? LOL
This does point out a huge difference between software and physical systems. The stakes on the physical systems as far as cost and safety are radically different most of the time from soft systems.
I mean a bad pointer causing blue screen can generally be rebooted out of, a bridge collapse kills people, local economy, etc. You can't just reboot it.
My guess is the higher the stakes to the system being built, the more sturdy its build is. Most of our projects just don't need to be that sturdy.
The few times they do and we don't meet those specs, you have things like the OPM breach. Where did that fall down?
The stakes for a database failure are potentially higher than the failure of a desktop application. An organization can't reboot it's way out of a mass data breach, although I'm sure they will spend the rest of their lives wishing they could rollback time before the event and nail down their security.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 10, 2015 at 8:59 am
Absolutely!
December 10, 2015 at 9:28 am
I agree that we are more like scientists than engineers. There is a certain element of experimentation within controlled limits.
You produce a solution that you have tested (hopefully!!), but no amount of testing can 100% guarantee no real-world issues. You often reach a solution (like a scientific theory) by induction or experimentation rather than just following predefined guidelines. Your tests(experiments) prove to your satisfaction that your theory works, but in the big wide world someone manages to falsify your theory/break your app. Your theory/app is then refined to fix the bugs.
I suppose when engineers came up with the idea for a suspension bridge, they were doing a similar thing and no-one know how safe they were until a good few had been built and used.
If you look into the history of suspension bridges (for example) you will find that the engineers haven't always covered themselves in glory as far as quality assurance is concerned.
The notion of traditional engineers as paragons of quality/testing and IT professionals as slapdash chancers is something of a generalisation to say the least. That's not to say that the IT profession couldn't introduce some platform agnostic "chartered" status which tests real-world savvy rather than knowledge of a given language/platform, in an effort to drive up standards.
December 10, 2015 at 9:28 am
WOW, very good topic for discussion, Steve. I just read your article in my copy of today's SSC newsletter and came it to post my reply. There are already 5 pages of responses and I'm only now adding my own.
Oh well, its important and I want to add my $0.02 worth. I've been writing code, and sometimes doing DBA activities, for a couple decades. I've had the titles of Programmer, Programmer Analyst, Web Developer, Web Analyst, Analyst Programmer and now my title is that of Application Developer. But of all the titles I've had, the one I've liked the most is Software Engineer. I've felt like that was for me, the most appropriate and conveyed the most prestige. I consider myself to be a software engineer, using the same definition you gave for an engineer in your article. But I also recognize that in most engineering disciplines certification is involved. And continual education to maintain the certification is also required. We don't have that in our profession, generally speaking. (Some companies might, I don't know as I've never heard of such a thing, but I can imagine that some progressive companies do.) I honestly hope that some day our profession will require certification and education to maintain that certification. This relates to other discussions here on training by companies or the lack there of. Perhaps if those companies which today don't want to train anyone and at the same time require their IT staff to be held responsible for major snafus in the software/data/IT/etc. were to have to invest in those employees maintaining certification and education in an effort to reduce the chance of snafus, then both companies and employees would ultimately benefit.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 15 posts - 31 through 45 (of 67 total)
You must be logged in to reply to this topic. Login to reply