Slashdot Mirror
Define -- "Software Engineering"
2nesser asks: "How do you define the term 'Software Engineering'? Some see it as the implementation of the theoretical world of Computer Science, but isn't there more to it than that? Social responsibility, documentation, a program that works under precise, known conditions? Can you compare Software Engineering to other disciplines? What sets a 'Software Engineer' apart from the rest of the crowd?"
I'm sorry, but there's no such thing as Software "Engineering".
I have a EE degree but I work as a programmer now. Writing software bares only a superficial resemblence to any other engineering discipline.
Other engineering involves solid, proven, time-tested formulas and patterns, and can almost always be stripped down to "first principles" like the laws of physics.
Writing software involves re-inventing the wheel for every project, constantly changing it, and constantly changing methodologies to try and put out software that actually works for a change (where are the books on "Extreme Engineering"?).
In 100 years, Software may be specified, designed, built, and maintained just like bridges or radios, but not now.
Right now Software is more like some kind of creative art merged with mathematics. "Design Patterns" is the only thing I've seen in computer science that takes a step toward being more methodical, like other disciplines.
Not trying to insult folks who write software, I just think it's such a new and changing field, the methodologies havn't crystalized yet.
Engineering is about designing/implementing a product that meets certain criteria, with certain resources.
It's about getting it done for a certain cost, in a certain time. It's about making sure that certain saftey considerations are taken. It's about making trade-offs.
In the end, the software engineer has to be able to deliver a product and stand behind it. He or she is responsible for the quality of the product. If a bridge falls down, the engineers are blamed. If a car breaks down (due to bad design), the engineers are blamed. Similarly, if a program fails in some critical way, the engineers should be blamed.
From a software point of view, that means that we need to be able to accurately predict the behaviour of software. We need to be able to quantify things about programs. But we also need to be able to trade-off the cost of development with the savings. For example, it's silly to spend millions of dollars to protect a $10 asset.
We also need to be able to make guarantees about the safety and robustness of the software. This, I think, is going to be one of the biggest challenges as more and more life-critical systems become computerized with common-off-the-shelf components.
Just think of a project like the Ariane rockets... They are great achievements in mechanical, chemical, and electrical engineering. Yet the maiden voyage of the Ariane 5 blew up because somebody re-used software written for Ariane 4. The failure had to do with a floating-point error that was impossible on Ariane 4 but that happened on Ariane 5. (Well, it's more complicated than that, but this serves my point). The blame for the failure lies squarley on the shoulders of the sofware "engineers". Now, current software engineering techniques make it difficult to verify that a program can not be re-used in a new environment. But when the discipline matures, it will be Software Engineers, and their tools and tricks, that ensure that mistakes like Ariane 5 don't happen again.
When I worked for a large government contractor, there was intense interest in having our division become SEI level 3 compliant (then level 4 the next year, then level 5 the next year.)
:-(
This question was one of the ones asked by management at the time. They knew then that they were are the mercy of the 80/20 rules:
80% of the code takes 20% of the project time
last 20% of the code takes 80% of the time
80% of the staff does 20% of the work,
20% of the staff does 80% of the work.
etc.
So they tried to reign the "heroes" in. They did so by trying to adapt the over-performing 20% - by limiting what and when they could do, so as to:
A) bring the 80% along and
B) make the 80% not look so bad/suffer from low self esteem.
That division of that company reorganized itself into non-existence in the last few years (it had 1,200 "engineers" when they started in on the SEI stuff.)
--
In my opinion, programming is most efficiently done by individuals, when they are properly motivated. Much of the discipline of "software engineering" practices are VERY good but tend to be taken too far the instant politics are involved. For example, code reviews are essential for production quality code, yet when they become required for the tiniest change they become bureaucratic nightmares.
In my experience, the term 'engineer' has only been thrown about as a political buzzword; sometimes to justify higher education requirements, other times it is used to scare end-users out of filing formal complaints and other times it was used to raise hourly billing rates.
But whenever the term was used, it meant someone was planning on having programmers (ahem, engineers) program less.
"God is dead." - Frederik Nietzsche
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
I have been looking for a job for the last two months, and having dealt with several HR staff and recruiters, I can tell you that software engineering means you have an MCSE and can help the marketing director figure out how to get Powerpoint Presentation to "Open the internet".
.NET, Web Services and eXtreme Programming.
It also has something to do with like
"Can of worms? The can is open... the worms are everywhere."
>What sets a 'Software Engineer' apart from the rest of the crowd?
A good start, of course, is a four year degree from the department of Engineering at an accredited university. BS Computer Science under the Department of Engineering. Not those wannabe MIS punks in the business college with their accounting and management classes, but pure hardcore unadulterated comp/sci classes including compiler design, queue theory, three semesters of calculus, two semesters of differential equations, some statistics, numerical methods, logic classes, maybe some physics (statics and dynamics) while they are at it.
Second, a touch of autism never hurts. Real hackers can read 700 page technical manuals over the course of a weekend and remember the location in the book of any topic.
Be able to express yourself in strange languages - real software engineers can think in incredibly abstract ways, seeing things in ways that others competely miss. See 'A Beautiful Mind' for more complete information. Real software engineers write recursive code, self modifying code, and can think in six dimensions without breaking a sweat.
Finally, the ability to empathize with the machine is essential. Feel what the computer is going through, understand why it is working or not working, understand where in the system the bottleneck is and fix it to make your computer all better.
Offer your employee his choice between a raise and a new computer and the software engineer will pick new hardware any day.
Glonoinha the MebiByte Slayer
No it isn't since you never repeat writing the same software no more than an architect or engineer builds more than one of the exact same building
Think like that and you will never be a software engineer. Every bridge, building and program is assembled from components with common structures. Bulidings have foundations, walls, support beams in the walls, windows, HVAC, etc. An architect can put these together, predict how they behave as a whole and estimate how much the assembly will cost time after time in a repeatable fashion, even though no two final buildings are the same. Software engineering is about the same thing - assembling a program from commonly used components and being able to predict the cost and operational characteristics of the final product even though no two such products are the same.
Maybe the reason that you don't seem to think that software development can be stripped down to "first principles" is because you don't have the educational background to know what those principles are. The basic principles taught to Computer Science students around the country are as mathmatically verifiable and repeatable as any other scienctific system (including physics).
Thinks like "Big O" algorithm analysis, data storage techniques, and compiler theory form the basis of Computer Science and provide the structural underpinnings for most of the software engineering methodologies out there today.
I consider myself a software engineer. I certianly do not re-invent the wheel for every project because I have been using the same methodolgy ever since I started programming professionally (OOP). While I am constantly learning new tricks, techniques and technologies, the "first principles" that I learned in school have not changed over the last 50 years of computing history, and they will never change, because they have a firm foundation in mathematics.