SoylentNews is people
SoylentNews
The Atlantic is running an article on the friction between the computing world and Professional Engineer societies. This discussion has been going on for a long time, and is meaningful to me personally - I quit a 10-year career as server administrator with 'engineer' in my job title when I graduated with a Mechanical Engineering degree, and have since earned my Professional Engineer license. In a world where most software comes with a disclaimer of liability due to defects, where would an ethical, civic-minded programmer even practice Professional Engineering? Angry Birds probably doesn't have any responsibility to the public safety, so there's little need there; on the other hand, Google's self-driving car program is a good candidate.
I'd love to welcome the programming profession into the circle of licensed Engineers, provided that the industry manages to agree on standards of quality and accountability. I don't see the methods (such as Agile) used by programmers as a significant obstacle, either; the programming motto of "move fast and break things" (which the article wrongly decries) is echoed in the motto "fail early, fail often" that is held by many Mech Eng R&D shops. I just fear that the halting problem will be solved before any such standards become widely accepted and implemented in the industry.
(Score: 3, Informative) by CirclesInSand on Saturday November 07 2015, @03:49PM
I disagree with the "sometimes proof of correctness". Even though it is uncommon, I'd say that only those few software developers who use proof of correctness can be called engineers.
The standard of engineering is that an engineer knows his design will work before implementing it. Anyone who has to compile a program and run unit tests to see if it works isn't a software engineer. It would be like building a bridge, having someone drive over, and seeing if it crashes. No person who did that should call himself an engineer. The "hope and pray" method isn't good enough.
Software development is still a new field relative to fields with engineers, such as centuries old mechanical engineering or chemical engineering. It is too young for the majority to have the standards that engineers in other fields have to meet, everyone is still just trying to figure out what works. When formal verification becomes common, then there will really be justification for the title "software engineer". Until then, "developer" is really the only title that is deserved.
(Score: 3, Insightful) by TheLink on Saturday November 07 2015, @06:00PM
It would be like building a bridge, having someone drive over, and seeing if it crashes. No person who did that should call himself an engineer. The "hope and pray" method isn't good enough.
It probably would be done that way if building and testing a bridge is as cheap as building and testing software. In fact nowadays many things are actually done that way using simulation and models... Some even use "evolutionary design": https://en.wikipedia.org/wiki/Evolved_antenna [wikipedia.org]
Which is like crashing stuff a LOT and picking what worked best and doing it over and over again. So how different is that really?
Which comes to this: lots of people don't understand the real differences between Civil Engineering and Software "engineering" and thus why things are the way they are and why stuff fails. Many try to manage software projects the way Civil Engineering projects are managed using the assumptions that are only valid for Civil Engineering, or completely misunderstand what is what.
Civil Engineering:
Design Phase costs about 10% of Build Phase.
Build Phase involves tons of construction workers and heavy machinery and a fair bit of time. Increasing the speed of the Build Phase involves adding more workers and machinery, which can sometimes cut the build time by weeks or months.
The blueprints and plastic models are way cheaper to make than the Real Thing.
It's easier to convince Management to spend a bit extra to get the design better (not saying they won't be unhappy or that nobody will be sacked), because the budget only allows for one big Build.
Making Software:
Design Phase costs more than 1000 times the Build Phase.
Build Phase involves the programmer typing "make all" (or selecting "rebuild solution") and going to read Soylent News or fetch a coffee or do some sword fighting ( https://xkcd.com/303/ [xkcd.com] ). Increasing the speed of the Build Phase involves adding more GHz, cores, SSDs or computers, which can sometimes cut the build time by seconds, minutes or hours.
The blueprints and "plastic models" cost as much to make as the Real Thing.
Management often sells the blueprints/plastic models as v1.0 because they compile and "kinda run" and the budget only allows for one big Design... and the customers often buy it :).
There's no Gravity- you can do lots of weird stuff and it won't obviously fall over. And just because it looks complex doesn't always mean it is the wrong way of doing things. Sometimes a large multinational company's business processes are really that weird and complex- salary, leave, approvals, taxes and laws (of different states and countries), unicode, RTL+East Asian language handling, time zones (including DST), etc. it's just they and others don't realize it's that weird and complex till experienced people start giving them edge scenarios and asking them questions on what should happen in those scenarios. And even if you're experienced you may not capture all the edge cases or you might wrongly assume the customer would "obviously" prefer an edge scenario to be handled some way and thus not ask them (you have to assume otherwise there would be too many questions, many of which they would answer wrongly anyway ;) )...
So it should be no surprise that those plastic models regularly fail. Complaining that the plastic models fail and saying that's because "software engineering" is not engineering isn't going to improve things. Too many people stupidly/ignorantly think the Software Design Phase is like the Civil Engineering Build Phase and assuming that it is just as easy to speed things up a lot by simply adding more people and resources. Yes you might be able to speed things up by adding people BUT it's not as easy and you need to add the right people (and perhaps remove some people...).
As for "proof of correctness" and formal verification. In theory these are great. In practice in most real-world cases they wouldn't help that much because there's still the huge problem of capturing and describing the requirements accurately. You could have something that works 100% as per the specifications and design but the specifications were wrong in the first place and there's no formal verification for that.
And from what I see in many cases that's where the big problems are - the customer doesn't actually know what they want till you build something the way they insisted, despite your suggestions/recommendations and then they go, "Uh, the end users don't like it. How about we try 'changing things a bit'" and you go "but that means you want something that's more like a bridge instead of a tower". Or they go "That's exactly what we asked for, but after some tests we're going to stick to using Excel instead". Whereas the code deviating from the spec is often not too difficult to fix if your coders aren't complete idiots (e.g. they did understand the spec and wrote to the spec, they just made the equivalent of "typos").
Secondly say you really used "formal verification" stuff. Your formal verification "coder" could still make the equivalent of typos or bigger bugs while converting the human specification into the "formal verification" specification. So you still will have bugs despite it saying "100% correct". After all in most cases the "compiled" code works 100% exactly as what the coder wrote in the source code. Except it's wrong :). So how much would you really gain from formal verification in practice?
Can you give me "formal proof" or statistics showing that the average real world coder will make fewer mistakes when converting a complex real world spec into the formal verification specification? Or is the improvement in quality actually due to "selection bias" where only the higher quality talent does that formal verification sort of thing, and those higher end bunch would make about as few mistakes anyway even if they wrote it in Python instead of using formal verification methods.
If you really want to prove that formal verification really works, try outsourcing the conversion of a few complex human specs to formal verification specifications and resulting programs to the cheapest bidder and the average cost bidder. Then compare the results with outsourcing of the conversion of those same human specs to programs written in Java or C# or some higher level programming language. Compare the time and $$$ taken to produce 95% and 100% conformance to the human specs as per your interpretation. If you get significantly better results with formal verification methods then I will believe formal verification really works. Otherwise it could be as I said - it just appears to work because you are using higher skilled people :).
But be aware I have no related certifications in such stuff, nor much real world experience in such stuff either. I think I made some good and valid points though ;).
(Score: 2) by TheLink on Saturday November 07 2015, @06:25PM
On a less serious note- I bet in too many cases the "requirements gathering" ends up a bit like this: https://www.youtube.com/watch?v=UeMhjhGe4VA [youtube.com]
:p
(Score: 2) by Absolutely.Geek on Sunday November 08 2015, @08:44AM
As a software engineer in the industrial sense; my code runs factories and it works reliably for years on end. I work with mechanical; electrial; chemical and process engineers every working day.
The standard of engineering is that an engineer knows his design will work before implementing it.
On the good jobs this is totally true; however on most jobs there is always the engineering triangle at work. GOOD - CHEAP - FAST pick any two. There are so many instances of management asking me to fix mechanical flaws in software (it is possible about 30% of the time) because they have rushed the job and not given the engineers time to actually fully test / model the job. Or the engineer in question is just shit and the design is bad. Plenty of electrical problems occur; which just get fixed and the drawing are changed (assuming there is budget) to match reality.
I am by no means perfect but I have seen some funky shit in my time.
Don't trust the police or the government - Shihad: My mind's sedate.
(Score: 0) by Anonymous Coward on Sunday November 08 2015, @04:13PM
Anyone who has to compile a program and run unit tests to see if it works isn't a software engineer. It would be like building a bridge, having someone drive over, and seeing if it crashes. No person who did that should call himself an engineer. The "hope and pray" method isn't good enough.
How is the process of writing your code, hitting compile and then running unit tests any different from the process of designing your bridge in your engineering software and running a simulation to see if the bridge will hold up under various stresses? In both situations, we try to prevent problems before they crop up when it is too late.
The main difference is that a bridge has very few moving parts, and all parts obey just a few well defined laws of physics, so the stresses and behavior of a bridge (or other physical constructions e.g. cars, planes, power plants) can be estimated rather accurately with numerical simulation as long as you have enough computing power. (either by hand or ironically by using convenient computer software packages)
Software is different. It needs to obey all sorts of rules defined by humans, and humans are fallible. These rules may not make sense for historic reasons and may not even be internally consistent. And the guys who design/write the software are just supposed to somehow anticipate all these edge cases and handle them properly. Reasoning about all the possible states and execution flows becomes extremely difficult because the complexity rises exponentially with every feature added.
In software we try to make our compilers smart enough to yell at us when our code does not make sense. Unfortunately compile-time checks cannot find run-time problems, so we also try to use other means of ensuring that our software works as expected. Unit tests and other tests are just one example of that. Assertions, Exceptions and logging are other ways to prevent errors or to handle them gracefully when they happen, to revert back to a proper state or at least prevent damage. Functional languages and domain specific languages are another attempt to formalize the development of correct software, but these are still rather experimental and academic, and can prove difficult to use for general purpose tasks. Proving the correctness of systems with software and hardware is theoretically plausible but practically impossible for all but the most trivial problems.
Civil engineers made mistakes in the past resulting in bridges or buildings collapsing. I reckon they still make mistakes, but the effects are usually not disastrous, because that sector has reached a certain maturity.
If people want to hold software engineers to the same standard as civil engineering, expecting all software systems to be correct, not just the most critical ones, then be prepared to pay the huge costs that implies. No sane individual or organization will ever pay that cost unless they are absolutely sure that they need to (e.g. medical, avionics, critical infrastructure etc.) and even then, such a formal approach severely limits the feature-set of such systems.
(Score: 0) by Anonymous Coward on Monday November 09 2015, @03:31PM
Yet, engineering mostly relies on convenient physical approximations instead of mathematical proofs.