3 ms·

It puzzles me why some insist on being called "Software Engineers", yet don't invest in automated, repeatable practices (i.e. true Engineering). By all means,

It puzzles me why some insist on being called "Software Engineers", yet don't invest in automated, repeatable practices (i.e. true Engineering). By all means, take risks and explore Software. But do it under the premise of Software Development if Engineering practices will not be applied. In agile environments, push for more "spikes" if estimates cannot reliably be provided for a story.

jerf 10y ago
"invest in automated, repeatable practices (i.e. true Engineering)." We do. We call those "libraries". We have more of them than most disciplines could dream of, and they work better than most disciplines could dream of. So where most disciplines are taking the closest things to libraries they have and still applying a lot of drudge work to put them into the current context, with "unexpected work" forming small single digit percentages of the work, we get to yank all the easy drudge work off the shelf and the resulting "unexpected work" makes up the majority of what we're doing. I'm not going to pretend everything is perfect in the land of software engineering, but the answer to "why are we so stupid that we don't do the obvious thing that people have been complaining about for 50 years now?" is that we aren't that stupid. We are very good at shrinking the obvious, easy parts of the problem down, so all that's left is the hard part. Which, since everything isn't hunky dory in the world of software engineering, we also often add to with self-inflicted injuries. Still, the amount of off-the-shelf crap that I can just push a button and have staggers the mind. If "real engineering" worked like computer science, we'd be down to a guy pointing and five minutes of fiddling with his phone to lay a bridge down across the average river, four minutes of which would be rebuilding the bridge in various different aesthetic styles to see which suited the location best. "Do I like the fake aged wood look, or do I go with modernistic concrete? Let's see the wooden one again...." Your homework is to write "hello world" in your favorite language and step through the resulting program in gdb or equivalent, starting from the moment the OS turns control over to the program, one assembler instruction at a time. I apologize if this comes off a touch crabby, though upon re-reading I'm not sure exactly what to tone down about it. I'm getting really tired of the inferiority complex programmers have about "real engineering". Yes, we do real engineering. If other engineers had the advantages we had, they'd be much more "agile", and they'd make the same messes we do. They work the way they do because of the constraints they have on them, for exactly the same reason the space programmers work the way they do and for exactly the same reasons it would be wildly inappropriate for all of us to work the same way NASA does all the time.
- jcrites 10y ago
  Great points! One other remark I'll share about software engineering is that the amount of engineering rigor required or warranted depends a lot upon the task and problem. If I'm building a back-office website for a few colleagues, I may not invest the same rigor as if I'm building a website that will be accessed by hundreds of millions of people. Many software tasks do not require great rigor: you add rigor until the incremental benefit is less than the incremental cost. As a result, I would guess that the average software engineering task is less rigorous than the average real-world engineering task, but that's only because real-world engineering frequently risks or protect lives. Even the tire rope swing, the hammock, and the treehouse put lives at risk if built poorly. The back-office website on average does not. Business might be disrupted or individuals might be inconvenienced, but typically no one can die. Yet, many types of software involve just as much rigor if not more as other engineering disciplines. For an example, read "They Write the Right Stuff", a story of NASA avionics software engineers [0]. I consider software engineering to be an engineering discipline because of the fact that rigor is required, and because a good engineer must know how much of it is appropriate, and be able to apply it effectively. A software engineer produces software to specified reliability and tolerances, according to requirements. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
- TheOtherHobbes 10y ago
  "Real engineering" does not mean building things. Real engineering means knowing how to model processes - so that when you actually do build something, your model gives you a strong signal ahead of time that it's going to do what you want. Engineering is not libraries or cook books: engineering is math. Civil engineers model buildings and other structures. Electronic engineers model circuit behaviours. Aerospace engineers model aerodynamics and materials. Traffic engineers model traffic flows. Stuff only gets built after a model appears to work. This is a good thing, because otherwise we'd be build bridges with rule of thumb and trial and error, and they'd fall down a lot, and kill people. Knowing the math makes it as easier to model a business case, complete with deadlines, as a process. Why isn't software engineering like this? It's not impossible to model software. It's just conceptually demanding, and very expensive. Professional software engineering doesn't look much like vanilla coding. The percentage of developers who can hack it - or could ever hack it - is not large. So we muddle along as a trade, not an engineering profession, hammering and gluing libraries together. The pay is still good, hardly anyone gets asked if they know what the ACM is in job interviews, and a lot of customers don't mind that much if a site only works in Safari and not in Chrome. (NB: actual experience I had with my online banking account last week.) It's true that being asked to estimate how long something will take may be met with a sharp intake of breath. But the reality is that very similar projects have usually been completed many times in other companies already, and the amount of truly unique and original R&D needed for most work need is miniscule.
