December 10, 2015 at 6:29 pm
I think we are.
We develop new and maintain existing systems and engines within software systems, which as we all know is a related science referred to as computer science.
To say we are not engineers is to say we do not develop new or maintain existing technological solutions. Many of us very much do this on a daily basis from developing a complex ETL system to developing a data warehouse.
However, the word "maintain" is important when I say this. Performing backups, log shipping, etc are certainly maintaining, but not the same as performance tuning, coding, scripting and etc. We "maintain" by executing scientific knowledge and mathematics as well develop new technological solutions with the same methods.
While you may not be engineering on paper, you certainly are a database engineer.
December 11, 2015 at 12:36 am
Steve Jones - SSC Editor (12/10/2015)
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.
The reason I brought up standard language is based on what a lot of other comments are bringing up formal training, guilds etc. If anybody honestly thought that would work if an Computer Engineer had to do the same for C#, then Java, then C++ then..., or TSQL, then PLSQL...no-one would ever reach the end!
My thinking was very few languages actually have any significant benefit over any other, the reason for most of them is time, politics and personal feelings.
If we had one general purpose, one functional and one SQL/set based...would we really loose out?
Agreed though, maybe the languages can stay flexible and the surrounding processes and documentation can be the standardised.
December 11, 2015 at 2:40 am
It's kind of surprising to me that Steve Jones makes the distinction based on liability and formal knowledge. That might be an US thing. As an engineer, liability is part of the job, but often not the most important part. And formal knowledge, well, it's not only in software that things change rapidly.
I've worked as an electronic design engineer for more then 10 years. Industrial products. Often safety-critical. The engineering-part of the job is thinking about system design / interfacing with the world / reliability / safety / long term support / maintenance. Formal knowledge ? Hardly relevant.
Now I'm working on data-centric business software. Just like many designers / developers we implement business rules in software. The main challenges are keeping the code maintainable and structured when more than 30 developers work on the same code base. For me, somehow it still doesn't feel like engineering. It's complex, it's challenging, that's true. But for me it only feels like engineering when I'm estimating data size / measuring throughput / fixing performance issues / architecting alternate solutions.
So in the end, for me, business software development is not really engineering. But system architecture and database design are engineering tasks, yes.
December 14, 2015 at 12:23 am
That reminds me of a Calvin & Hobbes' cartoon. If I remember correctly, Calvin asks his father how the load limits on bridges are determined and Calvin's father replies that heavier and heavier trucks are driven over the bridge until it falls down. At which point, Calvin's mother interjects...
This is the difference between the trial-and-error-method and engineering, namely working out the answer based on proper specifications, the application of the appropriate sciences and peer review?
December 14, 2015 at 10:48 am
No, we're not engineers. Software and the IT industry move to fast to allow for the rigor of an engineering discipline. It is both the beauty of the industry and the Achilles heel. However, in the next decade I expect business is going to force IT to slow down and become more disciplined. Particularly as more and more personal data moves into the "cloud".
December 16, 2015 at 8:35 am
Nyteshades (12/14/2015)
No, we're not engineers. Software and the IT industry move to fast to allow for the rigor of an engineering discipline. It is both the beauty of the industry and the Achilles heel. However, in the next decade I expect business is going to force IT to slow down and become more disciplined. Particularly as more and more personal data moves into the "cloud".
Two things.
What's the rigor? There are people that work quickly, include lots of tests and evaluation of their work. The space shuttle team at IBM has been rated as one of the best ever. I'd be careful here. There are engineers that move quickly and do shoddy work, so the question is more is our profession capable? Whether we do or not, that's an individual item.
Why would we slow down? I suspect that as more people move to the cloud, they'll be trying to move quicker, and "roll forward" when issues occur rather than slow down and be more disciplined. Which is a bit sad as better software dev practices are needed in the cloud.
December 16, 2015 at 9:13 am
Steve Jones - SSC Editor (12/16/2015)
Nyteshades (12/14/2015)
No, we're not engineers. Software and the IT industry move to fast to allow for the rigor of an engineering discipline. It is both the beauty of the industry and the Achilles heel. However, in the next decade I expect business is going to force IT to slow down and become more disciplined. Particularly as more and more personal data moves into the "cloud".Two things.
What's the rigor? There are people that work quickly, include lots of tests and evaluation of their work. The space shuttle team at IBM has been rated as one of the best ever. I'd be careful here. There are engineers that move quickly and do shoddy work, so the question is more is our profession capable? Whether we do or not, that's an individual item.
Why would we slow down? I suspect that as more people move to the cloud, they'll be trying to move quicker, and "roll forward" when issues occur rather than slow down and be more disciplined. Which is a bit sad as better software dev practices are needed in the cloud.
More speed. Less haste.1
1It's not even as if I made this up!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 19, 2015 at 2:09 pm
99zardoz (12/10/2015)
I would certainly welcome a platform-independent way of obtaining a lasting certification that only required renewal say every 5 years.I went to the trouble of getting one Microsoft cert and found it really to be an exercise in "how good is my memory at retaining Microsoft-approved approaches to problem solving".
In my experience Microsoft certs do have some value - if you employ two people holding the right sort of cert you can easily get into deals with MS that without those people you would find very difficult to get. The people with those certs may be absolutely useless for everything but this indirect utility, but their certs are nevertheless useful to the company. This could be fixed by reforming Microsoft, and is sometimes bypassed by convincing Microsoft you are doing great stuff even if you don't have people with Microsoft certs.
What we need is a way of demonstrating that you understand good practices for developing and testing code without being tied to a particular platform or language, or whatever "emperors new clothes" software development trend is in fashion. Something that will still be relevant in 5 years, and then you should have to renew it by sitting some sort of exam in changes in widely accepted changes in software practices, again, avoiding "fads".
I see two problems with this: first, 5 years may be too short a period unless the recertification process is pretty trivial (which is probably undesirable); but providing a log of continuing professional development every 6 months and having the certifying body evaluate that log (and validate it by checking that you did attend the events you have logged) is much less hassle than full recertification and is (I think) an adequate substitute.
Second, avoiding fads would be very difficult: we get new labels for old things quite regularly as various "experts" who have never bothered to learn any of the science reinvent whe wheel (often with a few sharp corners and sometimes with no axle) and get it hyped into todays answer to everything. The same happens with management methods, development and quality assurance methods, and so on, as with technologies and science. The trouble is that the new labels get adopted by the majority, as the majority of software people have not learnt the science and are taken in by the hype, and testing people's knowledge can either use the new (usually vague and imprecise) terminology and disqualify those who have learnt the science or use the old terminology and disqualify the bright young things who have struggled to make sense out of the overhyped and imprecise new terminology.
I would see it as a way of weeding out "copy and paste" developers and those who have a vendor certification but lack the common sense gained by experience.
Copy and paste developers are not a bad thing, and anyone who doesn't copy and paste where appropriate is not an engineer at any level. I've had to invent things to enable tools to be built to enable development of difficult components of a project at acceptable cost, but in inventing and implementing that stuff about 95% was copied straight out of the technical and scientific literature or from existing softare whether compilers/interpreters/os components/type systems or applications. That's what engineers do - they don't reinvent the wheel if existing wheels will do the job and are available, they copy the existing ones (or, preferably, buy them from whoever makes them if that's economically feasible).
And whether weeding out those who lack the common sense gained by experience is a good or a bad thing depends on what "weed out" means - it had better not prevent them from gaining experience (and hopefully common sense).
The problem is that Microsoft et al would undermine any attempt to establish such a qualification. The BCS membership in the UK is so uncommon that it means precisely nothing to most recruiters. It was also too onerous to obtain. We need a two hour test that can separate the wheat from the chaff. It could be done.....
BCS membership is not all that uncommon - most of the people I worked during my four and a bit decades in the industry were both Members or Fellows of the BCS and Chartered Engineers. And I don't think Microsoft would do anything to undermine a serious attempt to establish a proper qualification; your et al, assuming it includes the verious companies running the crammers and the bootcamps and teaching the stuff in such a way as to destroy the value of the qualification (because it will all be forgotten except as jargon approx two days after the exam) as well as companies like Cisco would of course be a problem.
Tom
December 19, 2015 at 2:52 pm
99zardoz (12/10/2015)
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.
There is a pretty recent example, that suggests that civil/mechanical engineering may not be as much ahead of software engineering as most commenters here seem to believe.
The London Millenium Bridge was opened on 10 June 2000 after main works had run 12% over budget and 16% over time. Immediately it began misbehaving sufficiently that it was decided to restrict the number of people allowed to be on the bridge at the same time to far below the designed capacity; this of course resulted in queues; it didn't result in any reduction in the bridge's misbehaviour. Further restrictions on numbers were imposed, with no useful result, until two days after it was opened it was closed down pending a fix.
At that point we can already see two serious failures to meet proper engineering standards: clearly no stress test up to expected loads had been attempted before exposing the public to this new bridge; and after the bridge was discovered not to behaving contrary to specification the public were left exposed to it for almost two days instead o it being shut down immediately for proper testing and repair.
The testing and repair then took place, and lasted almost two years - twice as long as the main works had been scheduled to take. Effectively the main works phase ended up 200% behind schedule - this civil engineering project sounds like a government software development project, doesn't it!
Incidentally, the bridge was closed briefly (less than a day) in 2007 because people on it risked being blown off it by Kyrill (a storm). But that wasn't a bug, it was an intended design limitation, akin to the various maxima supported by, for example, SQL Server 2014.
Tom
December 19, 2015 at 3:02 pm
jshahan (12/10/2015)
I'm in agreement with those that say we are not engineers. However to those that say we should have the same standards or disciplines as those who design cruise ships and high-rises, I would ask what effect that would have on development costs.
Well, if the fly-by-wire software in commercial passenger aircraft were not engineered to that standard living anywhere near an airport or under a flight path would be a high risk activity and travelling by aeroplane would need either very expensive (vastly more expensive than currently) life assurance or a total lack of concern for one's dependents.
So some people developing software are engineers. Or at least let's hope they are!
And of course fly-by-wire software in military aircraft requires extremely good engineering too, as do ATC systems, automatic aiming systems, and so on.
The cost of having serious engineering practised in these cases is far ouweighed by the cost of not doing so.
Tom
December 21, 2015 at 6:48 am
TomThomson (12/19/2015)
jshahan (12/10/2015)
I'm in agreement with those that say we are not engineers. However to those that say we should have the same standards or disciplines as those who design cruise ships and high-rises, I would ask what effect that would have on development costs.Well, if the fly-by-wire software in commercial passenger aircraft were not engineered to that standard living anywhere near an airport or under a flight path would be a high risk activity and travelling by aeroplane would need either very expensive (vastly more expensive than currently) life assurance or a total lack of concern for one's dependents.
So some people developing software are engineers. Or at least let's hope they are!
And of course fly-by-wire software in military aircraft requires extremely good engineering too, as do ATC systems, automatic aiming systems, and so on.
The cost of having serious engineering practised in these cases is far ouweighed by the cost of not doing so.
Any mission critical or life-critical system naturally must be tested and hammered insanely hard before anyone risks their lives on it. Even then, good luck finding all the bugs before something dire happens. If I'm not mistaken there were problems with the F-15, F-16, F-22, and F-35 flight software--which is particularly scary in the F-16's case as it literally can't be controlled without the computer.
Having said that, take a look at the cost of said software, it's a huge percentage of the overall budget and often times the bottleneck time-wise.
And even now, after everything they did (and they by God moved heaven and earth!) no doubt there are still serious bugs lurking in that software that under the proper circumstances will cause the plane to crash and kill the pilot.
Do you want to pay 3 billion dollars for an accounting system? I wouldn't mind seeing that level of engineering done on crypto security (assuming the software could be spread across all humans, reducing its cost) but then again we can't trust governments not to meddle in various ways, so anyone who could afford that level of development can't be trusted with it.
And so it goes. Development is a craft, not an engineering discipline precisely because A) it's all custom written for small audiences and B) most of it isn't life-threatening if it fails and C) it has to be affordable on extremely limited budgets.
Good, fast, and cheap, pick any two...
That isn't to say craftsmen don't have best practices, known best principles, and so on. We do. That isn't to say that *well written* software doesn't follow KISS, clarity, and other requirements, because it does.
However, as with any profession (including engineering) there are going to be MANY more appretice-level practitioners than masters--and there are REASONS this is so.
Certification in our industry is a bad joke. It lines the pockets of the cynical or the pockets of very people who create the software you're certifying for. There can't be a generic certification because our profession is all about "jack of all trades, master of none".
I can't see that changing.
December 21, 2015 at 7:43 am
roger.plowman (12/21/2015)
Good, fast, and cheap, pick any two...
Always include "Good". Fast and cheap usually follow auto-magically.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2015 at 9:55 am
Jeff Moden (12/21/2015)
roger.plowman (12/21/2015)
Good, fast, and cheap, pick any two...Always include "Good". Fast and cheap usually follow auto-magically.
I wish. Good and fast (delivered) isn't cheap, good and cheap isn't fast (delivered)
December 21, 2015 at 10:45 am
roger.plowman (12/21/2015)
I wish. Good and fast (delivered) isn't cheap, good and cheap isn't fast (delivered)
True but I like Jeff's point, always shoot for good. Client satisfaction follows, leave it out at your peril.
December 21, 2015 at 11:28 am
GeorgeCopeland (12/21/2015)
roger.plowman (12/21/2015)
I wish. Good and fast (delivered) isn't cheap, good and cheap isn't fast (delivered)True but I like Jeff's point, always shoot for good. Client satisfaction follows, leave it out at your peril.
Good enough is often what most clients really want not perfection.
Viewing 15 posts - 46 through 60 (of 67 total)
You must be logged in to reply to this topic. Login to reply