Sign in / up

back to article It's a decade since DevOps became a 'thing' – and people still don't know what it means

To everyone with DevOps in their job title (and a quick LinkedIn search turned up 45,597 of you just in my network): folks, you're doing it wrong. To every employer looking to fill positions like "DevOps engineer" (and there are plenty): you, too, are miserably misguided. As it turns out, DevOps isn't "a job title, a software …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *

Page:

  1. Anonymous Coward
    Anonymous Coward

    DevOps is still snake oil

    that is easy to slip up on by the unwary.

    It also means that anyone brave enough to say 'I'm an expert' will get heaps of shit heading in their direction because the snake oil salesman promised that it is the answer to life, the universe and untold riches.

    Sceptic? I still am and treat it as a septic tank. Good stuff goes in and only smelly stuff comes out.

    The optomist in me says that one day it will all work and the roads will be paved with gold.

    33 7 Reply
    1. CheesyTheClown
      Reply Icon

      Re: DevOps is still snake oil

      I disagree, DevOps has worked for 30+ years a lot better than modern IT has.

      You buy a platform instead of building one. That means mainframe, private cloud etc... you the hire developers who build your business software to run on that platform or buy software made specifically for that platform. This is what banks do. Then, operations operates the mainframe and works with the developers to apply system updates that may contain breaks.

      This system works absolutely damn near perfect and cuts IT spending to almost zero.

      What DevOps were you thinking of?

      6 10 Reply
      1. 1Rafayal
        Reply Icon

        Re: DevOps is still snake oil

        Devops is simply making developers own their own work as opposed to them picking up tickets and checking in code. It also gives them a level of ownership over how their applications are deployed and how their infrastructure is built etc.

        Thats pretty much it.

        The rest of it, the conferences, the books etc, you dont need it. Anyone who says they dont need any devops software is lying to themselves - you think you can get away with no SCM? Or a build server? Or something like a Jira?

        5 3 Reply
      2. Gene Cash Silver badge
        Reply Icon

        Re: DevOps is still snake oil

        > This is what banks do

        Banks? Like the ones that are having constant unplanned outages?

        9 0 Reply
        1. Doctor Syntax Silver badge
          Reply Icon

          Re: DevOps is still snake oil

          "> This is what banks used to do

          Banks? Like the ones that are having constant unplanned outages?"

          Better?

          2 0 Reply
    2. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: DevOps is still snake oil

      A cynic might think that the current buzz around DevOps is really about circumventing "least privilege" access control policies, increasing workload of devs for no more money and de-skilling ops staff, whilst also giving a marketing buzz to vendors who want to peddle more stuff to solve the problems of removing privilege separation, increasing workload and de-skilling staff.

      18 0 Reply
    3. Daniel von Asmuth
      Reply Icon
      Go

      Re: DevOps is still snake oil

      "DevOps is not a skillset and it's not a toolset: it's a mindset."

      That is why your company should certainly sell, DevOps, Cloud As A Service etc. and refrain from buying any.

      The optometrist to me says that all this vague cloudiness can be resolved by buying a new pair of spectacles and then I shall clearly see.

      5 0 Reply
    4. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: DevOps is still snake oil

      Company IT heads convene for meeting one day...

      "Let's move to the cloud next week, that bloke from the consultancy said it was easy! We can cut Ops to zero and Devs to almost nothing, outsource everything. I mean the cloud is magic right? We'll save bucket loads of money in IT and we can blame everyone else when things blow up! It's win-win!"

      Next steps....

      Handful of bright, development minded Ops get to stay on so long as they promise to renounce their bad old ways of sysadmin, join the dark side and become 75% development skilled.

      Devs that are left are automatically given full sysadmin privs over systems they're responsible for. Devs are now promoted to Senior Dev positions and get to lord it up over the cowering menial Ops who are now second-class citizens of the new world order and should be damned grateful they still have jobs from their benevolent dev overlords!

      0 0 Reply
    5. phuzz Silver badge
      Reply Icon

      Re: DevOps is still snake oil

      I love the way that every reply in this thread has different ideas of what devops means, and most of them disagree.

      Sums it all up really.

      5 0 Reply
  2. Anonymous Coward
    Anonymous Coward

    Yawn...

    ...do these people have a real job? Would they be able to do it?

    DevOps is simply something that happens when developers automate the installation of software, traditionally by creating VMs in AWS.

    And lo: there were books. And conferences. And Gurus.

    26 2 Reply
    1. Yet Another Anonymous coward Silver badge
      Reply Icon

      Re: Yawn...

      I thought dev ops meant developing and testing on the production servers ?

      24 1 Reply
      1. TRT Silver badge
        Reply Icon

        Re: Yawn...

        I thought it meant single-person software companies.

        8 0 Reply
        1. Anonymous Coward
          Reply Icon
          Anonymous Coward

          Re: Yawn...

          I thought it meant developers who were co-opted into doing sys admin and DBA work (or vice verca) because the company they're working for is too tight to hire enough staff.

          21 0 Reply
    2. Steve Davies 3 Silver badge
      Reply Icon

      Re: traditionally by creating VMs in AWS.

      And before AWS, the world didn't exist?

      Seriously, what did we do before AWS/Azure?

      BC seems to mean Before Cloud to an awful lot of peole these days.

      14 0 Reply
    3. CheesyTheClown
      Reply Icon

      Re: Yawn...

      Not even close. VMs exist mainly because software developers don’t have access to a stable platform to design against. As such, they set a bunch of requirements for all kinds of systems which traditionally required more servers... which required IT people to build from a list of requirements... who then virtualized them.

      In a DevOps environment, there’s no need for VMs because the platform is probably fully distributed using technologies like Redis for example. Table stores are favored over traditional SQL servers. Object storage is available without the need for file servers. As such, we develop software towards a platform which is triggered by timers and HTTP servers.

      When you don’t have DevOps, you have IT guys and generally absolute shitty platforms which are closer to super computers than business systems. When you have DevOps, you can dump shit like software defined data centers. You don’t need virtual machines or containers. You don’t care about x86 vs ARM.

      So.... nope... not even close. DevOps is about a system wher developers and operators develop and operate business systems without the chaos and madness you would generally find with IT people involved.

      We’re currently replacing about $20 million of data center equipment and about 150 IT people with some Raspberry PIs and a dozen programmers. All the crap that has to be VMs like AD, e-mail and collaboration is going cloud. All the business software will be developed in-house. We have done initial testing and have proven that security, agility and performance is substantially higher this way.

      2 25 Reply
      1. elip
        Reply Icon

        Re: Yawn...

        "...you don’t care about x86 vs ARM." <--- Spoken like a true developer.

        6 0 Reply
        1. CheesyTheClown
          Reply Icon

          Re: Yawn...

          Isn't it nice?

          It's awesome to be in a world where you can have developers on staff who... if the code is slow will work with the DBA to make it better.

          Imagine a world where the operators would see 90% CPU usage and be able to discuss with the developers what was going on and work together to identify whether it was bad code, an anomaly, etc... and then correct the problem? This generally happens because code which was originally intended for batch processing is reused without optimization for transaction processing. So, instead of being run once a night or hour, it instead is run a million times a minute. So, we then optimize queries and cache data if necessary and make sure the database is sharding the hot data where needed.

          If you're not pissing away $1.9 million for :

          - 6x Rack servers with 20 cores each, 256GB RAM each and 16 enterprise SSD drives

          - 4 leaf switches, 4 spine switches, 4 data center interconnect switches plus all the 40Gb cable

          - 2 dark fibers with CWDM for DCI

          - VMware Cloud Foundation with NSX, vSAN, ESX/vSphere

          - Windows Server Enterprise 2016

          Which is pretty much the lowest end configuration you would ever want to run for a DIY data center...

          You can instead spend the money on things like making software which really doesn't need systems like that. Run your generic crap in the cloud. Build your custom stuff to run locally. And keep in mind that the developers are able to run their systems on 10 year old laptops while they're coding. But the good news is that by dumping the data center and the staff to run it, they can now have new laptops and a better coffee machine. :)

          2 0 Reply
      2. Anonymous Coward
        Reply Icon
        Anonymous Coward

        @CheesyTheClown

        "We’re currently replacing about $20 million of data center equipment and about 150 IT people with some Raspberry PIs and a dozen programmers."

        I hate to be the one to break the news to you sunshine, but if thats true (I have my doubts) then most of your department about to be outsourced. I'd get your CV sorted out ASAP if I were you.

        12 0 Reply
        1. CheesyTheClown
          Reply Icon

          Re: @CheesyTheClown

          I'm the software architect. Pretty sure my team is safe.

          I hope to be eventually outsourced. It would mean we did such a good job that the system won't require having us around.

          My next career is biotechnology. I hope to obsolete myself in the next 3-5 years while studying to enter my new field. I'm hoping to move on to making a medical device for imaging the inner ear of a human and possibly using ultrasound to perform some basic procedures related to balance issues.

          I do really appreciate the concern though. It is very kind of you :)

          0 1 Reply
      3. Dagg Silver badge
        Reply Icon
        Mushroom

        Re: Yawn...

        DevOps is about a system wher developers and operators develop and operate business systems without the chaos and madness you would generally find with IT people involved.

        You what! I've seen this too many times in the past. Wildcat changes directly into a product system stuffing up the whole thing.

        Users complaining because everything they go to use the system it has changed and they end up carrying out the UAT.

        1 0 Reply
      4. Not That Andrew
        Reply Icon

        Re: You don’t care about x86 vs ARM

        This video might be of interest https://www.youtube.com/watch?v=b2F-DItXtZs.

        0 0 Reply
    4. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: ...do these people have a real job?

      Hmmm.

      Anyone else noticed who wrote this article?

      His employment history is still up and visible on LinkedIn. You'll have seen him round here intermittently too, though maybe not as memorably as Steve Bong.

      Spot many real jobs, or is it more about... well... lots of evangelising and PR stuff?

      0 0 Reply
  3. Matthew Brasier

    Every time a customer of mine says they do devops I ask the developers how they are getting on with being paged at 4am to support the system. They always look horrified and tell me they don't have pagers because the operations team do that. They aren't happy when I say they aren't doing DevOps then - a key feedback look of DevOps is that developers feel the pain of operational support, resulting in them putting in more effort to make sure that issues are properly resolved and the system is reliable and stable.

    32 0 Reply
    1. Czrly
      Reply Icon

      No Thanks!

      And, consequently, the company saves money by getting rid of all those operations teams and the developers quit because they're never not working, having to be developing during the day and fixing some bug that's 99% caused by something entirely outside their control (like a patch to a dependency or OS component or the simple fact that some other muppet pulled out a vital cable and tanked their services).

      As a developer, I'm quite prepared to say: "No thanks!" to that. There's a reason why operations are operations and I'm development. They don't have a clue about heaps and stacks and memory and how interlocked synchronisation primitives really work or how to design an indexed relational SQL database so that it doesn't crawl under real-life loads. I don't have patience to fix stuff broken by other people in the wee hours of the morning.

      As a developer, I'm also quite prepared to write extraordinarily good tests and to implement a good workflow for my team, complete with continuous integration and staging environments and automated rollouts and all that other stuff. Not because it's DevOps (TM) but because those things just make sense when you're running a large team and some of the team members aren't all that experienced.

      I'll never call what I do "DevOps", though. Just like I don't use hashtags.

      23 3 Reply
      1. bombastic bob Silver badge
        Reply Icon
        Devil

        Re: No Thanks!

        I heard about a study that was done regarding programmers and their work environments. There are several "deal breakers" that would force a programmer to quit (or not take the job), things like having a PHONE RING all of the time (and having to answer it).

        I don't recall anything else specific. but here's a list of things that I would consider "deal breakers":

        a) having to answer a phone while at the office

        b) having to carry a pager (so you're always "on call")

        c) 'too many cooks in the kitchen' (bad project management)

        d) unclear objectives and/or requirements, particularly if they CHANGE a lot

        e) too much "feeling" goin' on. nauseating, yeah

        f) consistently NOT giving me the access I need to get my work done

        g) company politics [in any form]

        h) being forced to give unrealistic estimates (and then LIVE by them)

        i) being in an "open office" (rather than "your own office" or a VERY private cube). that includes offices with cubes that have 3 foot walls, aka "a fish bowl". (whereas sharing an office with 1 or 2 other people is fine)

        So if 'DevOps' means that you MUST be "operations" (on call, open office, dealing with users/customers) as well as "development", then I think it's a model for FAIL. Because the personality of creative programming types (the good ones, specifically) isn't well suited to the 'customer service technician' requirement.

        11 1 Reply
        1. AdamWill
          Reply Icon

          Re: No Thanks!

          I think a nuance being missed here is that devops isn't really appropriate for all scenarios. As the article - which is actually really good! - explains, it really originated in *one specific* area: the provision of hosted web services at large scale.

          If you think about it, this area has some attributes that others really don't. Most importantly for my argument here, it doesn't involve "releases" to "customers", exactly. No-one thinks in terms of "deploying Facebook 5.6". They just go to Facebook. There isn't a clear "you are a customer of BobCorp running BobSoft 3.4" relationship going on there. Also, there is - to a reasonable approximation - only *one* Facebook. There aren't 50,000 Facebook deployments in the world, with 50,000 on-site Facebook admins who each have their own concerns that might affect when they want to deploy Facebook 5.6.

          If you're dealing with *this specific model* - where there's only a very small number of deployments of the codebase you're working on, and your organization has a high degree of control over them - full-fat devops, fully understood, makes an awful lot of sense. It would be rather silly for Facebook to have a Facebook Development Team cutting conventional releases of the Facebook Software, and an entirely separate ops team deploying and maintaining a Facebook Deployment using the Facebook Software. *It's all one thing*.

          I think a lot of the cognitive dissonance and misunderstanding comes from people working in very different contexts not recognizing that that's what they're doing. You can't really reasonably apply the full set of devops practices if you're not working for Facebook but for BobCorp, where you deal with those 50,000 customer admins of BobSoft deployments, because *you at BobCorp don't actually do the 'ops' part*. Your customers do. So if this is your situation, naturally devops is going to seem like bullshit to you.

          Then there's the more complex cases - like maybe BobCorp has its own internal deployment of BobSoft. Should BobCorp follow devops principles for its own deployment, but also have a process for cutting releases and supporting external customers with conventional releases? Or should it treat its own internal deployment as just another customer?

          Bottom line, devops only really works/makes sense when there can be a single process with control over all the significant deployments of the software being developed, and the development of the software can be integrated into that process such that you can have a very high degree of confidence that any code which passes the commit tests can be sent out to all those significant deployments immediately and will not break anything.

          11 0 Reply
    2. CheesyTheClown
      Reply Icon

      Nope.

      How can so few people know what DevOps is? We’ve used it in banks since the late 60s and it’s been pretty stable since the 80s.

      Of course, it is clear you don’t know what it is either. It has absolutely nothing to do with developers being operators. And yes there are still occasionally 4am calls, but ask the mainframe operators at banks how often that occurs.

      2 6 Reply
      1. Naselus
        Reply Icon

        Re: Nope.

        "How can so few people know what DevOps is? We’ve used it in banks since the late 60s and it’s been pretty stable since the 80s."

        Given you're literally the only person in the world who thinks DevOps has existed since the late 1960s, and the definitions you've offered for it thus far are completely at odds with those offered by any of the actual practitioners, I suspect you might just have no idea what DevOps is either.

        9 1 Reply
        1. CheesyTheClown
          Reply Icon

          Re: Nope.

          haha What do you classify as a practitioner?

          I know a lot of practitioners as well, and DevOps is the current name of the evolution of business software development, operations and process management. It's not new. We learn as we go and we improve. DevOps has nothing to do with writing software to perform the IT departments job. It has nothing to do with automating things like virtual machines and containers. It has nothing to do with any of that. It has to do with operations and development working together to ensure there is a stable and maintainable platform to build and maintain stable software against through proven test driven development techniques.

          Software defined and automation and all that crap has nothing to do with DevOps. You could of course use those things as part of the DevOps process.

          The goal is to not need all the IT stuff to keep things running. You should be 100% focused on information systems instead. Start with a stack and maintain the stack. A stack is not about VMs and containers. It's about a few simple things :

          - Input (web server)

          - Broker (what code should be run based on the input)

          - Processes (the code which is run)

          - Storage (SQL, NoSQL, Logging...)

          There are many different ways to provide this. One solution would be for example AWS, another is Azure and Azure Stack. You can also build your own. But in reality, there are many stacks already out there and there's no value in building new ones all the time. As such, while the stack vendor may employ things like automation and kubernets and docker and such, they're irrelevant.

          What we want is :

          - The ability to build code

          - The ability to test code

          - The ability to monitor code

          - The ability to work entirely transactionally

          Modern DevOps environments are just a logical progression on classic mainframe development to include things like build servers, collaborative code management, revision control, etc... it's also adding an additional role which used to be entirely owned by the DBA which goes further to ensure that as the platform progresses, operations, DBA and development work as a group so that we reduce the number of surprises.

          Of course, you may know more about this than me.

          5 0 Reply
      2. Jonathan Schwatrz
        Reply Icon
        Happy

        Re: CheesyTheClown Re: Nope.

        "How can so few people know what DevOps is?...." Well, obviously, because it's a relatively new buzzword for a lot of old techniques that had to be re-"discovered" so that people could make money flogging those old techniques again under a new name.

        10 1 Reply
    3. Paul Hovnanian Silver badge
      Reply Icon

      "I ask the developers how they are getting on with being paged at 4am to support the system."

      Been there, done that. Specifically for aircraft functional tests. When the automated test fails, we aren't sure whether it is the aircraft system under test, the test hardware, software, test requirements or whatever. So everyone gets paged.

      We started with a system built by our information systems people. Who couldn't be buggered to get their [censored] down to the factory when things went wrong. Worse yet, IS management was always looking for ways to export this task to someplace like India. So we (engineering) booted them out and took over their tasks. Now we had one person who would answer to the hardware/software/requirements issue. And the factory (and FAA) loved us for it.

      9 0 Reply
      1. Jonathan Schwatrz
        Reply Icon
        Go

        Re: Paul Hovnanian

        ".....When the automated test fails, we aren't sure whether it is the aircraft system under test, the test hardware, software, test requirements or whatever. So everyone gets paged....." LOL, that rings a bell! had an "agile" project where the developers had to deliver to fortnightly sprints, then they would go home on Friday evening and switch off their phones prior to the latest release being loaded into production - and falling over - at 2am Sunday morning. They simply got so far on the Friday afternoon and then couldn't be arsed to fix anything else, so simply fudged their testing to get the release out the door in the knowledge it would be Ops problem after 5pm Friday. Quality of code increased massively when I insisted ALL developers had to be available to help troubleshooting at 2am every Sunday. That was several years before "DevOps" suddenly became the fad of the week.

        5 1 Reply
  4. Hans 1

    Old-school vendors like BMC are much worse. For example, BMC's site is a mishmash of meaningless buzzwords, all targeted towards "your DevOps team". CA Technologies, for its part, waxes lyrical about its "DevOps solutions" and how they help to "redefine culture" around DevOps. Finally IBM lumbers toward a "Cloud Garage Method".

    Thanks, made my day ... BMC are really an easy target for us ;-)

    3 0 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Cloud Garage Method? They have those flying cars we keep hearing about at IBM?

      2 0 Reply
      1. Doctor Syntax Silver badge
        Reply Icon

        "Cloud Garage Method? They have those flying cars we keep hearing about at IBM?"

        No, they have a random word string assembly system.

        0 0 Reply
  5. Hans 1

    DevOps is way you organize work

    Unless you have a system already in place that is not devops and that allows you to release frequently and early, test always, and have automated to hell and back, well done, you, sir (or madam) have earned the right to bash DevOps.

    However, if you have not, you are like all those car manufacturers with mechanics walking miles to get nuts, bolts, screws and parts here and there in the factory laughing at Ford's assembly line.

    No, you do not need paid for tools for this, you can do it yourself with FOSS.... yes, some DevOps evangelists come with their philosophy, voodoo BS and rules etc ... the thing is, the world is moving fast, your competitors are building those DEV assembly lines, streamlining development, test, and release cycles ... DevOps is a way to achieve that, you do not have to embrace the whole "philosophy" to make it work for you ... one of the central points of DevOps is: "Change is beautiful, if it makes a difference!"

    Now, I mentioned dev, test, and release cycles, but you can adapt it to other areas of business .... what most C-types do not realize is that IT is not a cost center, imagine if you could streamline the period close or other financial processes ... most of the time, that will save you a lot of cash ... there are paid for solutions out there that do just that ... or imagine, SAP system copy, a bloody nightmare, get some setting wrong and you can start again ... taking the DevOps methodology, you constantly improve your processes, again, no one tells you you have to go 100% agile and have a SCRUM master, not necessarily needed, you can achieve all these goals without. It does help to start off like that, though, imho ... YMMV

    6 5 Reply
    1. Doctor Syntax Silver badge
      Reply Icon

      Re: DevOps is way you organize work

      "No, you do not need paid for tools for this, you can do it yourself with FOSS"

      Of course you can't. Unless you're paying wedges for tools, lots and lots of consultancy and conferences (did you notice the bit at the bottom of TFA) you're not Doing It Right.

      2 0 Reply
    2. FatGerman
      Reply Icon

      Re: DevOps is way you organize work

      "Unless you have a system already in place that is not devops and that allows you to release frequently and early, test always, and have automated to hell and back, well done, you, sir (or madam) have earned the right to bash DevOps."

      I have created 3 such systems from scratch, 2 of them well before anyone had ever uttered the word 'DevOps'. My main failing as an engineer seems therefore to be that I simply regarded that as doing my fucking job properly, when I obviously should have been inventing buzzwords and holding conferences instead.

      4 0 Reply
  6. SVV

    Still not a thing you can instantly conjure up

    However years of experience of development plus configuration and administration of servers with good mentoring and advice from older more experienced folk and an eagerness to learn and put in the hard graft..... well that will give the required insight. A short cut to this level that's possible via undefined hypey hype? Put me in the "totally unconvinced" category.

    5 0 Reply
  7. Lysenko

    We all know what "Beta Test In Production" means...

    ... and labelling it DevOps won't change that.

    Shovel [redacted] as fast as possible down the continuous integration pipeline, pausing only to check it isn't toxic enough to trip the unit tests, then get your users to do your real QA, ask forgiveness rather than permission, then brag about your mean time to remediate metrics? Get the Devs to configure AWS security because Ops isn't a specialism we need any more?

    Unfortunately, we know exactly what DevOps means.

    14 0 Reply
  8. Rich 2 Silver badge

    Oh dear

    "developers need to think about the stability of the product as just as important as the features"

    Soooo....

    It's about doing your job properly then?

    You may have guessed that I'm rather cynical about this sort of stuff. Along with Agile and eXtreme (bloody stupid name). Whenever I hear any of these names I think of spotty youths who can't be bothered to actually design something right the first time round and cirtainly can't be arsed to document anything.

    And even if I get over my cynicism for a moment, it all assumes that the system you're working on can tolerate a half baked broken change. I've never worked on anything that can be anything other than working perfectly. You might get away with it on faecesbook or some such but contrary to what many seem to believe, not all software is related to running a web site. And your fancy DevOps etc often doesn't work in other environments

    17 2 Reply
    1. Rich 2 Silver badge
      Reply Icon

      Re: Oh dear

      In the interest of educating myself, can someone please explain who the "Ops" person/people are and why they might find it acceptable to be provided with (say) a super new software build from the "Dev" people that might be broken ("never mind the quality. feel the width") for a...

      A/ Critical satellite comms system

      B/ A heart monitor

      C/ A railway signalling system

      Just curious

      9 0 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: Oh dear

        You can add

        4) Railway and Air Traffic Control Systems

        I would not want to test beta software in production when mistakes could mean that planes fall out of the sky. (I have developled ATC system and the rigour of testing, testing and retesting before you get anywhere near production is just part of the culture and it seems to work)

        Which leads to

        5) Any safety critical system.

        10 0 Reply
      2. rnturn
        Reply Icon

        Re: Oh dear

        Web sites seem to be all that matter nowadays.

        1 0 Reply
  9. Mr Dogshit
    Paris Hilton

    Having read the article

    I'm still none the wiser. Still don't understand why programmers are called "developers" either. Surely a developer was the person behind the counter at Boots who processed my 35mm film?

    15 1 Reply
    1. Zot
      Reply Icon

      Re: Having read the article

      ”Developers?” Yeah, it took me awhile to stop laughing at “engineer” as a term for a programmer, apparently it was because it “sounded better”. Haha, kids hey...

      5 1 Reply
      1. Franco
        Reply Icon

        Re: Having read the article

        That takes me back to my University days, someone queried why a course in "Computer Science" was teaching "Software Engineering" (I am well aware of the vagueness of those terms in the real world, hence the inverted commas). We were told that we could be taught engineering principles in the software course, but we would be classified as scientists at the degree level because of professional bodies such as the IEEE being very protective of the term engineer.

        Microsoft hit the same thing with the original MCSE certification hence why it's now Solutions Expert rather than Systems Engineer.

        4 0 Reply
        1. kjw
          Reply Icon

          Re: Having read the article

          Some countries have laws about the term engineer which could also explain why a global company like Microsoft would shy away from casual use.

          1 0 Reply
      2. JohnFen
        Reply Icon

        Re: Having read the article

        "it took me awhile to stop laughing at “engineer” as a term for a programmer, apparently it was because it “sounded better”"

        I'm old enough to remember when "computer programmer" and "software engineer" were different jobs with precise definitions. I guess those days are long gone.

        5 0 Reply
      3. Dagg Silver badge
        Reply Icon

        Re: Having read the article

        ”Developers?” Yeah, it took me awhile to stop laughing at “engineer” as a term for a programmer, apparently it was because it “sounded better”. Haha, kids hey...

        Wrong, as one who has worked as a software engineer we worked in a engineering environment along side the electrical, hardware and mechanical engineers on industrial process control systems. We used exactly the same processes and discipline as all the other engineers.

        We needed to, our software was controlling some extremely expensive, dangerous plant.

        1 0 Reply

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like