ebbv 10y ago
You're offering a lot of derision without any useful information. If you've discovered the secret to repeatable, predictable software development, by all means please share it.
- matchagaucho 10y ago
  What I've discovered is that software is craft. Everyone progresses through phases of apprenticeship, journeyman, and master; with the art of "estimation" progressively improving. Yet when we call it Engineering, we hold ourselves accountable to a different set of expectations.
  - ebbv 10y ago
    Is that supposed to be insightful? The first part is obvious, the second part is nonsense. Neither offers a secret to repeatable, predictable software development. If you're going to make a fantastic claim that you can make software engineering time estimations reliable you should back that up with how you do that. Saying "I've been doing it for a long time and I call it engineering." Is not enough.
    - matchagaucho 10y ago
      Re-read my statements.You've missed the point.
ArkyBeagle 10y ago
Software people have dealt with nothing like the number of bodies buried under the Great Wall its engineers had. "Engineering" came from sappers, originally. Engineers work for insurers. For the moment, software engineers work for people other than insurers. I'm not quite ready to turn my culture over to the actuaries just yet.
dasil003 10y ago
You're not grokking the scope of "software engineering". Software itself is pure, arbitrary logic. Advances in microprocessors, networks, and storage has blown up the scope of what software can accomplishment to unfathomable scales. It's as if the humble hobbyist carpenter building a doghouse on the weekend had to know the intimate details of quarks, atoms, molecules, all the way up to the interaction of planets, star systems and galaxies, except without the immutable laws of physics, just layer upon layer of human-invented abstraction with no guarantee of universality. The blessing and the curse that makes software unique is that you get to make the rules, all of them. Let that sink in for a minute because if you look at all other engineering practices they are all based on the rigorous and immutable constraints they have to deal with. Any set of automated practices for producing software will only make sense for a tiny slice of software for which a set of constraints can be reasonably agreed upon.

jerf 10y ago

"invest in automated, repeatable practices (i.e. true Engineering)." We do. We call those "libraries". We have more of them than most disciplines could dream of, and they work better than most disciplines could dream of. So where most disciplines are taking the closest things to libraries they have and still applying a lot of drudge work to put them into the current context, with "unexpected work" forming small single digit percentages of the work, we get to yank all the easy drudge work off the shelf and the resulting "unexpected work" makes up the majority of what we're doing. I'm not going to pretend everything is perfect in the land of software engineering, but the answer to "why are we so stupid that we don't do the obvious thing that people have been complaining about for 50 years now?" is that we aren't that stupid. We are very good at shrinking the obvious, easy parts of the problem down, so all that's left is the hard part. Which, since everything isn't hunky dory in the world of software engineering, we also often add to with self-inflicted injuries. Still, the amount of off-the-shelf crap that I can just push a button and have staggers the mind. If "real engineering" worked like computer science, we'd be down to a guy pointing and five minutes of fiddling with his phone to lay a bridge down across the average river, four minutes of which would be rebuilding the bridge in various different aesthetic styles to see which suited the location best. "Do I like the fake aged wood look, or do I go with modernistic concrete? Let's see the wooden one again...." Your homework is to write "hello world" in your favorite language and step through the resulting program in gdb or equivalent, starting from the moment the OS turns control over to the program, one assembler instruction at a time. I apologize if this comes off a touch crabby, though upon re-reading I'm not sure exactly what to tone down about it. I'm getting really tired of the inferiority complex programmers have about "real engineering". Yes, we do real engineering. If other engineers had the advantages we had, they'd be much more "agile", and they'd make the same messes we do. They work the way they do because of the constraints they have on them, for exactly the same reason the space programmers work the way they do and for exactly the same reasons it would be wildly inappropriate for all of us to work the same way NASA does all the time.

