How Software Engineering Differs From Computer Science 306
cconnell sends in a piece he wrote for Dr. Dobb's which "argues that software development will never be a fully formal, rigorous discipline, and the reason is that software engineering involves humans as central to the process." Quoting:
"Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science — perhaps the cyclomatic complexity of the software's control graph. But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code. The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software. The same is true for safety. Researchers have used some formal methods to learn about a software system's impact on people's health and property. But no discussion of software safety is complete without appeal to the human component of the system under examination."
Re:Is software "engineering" really engineering? (Score:4, Interesting)
Chuck Connel does not understand Simon's work (Score:4, Interesting)
There is nothing secret about human cognition. The fact that software engineering relies on human resources and not on binary logic is in no way a limitation. Many modern algorithms rely on heavily on probability and work with uncertainty. Herbert A. Simon [wikipedia.org] built a solid framework for understanding human decision making process. This framework is just as solid as mathematical formulas behind computer science.
Re:Is software "engineering" really engineering? (Score:5, Interesting)
Soft skill? Depends how well it's done. Lets use car repairs as an example. There are many times I've known or heard tell of where well trained city mechanics throw up their hands in defeat before the car is taken to either a 'mate who knows something about cars' or a 'bush mechanic' and fixed in 15 minutes. Ie. Sometimes the ability to observe, sort information well and problem solve is worth a lot more than a piece of paper with 'engineer' written on it.
Another example. I run a computer repair business with a 'no fix, no fee' policy. Even though I've never had a single day of formal training in the field, I have never, ever had to bring that policy into action. Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.
Old debate (Score:3, Interesting)
I think more specifically, Software Engineering is an empirical discipline. All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things. This puts Software Engineering more in the realm of social sciences than that of mathematics. As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches. In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.
Luckily this has been changing. Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic. Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem). Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician). Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion. All the good software engineers I know combine excellent technical skills with good empirical and people skills. It's all about measuring what is going on rather than assuming or deducing from mathematical models. Good SEs use test suites, profilers and other means to find out how good/bad their code is.
So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either). A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.
One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones. There's a lot to learn from how successful OSS projects operate. A lot of best practices find their origin in such projects. Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world. For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests. They developed a lot of technology and practices just to support knowing how they were doing. Most of that is now widely used across the industry. Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.
Re:Is software "engineering" really engineering? (Score:5, Interesting)
Going by the wikipedia definition, decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis. Admittedly I might be generalising, but is it more of a soft-skill then?
That's just horsepucky.
The only reason it seems the way you mention is that software processing cycles are so ridiculously cheap compared to, say, 3" C-Channel girders. But just today, I was doing some engineering to develop a distributed, self-healing clustering file system. Specifically, I was doing performance analysis of different approach, doing a base unit of 1,000 simple file reads. That is most *definitely* a physical analysis - performance tuning always is. But do I care about each individual line? Not really. Do I do extensive analysis of each individual element? Not by a long shot, simply because the actual, real, overall cost of the software is so low.
We host highly complex, vertical-market database solutions. We have a pretty decent hardware cluster comprising some $25,000 in whitebox rackmount equipment. A nice half-rack of stuff. And another $10k or so for a failover DR scenario. But compared to the number of customers we service, and the size of my company, that's an insignificant investment, yet we are overbuilt at least 400%!
If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?
Engineering != Science (Score:3, Interesting)
Connell titles his article "Software Engineering != Computer Science." He later proposes Connell's Thesis, "Software engineering will never be a rigorous discipline with proven results, because it involves human activity."
I would suggest that the article's title reveals why software engineering doesn't have "proven results" in the sense that Connell means. It's not due to human activity. Rather: engineering != science. "Proven results" (i.e., a set of results logically derived as part of an axiomatic system) are more characteristic of a scientific field than an engineering discipline.
Engineering applies and relies on science, but is not science, per se. Mature engineering fields have standards and codes of practice, both science-based and empirically derived. When/if software engineering matures further, it is reasonable to expect such standards and codes to develop.
Like Architecture (Score:3, Interesting)
I've always compared software development to architecture in that you can give a specification for a building (size, floors, x rooms, etc) and you can get multiple designs that fit the specification but a great architects design will always stand out.
Sometimes I look at code and it just does n't "feel" right, sure it may work just fine but I may not like the design choices taken whilst sometimes I see code that is designed so well that the peices fit together seemlessly (not that often I'm affraid).
Re:Is software "engineering" really engineering? (Score:1, Interesting)
Architecture (at least when done PROPERLY) is a bit like that. It combines an artistic aesthetic along with a rigorous utilitarian ideal.
Pure utilitarianism in architecture wont win any awards, but gets the job done. (Example-- concrete houses.)
Likewise, pure art structures tend to have serious functionality issues. (Bad use of floor space, leaky roofs, plumbing problems, poor airflow from poor window location choice, etc.)
The pinnacle is reached when both of these come together harmoniously. Considering the utilities at work at the time, I find old 19th century "Victorian" houses to be exceptional at this. These houses were very beautiful to look at, incorporating many artistic, yet functional edifices, and were designed to give maximal floor space economy for the furnishings of the era, along with good natural ventilation through hall, room, and window placement. There are other such "Beauty meets function" designs found elsewhere as well, but the point still stands.
In the software world, you have the same basic warring principles;
The CLI application is utilitarian, effective, and no-nonsense.
They "eye-candy bloated UI" application may severely lack in true functionality, but boy it sure is "purdy."
The pinnacle comes when the balance is struck harmoniously between usefulness, utility, and ease of use (aesthetics).
If I were to put that label on a piece of buyware, I'd be tempted to cite NT4. It was lean, efficient, stable as a mountainside, and reasonably pain-free to use. It knew it was just an OS, and that the user merely wanted to use it to get work done. Granted, it's features are horribly dated by today's requirements. It's a bit like the previously mentioned Victorian houses.
[today's incarnations of windows remind me of an old victorian house that has had holes cut in the walls, and had 'amenities' forcibly installed in such copious and wild abandon that it ends up looking like PeeWee's playhouse instead. [youtube.com] (watch for full effect, and tell me you don't agree.)]
So, at least in my opinion, Software Engineering is quite a bit like Architectural engineering, except using virtual components and aesthetics, instead of physical ones.
Re:Is software "engineering" really engineering? (Score:3, Interesting)
I doubt real engineers would use a completely unreliable piece of software.
Real engineers are practical enough to use software works well enough. They're not mathematicians who keep looking for complete proofs, or 100% - they are well aware of the real world.
And in the real world, it will be exceedingly unlikely that the finite element analysis software will work fine for lots of different cases, but fail dangerously for your case even though it is not really very different to other common cases.
If the case is something really new and "far out", I bet a proper engineer would do more checks and perhaps add higher safety margins.
The other thing is, an experienced engineer will often know whether something is dangerous. It's just like you looking at a branch and guessing whether it will hold your weight or not. If a branch is way too weak it's easy to guess that.
Similarly if the software gives a result that's ridiculous an experienced engineer should notice it.
So the software has to give a result that's not ridiculous, but still dangerous despite the margins of errors etc.
It's more likely that the contractor botches up the job (or cheats) and doesn't build according to the required quality and spec - e.g. use more sand in the concrete to save cost, use less concrete, etc.
Re:Is software "engineering" really engineering? (Score:3, Interesting)
"completely unreliable piece of _software_"
I doubt real engineers would use a completely unreliable piece of software.
The point of this article was that software engineers are not real engineers because they lack rigorous frameworks and rely too much on human factors. Seen from that point of view, you really only have two classes of software: those that are rigorously engineered to be reliable (and the article already claimed those don't exist), and those that are not. The last group must therefore comprise all software that's out there.
Real engineers are practical enough to use software works well enough. They're not mathematicians who keep looking for complete proofs, or 100% - they are well aware of the real world.
Fine, no problems with that. But "real engineers" should then also accept software engineers as real engineers. Software engineers are also practical enough to make software that works well enough - even though software engineers are not mathematicians who keep looking for complete proofs.
And in the real world, it will be exceedingly unlikely that the finite element analysis software will work fine for lots of different cases, but fail dangerously for your case even though it is not really very different to other common cases.
"We tried walking across it a few times and it stayed up, so it is probably fine" - Yeah, that sounds pretty rigorous to me...
If the case is something really new and "far out", I bet a proper engineer would do more checks and perhaps add higher safety margins.
Again, where is that rigorousness of which the article speaks? What you are proposing is just a matter of intuition, without any grounding mathematical framework.
The other thing is, an experienced engineer will often know whether something is dangerous. It's just like you looking at a branch and guessing whether it will hold your weight or not. If a branch is way too weak it's easy to guess that.
And an experienced software engineer won't know?
Similarly if the software gives a result that's ridiculous an experienced engineer should notice it.
And an experienced software engineer won't notice?
It's more likely that the contractor botches up the job (or cheats) and doesn't build according to the required quality and spec - e.g. use more sand in the concrete to save cost, use less concrete, etc.
...and we're back to human factors. Thank you for disproving the article entirely on your own.
Only if its the right experience Re:Experience (Score:3, Interesting)
You can learn the roman numeral system inside out and be the worlds leading expert on it but you can never do with it what can be done far more easily with the Hindu-Arabic Decimal system. A common introductory algebra student can by far exceed the limitations of doing math with the abstract Roman Numeral set.
The Decimal system allowed us to use "nothing" to hold value. The Zero place holder....something so simple, yet so enabling...
Who'd thought "nothing" could be so power enabling?
The same holds true of Computer Science and Software Engineering.
And again we are at a point of needing to recognize a real value of something that seems so unreal or foolish sounding.
Abstraction Physics [abstractionphysics.net], but how can the abstract be physical?
Not only can abstractions have a physics to them, but without the physical, abstractions cannot exist at all. And it is the physical that enables the creation of abstractions, a physical reality that does move in the process of making and using abstractions.
This is where abstractions and physical reality meet, where abstract ideas are converted to physical effect and hard reality.
What you are reading right now is an example of abstract conversion to the physical. From my mind to my fingers on the keyboard to the computer and over the internet..... to your screen where its being input into you and your mind. And if it were instructions to do something and you did, like make a paper airplane ...... thats all physical...
Just as there are definable atomic structures in the physical realm getting more and more refined, so it is with abstraction and genuine software engineering in dealing with abstractions and their unavoidable physical creation and use action constants.
These constants are identified and defined and by nature are so inherent in our human functioning that we don't even think of them..... However, computers are not human and they don't, unless we program them to. And we haven't yet done so from a POV of Abstraction Physics [abstractionphysics.net] such the understanding would be as common and applied as the Decimal system is today, instead of roman numeral based mathematics.
Genuine Software Engineering should be making the task of programming easier for all of us. But it seems stuck, to use the analogy, thinking in terms of roman numeral mathematics. Physicist identify, define and refine our understanding of the physical, but abstractions, though we are the absolute creators of these, there is still the unavoidable and unchanging physical reality action constants of abstraction creation and use. And it is this that is the solid foundation upon which to build genuine software engineering.
The proof of the action constants is simple: Try not using them.
Software never fails, people decide it does (Score:2, Interesting)
The statement that software engineering - which is a mislabel - cannot be a rigorous, formal system is so obvious that it might as well be one of those things we never think about until we have to and when we do think about it it's intuitively obvious.
Consider what will happen when you die, there are only three possibilities: You exist after you die and you like the results; you exist after you die and you do not like the results; you do not exist after you die. All three possibilities are equally valid since we have no evidence of any of them. If as it turns out, that when you die you cease to exist, it is not something you need to worry about. Now, the thought probably terrifies you - it used to terrify me, too - until you realize something: if you cease to exist, you will know nothing. You'll never know that you don't exist.
So consider the conditions of the existence of software. Software is always perfect and is always the same, it never changes. It does not rot, rust, age, get moldy, crumble, break, shatter or fail. It never needs maintenance, lubrication, cleaning, sharpening, polishing, repair or replacement. As long as the hardware that copies it makes identical copies, it is perfect and always will be perfect, except for the extremely rare and unusual case of deterioration of the storage media due to cosmic ray damage. Which can be detected by mathematical algorithm, in which case, if there is another source, another perfect copy can be made and it's right back where it was. Software is never defective and can never be defective other than the case I've given of the rare possibility of cosmic-ray damage to media or hardware failure in copying, and thus it never needs change, modification or updating.
Every year, every country makes changes to its tax laws. Any software which must comply with those new changes has to be changed according to the decisions of tax accountants and lawyers as to what is needed to be in compliance. If you have a cellular network and want to add new features, you have to modify the software - in the switches, the handsets, the gateways, and/or all of these - to be able to enable them to offer new features. In both cases the software needs updating.
Both statements are true, but you might ask how they can be when they appear to be conflicting. They're not, and I'll explain why.
Any software package, from a 1-line APL function to a 20 million-line COBOL behemoth application suite that runs a trillion dollar bank, large insurance company or government agency, only requires maintenance or change because in someone's subjective opinion it needs a change. A bridge needs replacement when it collapses or when it is beyond its useful life; a building needs replacement under the same circumstances. A piece of metal furniture needs replacement when its structure rusts into dust, fails or is unable to support a load due to metal fatigue. These are objective facts, either the structure is usable or it isn't. An engineer can determine by experience and judgment that the structure is at its lifespan limit or can point to signs of physical rust, deterioration, or structure failure indicators that prove their opinion.
Any declaration that a software package needs updating, change, or replacement is strictly based upon the subjective opinion of someone saying that it needs the work. All software change is the result of some person's opinion that the change needs to be made and have no basis in reality except their opinion. Their opinion is correct if you agree with them or if in your opinion you can't disagree with their opinion. They may be correct that because of errors in how the software performs its desired function, need for new function, or need for changes in existing function, the software needs change, replacement or updating, but they can only be "correct" because it is considered that in someone's opinion they agree with their opinion that the change is needed.
But the claim by someone that a software package needs cha
Why many software projects fail (Score:4, Interesting)
Civil Engineering:
Design Phase costs about 10% of Build Phase
Build Phase involves tons of construction workers and heavy machinery.
The blueprints and plastic models are way cheaper to make than the Real Thing.
Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.
Software Engineering:
Design Phase costs more than 1000 times the Build Phase.
Build Phase involves the programmer typing "make all" and going to read Slashdot or fetch a coffee.
The 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...
It should be no surprise then that the plastic models regularly fail.
But maybe I'm seeing things wrong?
BTW I suspect that a Civil Engineering Design phase is managed a bit differently from the Build phase. Still, I'm not an architect or civil engineer so what do I know.
Re:Perspective? (Score:5, Interesting)
Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
I think you're confusing (or conflating) science with mathematics. But don't feel bad; people do this all the time. Part of the reason is that science routinely uses mathematics as a tool, and the two fields are deeply intertwined. Scientists use math to help understand and explain what they're working on, while mathematicians routinely use scientific work as inspiration for new ideas to pursue.
But the "science" part is usually very much about the real world. It's the mathematicians who carefully avoid dealing with the real world, since that's not their job. The interesting part is how often the abstract, theoretical stuff that the mathematicians work on turn out to be very applicable to figuring out what's going on in the real world.
One of the problems with our terminology is that "computer science" is generally used for the abstract, theoretical part of software. This is misleading, because the subject really is a mathematical field, not scientific. If it were scientific, the computer scientists would be performing experiments and developing hypotheses to explain how software works. But that's not what they do; it's the "software engineers" trying to debug software that do things like that.
And this leads to the problem that "software engineering" generally involves doing things that in other fields would be called "science". In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design. With software development, this isn't generally true. An engineer designing a bridge or house or airplane can expect to work with detailed specs for all the available components. With software, the equivalent information is usually proprietary and intentionally hidden from the people building the code. Even in "open source" systems, the concept of "information hiding" is popular, and all too often this does mean that needed information is intentionally hidden from the person writing the code. So the software engineer is working with poorly-documented material, and must develop using processes that test and discover the properties of the underlying stuff.
Of course, there are some software engineers who don't do any debugging. But we know how well this works. Civil engineers might be able to develop this way, since they have access to full specs for their material. Software engineers can't, because they are kept ignorant of the details of lower-level stuff. As long as this is true, software engineering must have a large scientific component, to study and test the software as it's developed. They must constantly develop and test hypotheses about their code, in order to get it to function as desired in an environment that is mostly hidden.
Anyway, there's little chance of getting the terminology straight any time soon. There's no chance of software people getting access to detailed specs for the underlying systems. We even have laws in place that block the access to full information. So software engineering can't really be true engineering, and software developers will continue to spend large parts of their time acting as experimental scientists in order to debug their software. And they won't get much help from the computer scientists, who are spending most of their time working with the mathematics of the subject, while disparaging the real-world portion of their discipline as being "mere engineering".
Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use. But that isn't going to happen any time soon.
Re:Experience (Score:4, Interesting)
Actually I wonder if the code written on the Vic 20 is exactly the code that matters. Even if it was just copying right from Byte magazine.
Here's what it says to me:
This is a software developer that was doing computer stuff when he was young because he enjoyed it. Not IM, not games, not first person shooters or flight sims. Software development in its basest form. For free. Because he could.
It also says he has been doing it for a very long time. If he is still doing it, he does it because he enjoys it - not because of how much it pays or how glamorous it is or how 'easy' it is compared to other jobs.
There were plenty of kids with the opportunity to spend all day every day on the Vic 20, but very few did so because in all honesty from an 'entertainment' perspective it sucked.
Give me someone who grew up hacking on a Vic 20 any day over a coder who knows the Java API set inside out (but started coding it three years ago, and doesn't know anything else.)