In his Java Watch column in Software Development Times ( “Is Software Engineering an Oxymoron?”, March 15, 2005) the always interesting Allen Holub deconstructs the phrases “software engineering” and “computer science.”
He claims that programming isn't math, although it's often part of college math departments, and it isn't a science, since scientists study nature, creating hypotheses and tests to glean insight into physical processes. I agree that doing science is nothing like programming.
But then Allen distances software engineering from engineering in general. And here I differ.
He claims that a structural engineer can analyze a bridge's design to see if it will fall down. But in software we can't do that; he says “there's no right design and wrong design–just different designs.”
If only things were so simple! Consider London's Millennium pedestrian bridge, opened in 2000. Designed and analyzed by certified professional engineers, it was nevertheless a failure, a hazard in fact. Though it didn't collapse, the bridge swayed so much it had to be redesigned.
Allen goes on to say that in software “there's no right design and wrong design–just different designs.” I'd argue that a design that doesn't meet the spec is intrinsically “wrong.” And even in engineering buildings and bridges, there are many possible correct designs. One may be more efficient; others might have more visual appeal. But all are correct, as long as they're structurally sound.
He complains that certification for software developers–sort of a software Professional Engineer license–is impossible as there's no absolute standard of correctness for code. Yet that's surely true in every branch of engineering. I can build a circuit that works most of the time, but fails erratically during solar flares. Or one that's apparently perfect till components age and bias levels shift enough for the system to fail. I well remember one company that built their own switching power supplies. They worked great in the lab but failed during summer thunderstorms in the Midwest.
Correctness in anything is awfully hard to identify. My code may be perfect till the customer's kid presses all of the buttons at once. An exam will never compensate for imperfect people.
Interestingly, Allen goes on to say that programming resembles the liberal arts more than engineering. It's like writing a book, he thinks, requiring the same sort of skills. Ironically, some of the best developers I've worked with were originally English majors. They know how to express themselves clearly and concisely.
But they're utter failures until they learn the arts of the engineer. Software design is engineering. It's neither science nor a liberal art. Engineering is the process of using technology to solve problems. Regardless of branch, all engineers decompose hard problems into smaller ones, identify and invent solutions, integrate these into a gestalt, and then test the result.
Engineering is analytical. Writing a program means creating elaborate structures that interact in complex–and yes, mathematical–ways. We need the ISR to run in less than 12 microseconds. The system is 92% loaded. We must guarantee locks occur in some manner to avoid priority inversion.
Finally, and this is an argument I hear a lot, Allen suggests replacing math requirements in CS curricula with English composition and Latin (gasp!). I agree that we developers desperately need better writing skills, and the colleges must challenge our right brains more.
But not at the expense of math. Studying calculus is a great way to train ourselves in the art of being analytical. I have never used abstract algebra in my career and remember virtually nothing about the subject, but that semester spent manipulating strange symbols in new ways bears a striking analogy to writing C code.
As for Latin, so far my 3 years of Latin has yet to help me build better code.
What do you think? Is software engineering an oxymoron?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. Want to learn to develop better firmware faster? Come to his seminars in Austin and Baltimore in April. Contact him at . His website is .
COMPLETELY AGREE WITH YOU JACK. I will not go with Allen's words. As a practising engineer, I KNOW that designing software is an engineering discipline. ONLY STRUCTURED ANALYSIS can lead us to the correct design or designs. There are WRONG designs in any engineering. Even in mechanical – if I close my car's front door when the back door is fully open, the front door will scrub with the back door. Though the design is visually apalling, I would say that it is flawled and not ANALYSED and TESTED for the scenario. Every engineering has a different way to analyse and test – that is all to it.
I believe, hence – in any engineering discipline, the argument of correct and perfect design holds good only until we find a point at which the design was not ANALYSED and TESTED for the given scenario.
IMO: If Software Engineering is an oxymoron, then ANY Engineering is an oxymoron!
– Saravanan T S
There are typically three ways those who anounce themselves to be “REAL” engineer handle things.
1. Its a mechanical task to create code -> buy a “Magic” tool from a management consultant.
2. Ill hack it myself a sunday afternoon after the PUB -> GOOOD LUCK.(You have become a software engineer”)
3. Ill just hire people ->
“Got you”, now your in the hands of … software engineers++.
Bottom line is that someone has to do the job. I do understand many peoples frustration that it is seen as untechnical.(“But who care”) I recon that it has more to do with budget, funding and job status.(Push someone else down to increase their own salary.) In the end it will still be the free market that determine the outcome, and the storm in the water glas may only have local and temporal significance.
If any course should be added to the curriculum it would be how to get the most profit, cash return from ones education.
This argument just keeps going on and on. I'm a BSEE turned MSCS so I've seen both sides of the argument with a fair degree authority. Most engineering disciplines deal with analyzing, modeling and implementing physical parameters. This is where software does not fit.
To me, software is essentially the manifestation of mathematical proofs. There are lemmas (methods and functions) and assumptions (variables) that produce either true or false results (application works or fails). Design by Contract attempted to enforce correct assumptions to create our proofs. Software bugs arise because we have made false assumptions therefore our proof fails.
Writing mathematical proofs require creativity, insight, determination and practice—lots of practice. Do these skills sound familiar? I never did see a course at my level on how to write proofs. I was once told that some people just don't have the magic to properly construct proofs. There are many ways to construct the proof of Pythagorean's theorem. Some are elegant, some are direct and some are so obtuse not many can follow them. This describes 99% of the software I've seen in my career.
Now, if software is mathematics, can we claim that mathematics is engineering and mathematicians are engineers? No! Engineers use mathematics to solve engineering problems; furthermore, engineers use software to solve engineering problems. Does this make software an engineering discipline? No! It makes software a science to solve engineering problems—just like mathematics.
One last thing, there are more software/musicians than there are software/english majors. Ask your friends if they play an instrument. IBM did a study on this topic in the sixties.
– Jim Black
I totally agree with the Jack's argument. Manipulating matrices, solving Bessel's Functions, fitting curves, etc require a greater use of the “left” side of the brain and goes a long way in sharpening problem solving skills (understanding the physics of light/optics in games etc). I'm however amused at Allen's suggestion, I never really understand how writing for example, Shakespearean comments (// Et tu Compiler ??) would really help, except perhaps in documentation. And even then I really fret at the glaring technical errors than to see if the 'i' comes in before the 'e' or not rule.
Anything that helps us write better code is welcome. What next, art class to draw pretty flowers around my makefile?
I can't help but notice the article picking on abstract algebra. I think what separates engineers from English majors is the fact that engineers have the mathematical basis to learn abstract algebra when it suits them while normal English majors suddenly need another degree when the question comes up.
I hadn't heard much of abstract algebra until a few weeks ago when I discovered that abstract algebra was what I was going to need to learn to code up the Reed-Solomon ECC algorithm somebody asked me for.
I agree that we have the tools and techniques to enable us to engineer our software. The problem is that too many “software engineers” skip the engineering and just begin hacking in a “solution”. Although management bears a lot of responsibility for this state of affairs — demanding immediate signs of progress on aggressive or unrealistic schedules — developers must also bear their share. Engineering is a discipline. If we want to be considered “engineers” we have to discipline ourselves to actually use the available techniques to analyze the problem domain, and to apply that analysis to our design, (and then, of course, to thoroughly test everything).
I agree that an absolute standard of correctness is very difficult to ascertain, but I think this is true in any branch of engineering, as Jack points out. The only reasonable standard is that a product meets customer expectations. This is why requirements analysis is such an important part of software engineering practice.
– Arch McCulloch
I disagree with Allen. Software engineers are supposed to follow the software engineering process. Just because many don't doesn't mean the entire field is not engineering. The software engineering process follows the same process all engineering disciplines do: analysis, design, implementation, test. I think the mathematical background is necessary in curricula because it trains minds to think in a problem-solving way; which is all engineering boils down to in the end.
As one who does hardware and software design, I would have to say that software engineering is a perfectly legitimate description of the process. Software, at it's base, is still deterministic. Certainly, the ability to accurately describe the desired operation is desirable (and that may be why the comparison to writing a book was made) but in the end, the software has to do what is required of it, and the only way that happens is by designing it properly.
What I think is the biggest problem with software engineering is that there can be an enormous amount of interconnectedness and dependence of functions and data. I also think that we will not be able to write applications that are close to 100% reliable until we are willing to spend the time and money to test them under an enormous variety of conditions OR restrict the operating environment. In the end, however, the ability to analyze a problem and design a solution is one that seems to be best handled by an individual with an engineering mindset, regardless of their educational background – but dealing with embedded systems seems to call for much more familiarity with the hardware side of things, and that pretty much calls for a more-or-less conventional engineering education and experience.
– Dave Telling
Compeletely agree with you on this (and a lot of your other articles BTW) – you could not say it any better.
As for Allen's “Software engineering is about process, not structural analysis”, he has obviously never run across the “Software Engineers” who apply both equally, amongst other factors; the good ones that is.
Anyone can code, but not too many can come up with a good design that meets the specs, and therein lies the difference in perspective. Perhaps the concept of a “coder” vs a “designer/analyst/architect” needs to be debated.
Definately more writing and critical thinking skills are needed for all engineers but DO NOT touch the math. It is too closely tied manipulating the machine.
“I'd argue that a design that doesn't meet the spec is intrinsically “wrong.” “
And you'd be correct. How many of us have ever been presented with a systematic method of creating or evaluating a Software requirements spec? This would be a useful skill it include an any engineering cirriculum, but particularly for software engineers.
– Doug Law
There is definitely a difference between good software designs and bad designs. The bad designs are the ones that we must continually fix with baling wire and duct tape. Anyone can write a simple program but developing complex software systems requires sound engineering, analysis and problem solving skills. At work, we sarcastically describe our work as “just typing” in reference to the misconception that software development is merely the art of writing code. In reality, good software begins with good design and programming languages are merely the tools that we use to express that design.
The suggestion that software development is closer to English composition than mathematical problem solving is simply nave. The English department does not teach logical manipulation, De Morgan's Law, mathematical abstractions or basic problem solving skills. An essayist would be far too concerned with artistic appeal, witty dialog and overall feel to be an effective software developer. A typical software developer is far more involved in the minute details and intricate complexities of a system that would send most English majors away screaming in terror. The attitudes, goals and thought processes of English composition are contrary to those of software development. I might hire a liberal arts graduate to design the look and feel of my user interface or web page but I would only entrust the development of a driver to an engineer.
However, all engineers, including software engineers, would benefit from training in English composition so that they may communicate their intensions and solicit requirements from their customers. Good writing skills are yet another tool of the trade.
– Brian Walker
I am a hardware designer who has written some deliverable software in his 37-year career. Many of the products I am involved with have a great deal of software content. However, I feel that the software profession neither is a science nor is it engineering. Software design is not based on any of the physical sciences, nor is it mathematically derived. Sorry, but creating Use Cases is not engineering. When a new signal processing algorithm is developed by a systems engineer, that is where the science or engineering takes place. Coding that algorithm for execution on a CPU, while necessary and adds much of the value to the end product, it's just not in the same category as the original algorithm development.
– Steve Shimko
I wrote up my take on this in my blog:http://www.artima.com/weblogs/viewpost.jsp?thread=101023
– John D. Mitchell
I have studied both hardware and software and can tell you software development is engineering. We do not have a professional license and as a result some software engineers are not engineers, and can never understand the difference. It is a true shame and in a world where every fact is seen as someone elses opinion it is very difficult to explain why some design is wrong or flawed and unfortunately it will take a bridge falling down sort of speak to convince some people.
– Steven Bailey
MarkYou have to manage software developers more like artists than like engineers. They need the freedom to be creative, to let loose, to be a little wild.
Sure you need a good software development process and good design rules, but you also have to be a bit flexible with these to get the best results.
I think it's the nature of the medium. It's so fluid, just characters on a blank screen, easily worked, easily modified.
Whoever said that writing software is like nailing jello to a tree had it right. It takes an artist to nail jello to a tree.
I agree with your opinion that software engineering is in fact “engineering”. However, I'm not so sure that computer programming is engineering, even though it really should be.
My formal education is in Computer Engineering, which placed me right between the electrical and software engineers in their arguments over which discipline was better for the future of technology. Electrical is a more traditional form, yet the fact that more and more dedicated hardware is being replaced with embedded software is undeniable.
Software engineering definitely requires application of theory from mathematics and physics. Creating, for example, embedded software often has very tight requirements on code size and algorithm speed. The software designer has to be able to understand how their design is going to meet ROM size, speed and power requirements and limitations. This is definitely beyond the capabilities of most English majors with some C under their belt.
Computer science on the other hand often has sufficient math skills to get the job done but the understanding of the engineering principles is just not there. Large computer programs written in high level languages are a lot closer to composing a document rather than designing a device or process. Often readability and maintainability is a primary design goal rather than designing something than can be verified. It is my belief that this is one of the reasons commercial software has become less reliable and secure. Hardware designers learned long ago that you have to design with test and verification in mind since fixing errors down the road will be costly. Software designers often have a safety net provided by patches and fixes easily distributed via the Internet.
It seems to be that software engineers had a better understanding of engineering principles in the past because their implementation platforms required it. Yet in our modern computerized society software engineers are losing focus of the universal engineering principles that should be the core of their design, namely test and verification.
All other engineering disciplines often have to provide a guarantee with their design. The bridge will withstand the specified stresses, the circuit will operate under the following specifications, the chemical will dissolve the required substances, etc. Software engineers on the other hand often provide disclaimers, “not responsible for any” It's about time software designers started taking responsibility for their programs whether it's driving a pacemaker or a calendar on their PDA.
– Steve Lascos
At most companies I have worked at, engineering is not engineering! Management wouldn't have it! 🙂
– Jack Crack