jcrites 10y ago
Great points! One other remark I'll share about software engineering is that the amount of engineering rigor required or warranted depends a lot upon the task and problem. If I'm building a back-office website for a few colleagues, I may not invest the same rigor as if I'm building a website that will be accessed by hundreds of millions of people. Many software tasks do not require great rigor: you add rigor until the incremental benefit is less than the incremental cost. As a result, I would guess that the average software engineering task is less rigorous than the average real-world engineering task, but that's only because real-world engineering frequently risks or protect lives. Even the tire rope swing, the hammock, and the treehouse put lives at risk if built poorly. The back-office website on average does not. Business might be disrupted or individuals might be inconvenienced, but typically no one can die. Yet, many types of software involve just as much rigor if not more as other engineering disciplines. For an example, read "They Write the Right Stuff", a story of NASA avionics software engineers [0]. I consider software engineering to be an engineering discipline because of the fact that rigor is required, and because a good engineer must know how much of it is appropriate, and be able to apply it effectively. A software engineer produces software to specified reliability and tolerances, according to requirements. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
TheOtherHobbes 10y ago
"Real engineering" does not mean building things. Real engineering means knowing how to model processes - so that when you actually do build something, your model gives you a strong signal ahead of time that it's going to do what you want. Engineering is not libraries or cook books: engineering is math. Civil engineers model buildings and other structures. Electronic engineers model circuit behaviours. Aerospace engineers model aerodynamics and materials. Traffic engineers model traffic flows. Stuff only gets built after a model appears to work. This is a good thing, because otherwise we'd be build bridges with rule of thumb and trial and error, and they'd fall down a lot, and kill people. Knowing the math makes it as easier to model a business case, complete with deadlines, as a process. Why isn't software engineering like this? It's not impossible to model software. It's just conceptually demanding, and very expensive. Professional software engineering doesn't look much like vanilla coding. The percentage of developers who can hack it - or could ever hack it - is not large. So we muddle along as a trade, not an engineering profession, hammering and gluing libraries together. The pay is still good, hardly anyone gets asked if they know what the ACM is in job interviews, and a lot of customers don't mind that much if a site only works in Safari and not in Chrome. (NB: actual experience I had with my online banking account last week.) It's true that being asked to estimate how long something will take may be met with a sharp intake of breath. But the reality is that very similar projects have usually been completed many times in other companies already, and the amount of truly unique and original R&D needed for most work need is miniscule.

ebbv 10y ago

You're offering a lot of derision without any useful information. If you've discovered the secret to repeatable, predictable software development, by all means please share it.

matchagaucho 10y ago
What I've discovered is that software is craft. Everyone progresses through phases of apprenticeship, journeyman, and master; with the art of "estimation" progressively improving. Yet when we call it Engineering, we hold ourselves accountable to a different set of expectations.
- ebbv 10y ago
  Is that supposed to be insightful? The first part is obvious, the second part is nonsense. Neither offers a secret to repeatable, predictable software development. If you're going to make a fantastic claim that you can make software engineering time estimations reliable you should back that up with how you do that. Saying "I've been doing it for a long time and I call it engineering." Is not enough.
  - matchagaucho 10y ago
    Re-read my statements.You've missed the point.

ArkyBeagle 10y ago

Software people have dealt with nothing like the number of bodies buried under the Great Wall its engineers had. "Engineering" came from sappers, originally. Engineers work for insurers. For the moment, software engineers work for people other than insurers. I'm not quite ready to turn my culture over to the actuaries just yet.

dasil003 10y ago

You're not grokking the scope of "software engineering". Software itself is pure, arbitrary logic. Advances in microprocessors, networks, and storage has blown up the scope of what software can accomplishment to unfathomable scales. It's as if the humble hobbyist carpenter building a doghouse on the weekend had to know the intimate details of quarks, atoms, molecules, all the way up to the interaction of planets, star systems and galaxies, except without the immutable laws of physics, just layer upon layer of human-invented abstraction with no guarantee of universality. The blessing and the curse that makes software unique is that you get to make the rules, all of them. Let that sink in for a minute because if you look at all other engineering practices they are all based on the rigorous and immutable constraints they have to deal with. Any set of automated practices for producing software will only make sense for a tiny slice of software for which a set of constraints can be reasonably agreed upon.