December 9, 2015 at 8:51 pm
Comments posted to this topic are about the item Are We Engineers?
December 9, 2015 at 11:27 pm
From the Article:
Engineering is defined as: the work of designing and creating large structures (such as roads and bridges) or new products or systems by using scientific methods. By that definition, I think we are engineers.
No... I don't believe that most Developers/DBAs are Engineers no matter how skilled they may be at their trade. I think that most true Engineers would either be insulted or have a good laugh about it if we started calling ourselves "Engineers". Yes, it's true that many use the "Scientific Method" and have a pretty deep knowledge of our trade but I wouldn't call myself an "Engineer". Well versed and highly knowledgeable super user maybe , but not an Engineer.
Folks like Paul Randal, Kimberly Tripp, and Itzik Ben-Gan... yes... Engineers. They're the exception rather than the rule, though. The rest of us (not including most of the people I've interviewed in the last decade in that) are just highly educated users at best.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2015 at 12:25 am
I have wanted our industry to be "certified and regulated" every since I was a couple of years in and could understand how shockingly bad some people are and are continually allowed to be. It is also the volume of incompetence. Many of these people are not incompetent themselves but are the sort that do so little because so little is asked of them.
Will it change? No. 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". There are even bodies in place to be that regulatory body (in the UK we have the BCS, for example, although they might not be the best option).
Is it a silver bullet? Of course not. Would it force people to raise their game? I am certain many would comply and for a lot that would be an improvement. Would we lose some very good practitioners? Probably but nowhere near the amount of shonkey ones!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 10, 2015 at 12:37 am
engineer (n.): a person who designs, builds, or maintains engines, machines, or public works.
Well.....SQL Server does have an engine, so....
December 10, 2015 at 12:55 am
No we are not engineers also data scientists are not scientists if you look at the definition of a scientist 🙂
December 10, 2015 at 1:13 am
I am a chartered engineer and SQL developer. Previously I have done "software engineering" and real-time systems development. There is no, fundamental, reason why people who work in this industry cannot be engineers but, the reality is, most are not.
There are many disciplines involved in 'doing' engineering that are applicable in SQL development, database administration etc. To mention just three - formal design, documentation of work and specification. How many SQL developers just dive in to a major job with spending any time going through a design process before they start? The 'nature of the beast' means that you can get away with murder. Every system I have worked with just seems a mess to me, even ones supplied by software companies.
As for documentation - you will lucky if there is any. Recently my organisation bought a new application (against my advice). They want reports to be produced from data extracted from said application. I requested an ERD and a data-dictionary but they did not have either. They said it was a good idea and they "might put them together in the future." As an engineer, I would not be allowed to produce anything without documenting it properly but these people are selling undocumented products.
The last bit is one of the worst aspects I have found working in this sector. The clients seem to have an expectation that they can get their requirements without a proper specification process. There are several reasons for this, which I will not list here, but all are symptoms of a general lax approach, especially by coders and development management.
The industry has a bad reputation for delivery and much of this can be put down to their not running it in an 'engineering' way. So, there is no fundamental reason why people who work in this industry cannot be engineers but most are just not interested in working like one.
December 10, 2015 at 2:48 am
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".
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 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.
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.....
December 10, 2015 at 3:24 am
nicksamuel (12/10/2015)
...There are several reasons for this, which I will not list here, but all are symptoms of a general lax approach, especially by coders and development management...
I, for one, would suggest that the lax coders are doing so either under order or because they can i.e. raise the bar and most will either improve or leave the industry.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 10, 2015 at 3:53 am
No, we're not. We don't have the rigour, the formality, the adherence to standards that characterises engineering disciplines. The scientific method is not 'try stuff at random until something works', which is how way too many people code. We don't, as an industry, have an attitude of continual education, of 'standing on the shoulder of giants', of rigorous discipline.
Can you imagine a bridge being designed and built based on the latest cool, gee-wizz framework of the week, with an 'we if it doesn't work we can fix it later' attitude? Or with 'I want to do it myself, not use someone else's solution'?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 10, 2015 at 4:10 am
GilaMonster (12/10/2015)
No, we're not. We don't have the rigour, the formality, the adherence to standards that characterises engineering disciplines. The scientific method is not 'try stuff at random until something works', which is how way too many people code. We don't, as an industry, have an attitude of continual education, of 'standing on the shoulder of giants'.Can you imagine a bridge being designed and built based on the latest cool, gee-wizz framework of the week, with an 'we if it doesn't work we can fix it later' attitude? Or with 'I want to do it myself, not use someone else's solution'?
I think nowadays it is more "try stuff that you pick off stackoverflow at random until it works" 🙂
December 10, 2015 at 4:53 am
This thread, albeit not yet very long, leads me to think that this editorial's title really should be:
Should we be engineers?
For me the answer is "Yes". Obviously.
(Depends on what we are doing really but on the whole I think that the majority of roles should be engineering.)
That Steve fella' does this to us all the time. We pigeons fall for his cat throwing day in, day out.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 10, 2015 at 5:07 am
No, generally not engineers, in the formal sense. Although I've met and worked with a few s/w architects that I would consider engineers. I believe a few levels of s/w developers (and sysadmins) exist that could provide a pathway for becoming known as s/w engineers. I often speak of a simple model of developer > designer > architect. Only reaching the architect level would allow one to become known as a s/w engineer. An objective qualification for recognition could be developed for a s/w architect.
I believe most people working this industry are in the developer category, maybe 80%; then 18% or so at the designer level, with the remaining 2% at the architect level (maybe less). Architects and good designers can greatly enhance the ability of s/w solutions to solve business problems.
I think the term itself (s/w or software) is part of the problem here. Although it does not call out a particular platform or language, it hints at such. The architect deals in a level of abstraction to solve a problem with a computing device (chip, server, mobile device, switch, appliance, etc.) - it is hardware AND software at this level. Perhaps Systems Engineer or something of that nature would suffice in the I/T industry as it has in other disciplines.
Adrian
NCSU EE
December 10, 2015 at 6:23 am
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.
December 10, 2015 at 6:31 am
Programmers in general (and developers especially) are NOT "software engineers". We are craftspeople. Development is not an engineering discipline (for all it's based on mathematics) it's an art. Anyone who thinks differently is fooling themselves.
Steve nailed it when he pointed out everything we do is pretty much custom, one-off solutions. While there are certain minimal "standards" in coding (code clarity, KISS, elegance) and some naming conventions and the like nothing is standard because there is no standard language, there is no standard OS, there is no standard system, there is no standard anything.
Waterfall was the closest thing we ever had to an engineering discipline and look where that brought us.
Engineering proper deals with well-defined domains. The rules for bridge construction, while complex mathematically, are at least well-defined and well-understood. It is a limited, sharply defined problem. Same with factories, cars, aircraft, *spacecraft* and every other material object that's designed.
Software, on the other hand, isn't. The domain is not sharply defined, the interactions are not sharply defined, they are not limited and they tend to multiply like rabbits over time.
As long as users demand ever increasing complexity and don't give us any time to work out the (nearly infinite) permutations of the code paths nothing will change.
And even if they did, it still won't be engineering.
December 10, 2015 at 6:33 am
My add to the conversation is that I see an engineer as someone who takes something apart, studies the pieces, modifies them as required, then puts the pieces back together, with the intent of the something being better now than it was before. This could be an actual thing, as in mechanical engineering or a process, as in industrial engineering or operations research.
Gary Varga hit the nail on the head - "Should we be?"
I took Steve's comments personally. I absolutely believe that the more I adhere to an engineer's mindset and operate within Gail's brief description above, the more successful I will be as a Solution Developer.
Are there any evangelists banging the drum for us SQL-types behaving as engineers?
Viewing 15 posts - 1 through 15 (of 67 total)
You must be logged in to reply to this topic. Login to reply