Define -- "Software Engineering" 118
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?"
Repeatability and Predictability (Score:4, Insightful)
Re:Repeatability and Predictability (Score:2)
Re:Repeatability and Predictability (Score:4, Funny)
No, we software engineers do not make the same mistake over and over. We make different mistakes each and every time.
Re:Repeatability and Predictability (Score:2)
One of the things that struct me as setting engineering apart was it's unique concern for controlling failure.
A program that can perform some intended fuction might just be the result of programing.
But a program that can do this while failing gracefully in a controlled manner under certain understood conditions would be the result of software engineering.
Re:Repeatability and Predictability (Score:5, Insightful)
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.
Re:Repeatability and Predictability (Score:2)
Re:Repeatability and Predictability (Score:2)
Then your post was in response to something I did not write. Nowhere did I mention anything about a scientific experiment. Nor in fact do such experiments demand anything like exact reproducability. There is no such thing. All experimental results contain uncertainty and error due to variations in procedure, conditions and measurement.
Re:Repeatability and Predictability (Score:2)
Re:Repeatability and Predictability (Score:2)
If this is so, why did the Software Engineering Institute gave their Capability Maturity Model Level 2 the title "Repeatable"?
Re:Repeatability and Predictability (Score:1)
Re:Repeatability and Predictability (Score:2)
For example, you could use a commercial SQL package, or MySQL for the database; and you should weigh up and have a conscious reason for choosing one or the other, for that particular application.
Clearly a commercial package will be more expensive, but may well be faster, but if you don't need the speed, then...
Trading off is not a sufficient condition for engineering going on, you can be trading off without doing engineering, but it is a good sign.
Re:Repeatability and Predictability (Score:2)
Re:Repeatability and Predictability (Score:2)
Please read the Software Engineering Body of Knowledge [swebok.org] and stop calling yourself a Software Engineer.
Re:Repeatability and Predictability (Score:3, Informative)
That which is repeatable and predictable is automatable.
Go ahead a credit me for that one. I don't remember if I got it from anywhere. The whole point of writing software is to releive people of tasks that are tedious and error-prone for people. If there are predictable, repeatable steps to produce something, then a program can be written to perform those steps. The worst term I've heard for the act of actually writing software is "software construction." Ugh. Compilers and project tools construct or, as most of you are familiar with it, build software. Does an author construct a book? No, the printer does.
What we do as developers is to design software. The design spec is the source code itself. We just have the privilege of having tools that construct from that design specification directly.
Architects (real ones, not the ones in software) will actually work on many levels in a building, not just the highest levels. There's the lead architect that figures out what the main uses of the building will be, and comes up with a general vision of how that building will work. Then, if he's lucky and has other architects working for him, he enlists their help in fleshing out the details, and designs the building down to the last sink faucet. Doesn't this sound familiar?
At this point, software and building engineering diverge. It's impossible for a architect to build functional experimental copies of their buildings, so they settle for models. They will design and build over and over (like how we write and compile over and over) until they get what they like. And then they hand it off to the construction workers, who are usually supervised by the architect during construction, because details usually crop up then.
Does anyone see the parallels between the two? We, the software engineers, are the architects. The build tools are our construction workers and model-makers. We are all designers, just at different levels, and don't let anyone try to equate you with a construction worker. You are a skilled professional whose insights and knowledge are useful to the outcome of software development.
Re:Repeatability and Predictability (Score:2)
I prefer: "Applied Software Engineering is a project-related discipline which employs systematic and quantifiable processes and techniques for creating cost-effective solutions to practical problems, with the purpose of optimising the development, delivery and maintenance of software which is reliable and meets user expectations when operating in the real world."
This is a synthesis of definitions from professional SE groups and organisations around the world, including the Software Engineering Institute [cmu.edu] at CMU and the Software Engineering Body of Knowledge [swebok.org] (SWEBOK), that embodies the goals, responsibilities and practices of SE.
To begin with, I am shocked that only one poster so far has mentioned the SWEBOK. This is the codex for anyone who wants to call themselves a Software Engineer, and in time will become the foundation of an international standard for SE skills.
It is important to realise that the goal of SE is not repeatable and predictable development. It is the creation of quality software (inherent in that meeting user, reliability and maintainability requirements), on time and on budget.
Achieving this goal has (at least) two aspects: a disciplined approach based on sound theory, and managing risk. Together these equate to reliability and predictability (both influencing and being influenced by discipline and risk management), making these a means to an end.
Unfortunately too many engineers lose sight of the real goal and instead target the means to achieve that goal. A perfectly predictable, perfectly reliable project is a failure if it can't delivery what the customer wants, on time and on budget.
So what is SE really? The SWEBOK answers the adequately. It identifies the areas of expertise in which a Software Engineer must be profficient:
Management (including risk management, project management and Best Practices) is a more important skill for an engineer than development.
working definition (Score:2, Informative)
Re:working definition (Score:5, Insightful)
Re:working definition (Score:2)
Of course, even if the client is experienced in the field, engineers will probably need to work with the client to more completely specify their design.
(ignore my sig, this post is not a troll)
Re:working definition (Score:3, Interesting)
You are mistaken. Civil Engineers design a skyscraper, construction workers construct it. Mechanical Engineers design a car, assembly line workers construct it.
A software engineer spends 80% of his time on requirements capture, analysis, design and documentation and 20% of his time coding. A programmer gets his instructions from an engineer and spends 95% of his time programming (and the rest goofing off on
In any mature industry, actual implementation is semi-skilled labor at best.
P.Eng. certification (Score:2, Informative)
abuse of the work "engineer" (Score:3, Insightful)
The word Engineer used to connote quality, rigor, someone who builds things that last. Engineers design buildings, and bridges, heavy haul trucks. Things that last for 20 years or more. As software developers we are more like artists. We design the tools that suite the latest fashion. Most software is trash in less that 3 years.
Prove me wrong.
Re:abuse of the work "engineer" (Score:1, Informative)
TeX
sendmail
C
emacs
BIND/named
and (ready for this!?) the TCP/IP stack
In some incarnation, these have been around for a few decades:
UNIX
Windows (note quite, but it has been around a while now)
and that's just off the top of my head!
but that said, i do agree with your point. it is a shame to see the title Engineer abused the way it is. Unless you're a P.Eng (i'm not!) you have no business calling yourself one---Even if you have an engineering degree and are not yet registered.
Re:abuse of the work "engineer" (Score:2)
This piece of software has indeed lasted twenty years and is just as useful today as it ever was. In fact, it has been used in ways which nobody ever intended, like denial of service attacks.
Re:abuse of the work "engineer" (Score:1)
Re:abuse of the work "engineer" (Score:3, Insightful)
As others have mentioned software engineering is about developing and using an engineering process when developing software. Just as in the beginning of engineering bridges, many people who 'engineered' bridges did not practice what we would consider to be anything near engineering today; there will (hopefully) be a time when we will look back at the present (and the recent past) with awe that so much software was made without sound engineering practices.
The goals of any mature engineering discipline include providing complete designs, reasonably accurate forcasts of time for development, safety considerations, and generally some sort of societal good.
Software Engineering is still very much in its infancy, ABET, the organization which accredits engineering schools in the united states has yet to accredit any software engineering programs, but that will probably change within 2 to 3 years. Additionally, only one state, Texas, recognizes and licenses Software Engineers. I expect that within 10 years, most states will license software engineers.
I also expect that within the next 10 years, software engineering as an engineering discipline will grow in recognition, as its benefits become redily apparent by prominent examples of software engineering (for example, when some major company starts following its forecast timetables and its software is not terribly buggy). I imagine that while use of traditional software development will decline, it will continue for many years to come.
For further information on software engineering, look at Watts Humphrey's A Discipline for Software Engineering or google on 'CMMI'.
(ignore the sig, this is not a troll)
Re:abuse of the work "engineer" (Score:2)
Engineering artifacts last for decades, but works of art last centuries or more! Have you ever even been to a museum? If you want an analogy for computer programming think more along the line of flipping burgers.
Re:abuse of the work "engineer" (Score:2)
Most software is created because of a need, where as art is created for an expression.
Yeah that is easy. (Score:1, Troll)
Re:Yeah that is easy. (Score:3, Funny)
Can you imagine if car designers were held to the same standards as web programmers?
I dunno... (Score:1)
Ain't no software like that sold that I am aware of. Brand new software gets a full skate on most things and is sold "as-is" like a used car, not like a new one. It's usually not even warrantied to even get off the lot.
Re:Yeah that is easy. (Score:2)
Re:Yeah that is easy. (Score:1)
Yes, but I already heard the cliche about a woodpecker and civilization being destroyed.
no such thing (Score:4, Insightful)
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.
With All Due Respect.... (Score:5, Informative)
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.
Original poster correct, not you (Score:2)
Programming within certain fields can certainly be broken down into known variables. If you are programming a DB app, for example, you'll need a schema and an idea of how you are going to get information into and out of the database. Much of actual program involves such known things.
But what if you are doing something no one has done before? Software engineering simply doesn't have anything to say. Computer science involves developing means for information processing, much like X engineering is limited by whatever X is (i.e, "mechanical" engineering). But that computer science deals with "information" doesn't really limit it at all.
The only limits that can be said about information processing are either (1) so fundamental to be of no use in all but the most theoretical work, or (2) so abstract that they can never be translated into things we need.
For an example of the first, we have Turing machines. They place theoretical limits on computer science. But rarely do you see someone say, "I would do that, but it is an impossible task for a Turing machine."
For an example of the second, we have software development models. These are usually prescriptive in that they say you should write lots of documentation and form a byzantine design document before you even start thinking about code. Regardless of their relative merits, you cannot use these models to gleen any useful information. For example, the waterfall model will tell me that I should do this, and I should do that, but it will not tell me what I want to know, which is how long the project will take.
That being said, I think most attempts at analyzing a problem before solving it are doomed to failure. To determine feasability, you just have to do it. I recall several times when I would figure out a simple way to do something when analysis had previously determined, "This is impossible or impractical because..."
Computer science is about solving problems. Software engineering is trying to solve the problem of solving problems. But you can only abstract so much. In the end you have to solve the original problem. You can't just form some abstraction that lets you solve anything that could possibly come up.
Re:Original poster correct, not you (Score:2)
Person One: We want to build a machine that flies, you know, like birds.
Person Two: Building a machine that flaps its wings and produces enough lift to fly is impossible.
Orville and Wilbur: Hey guys! Like our plane?
Re:Original poster correct, not you (Score:2)
In any engineering disciple, if you are honestly doing something that no one has done before, then X enginneering isn't going to have much to say. Engineering is really about doing things over and over again, only hopefully better each time. The first time something is done, its likely to be done by an artist, or a skilled craftsman. After a while of that, it is likely that a scientist (or several) will study this. Finally, engineers will be able to add it to their skill set. Nothing prevents you from being an artist, a scientist and an engineer for the same project....
(ignore the sig, this is not a troll)
Re:With All Due Respect.... (Score:2)
Re:With All Due Respect.... (Score:2, Informative)
Want a real-world example? Here you go:
I once wrote a rendering engine for a GIS data viewer. GIS (Geographic Information System) data, in case you're not aware, is huge. We're talking gigs and gigs of data in some cases. Because of this you can't just use a regular old 2D rendering system to draw it all on the screen because it won't scale up to be able to handle all this data. So when I was writing the replacement rendering engine, I make sure that all the lookup algorithms we used were O(log(n)). This is what makes rendering all this data possible, becuase you can find what you want to draw in logrithmic time (instead of linear time). I was able to establish this standard WAY before we wrote a single line of code. I could have just built a hashing system to look up the data in O(c) [constant time], but because of the algorithm analysis techniques I learned in school I knew that O(log(n)) lookups would be sufficent for the task (and save memory). So how many times did I have to re-write this rendering engine? Zero. I did it right the first time because I could prove the way I was doing it was performant enough to meet the spec before I wrote any code.
The reason that most of the code out there is terrible is because most programmers don't have (or don't use or don't remember) any formal computer science or sofware engineering training. Because of this, too much time is required to write really good code, so corners are cut. Software Engineering is not about establishing a draconian process to force developers to code a certian way, it's about providing tools and tricks to help them solve problems and prevent bugs with the least amount of effort.
Big-O (Score:2)
Re:no such thing (Score:3, Insightful)
Engineers existed long before any laws of physics were codified. In Fact, the first formal mathematics was invented as the result of studies of the methods Egyptian Engineers used to construct pyramids. For example the Egyptians used 3-4-5 triangles to lay out right angles.
Engineering does NOT requires ANY proof of anything, merely a well structured set of rules that works. Over time Engineers have fould that there are good uses for things like mathematics and physics, but for the most part the rules that engineers have used to build things over the past 4000 years were codified into the laws of physics and mathematics as an afterthought.
Writing software involves re-inventing the wheel for every project, constantly changing it, and constantly changing methodologies to try and put out software
That is not software development, that is Calvin Ball. Take a look at the Software Engineering Institute's Capability Maturity Model and you will immediately recognize your description of software development as CMM Level 1, i.e. chaos. The only reason your method ever succeeds is through the heroic efforts of a few talented individuals. This is the reason so many software projects fail, are late, and are over budget. Random actions are not a fundamentally sound way to build products.
Other organizations have better ways - for example the Loral Space Shuttle Software Group operates at CMM level 5 and produces the code with error levels on the order of 0.5 errors/KLOC where good quality commercial software runs at an average of 20 errors/KLOC.
In 100 years, Software may be specified, designed, built, and maintained just like bridges or radios, but not now.
Some places do that now. Unfortunately about 90% of the software industry is operating at the level of Calvin Ball.
Re:no such thing (Score:1, Interesting)
Other organizations have better ways - for example the Loral Space Shuttle Software Group operates at CMM level 5 and produces the code with error levels on the order of 0.5 errors/KLOC where good quality commercial software runs at an average of 20 errors/KLOC.
Are you sure this level of performance isn't just due to a coincidental collection of "talented individuals"? I.e., could you pull a random group of CS majors off the assembly line (heh) and train them in these methods, and achieve the same results?
Unfortunately about 90% of the software industry is operating at the level of Calvin Ball.
Why do you suppose that is?
Re:no such thing (Score:2)
I do not personally know of any studies that would prove my comments right, but they probably exist, I would imagine SEI has done some.
Most of the software industry is operating in chaos because it is has the least initial cost to get into the software industry. Having a structured process requires quite a bit of initial investment, since you need to develop the process, train your staff, and you do not get the payoff until you have run through several development cycles.
(ignore the sig, this is not a troll)
Re:no such thing (Score:2)
Talent level may be necessary, it is clearly not sufficient. There are plenty of organizations with high levels of talented programmers that produce poor quality software.
Re:no such thing (Score:2)
There are more than 50 formal methodologies for software development. Your knowledge is clearly limited to development in the narrowest sense (programming), which is the area to which design patterns applies. According to most formal models, getting down and programming should consume somewhere between 20-30% of project time, and that's excluding maintenance time!
SE no more reinvents the wheel than civil engineering does. Ever see two identical bridges? I haven't. They are different widths, different lengths, have different aestetics. But there are a few basic design principles, methods for calculating loads and tolerances and choosing materials, and techniques for putting the bridge in its place.
In software we have blocks of reusable code (components), techniques to combine them (APIs), provable methods for handling classes of processing and storage problems (algorithms and normalised database structures).
The biggest factor that causes the wheel to be reinvented time and time again in software development is ego. Most developers simple can't handle using someone elses code. The second biggest factor is a lack of documentation; which illustrates beautifully how so few "software engineers" actually know anything about the field they claim to be experts in; the third factor is cost, because it takes a SE to explain to a business manager what a programmer won't: buying a third party component for $200 reduces risk and costs less - even in the short term - than assigning a single develop to it for three days.
The software development world is full of hacks, information systems graduates and cocky comp. sci grads who like to think they can call themselves software engineers. If everyone who could pick up a soldering iron called themselves an electronic engineer, I'd also get the wrong impression.
Fortunately there is a REAL discipline called Software Engineering, with REAL processes and time-proven methods for delivering software, as required by the user, on time and on budget. See the Software Engineering Body of Knowledge [swebok.org] for more information.
Just like any other engineering (Score:4, Insightful)
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.
Re:Just like any other engineering (Score:1)
When an engineer builds a bridge, he looks at the specifics of the situation. What sort of traffic is this bridge going to get? What sort of stresses will it be under? Is this area subject to high winds? Seismic disturbance? Is this area particularly dry, or wet? The resulting bridge should work perfectly within those conditions.
In contrast, software is expected to work with all sorts of configurations. An end user expects a program to work under Windows 95/98/XP. He expects it to work with all his hardware that the programmer has never seen. He expects it to play nice with his video card, his sound card, his game controller. And so does his next door neighbour who has a totally different video card, sound card, game controller.
The point is, software has a large number of complex dependencies, which all may have undocumented quirks and idiosynchrosies. Until this sort of thing is fully abstracted away behind a reliable, predictable (and popular) OS, Software Engineering is going to be a pain in the arse.
Re:Just like any other engineering (Score:2)
I imagine at some point, there will be an OS that is developed with engineering principles in mind that combined with drivers developed similarly will provide a reliable and predictable OS. An OS that is reliable and predicitable will atract developers and uses.
Re:Just like any other engineering (Score:2)
The problem is that software is often made with far too many assumptions. Furthermore, software is often given less respect than hardware, since it's "easy to fix" software. This leads to people re-using code in ways that are inappropriate. Just like a car designer can reuse a certain type of glass for a windshield, and that glass fails because it was designed for something else, a software designer can reuse code in a way that violates its design principles and assumptions.
This is one of the biggest problems of software engineering: checking the assumptions. I haven't yet heard of a car breaking down (catastrophically) due to software, but it will happen, because people put too much emphasis on time to development, and not enough emphasis on engineering. And since the state of commercial software engineering is very bad, this gives us programs that are totally insecure, or programs that fail in life-threatening ways.
Re:Just like any other engineering (Score:2)
Finally a poster who knows that he is talking about!
The hurdle now for SE is to establish itself as a respected profession, where Software Engineers can (and do) stand up to business managers and explain that software is not quick, or easy, or simple to fix.
This involves a change in mindset of managers, software engineers, developers, and consumers. The customer is used to paying more to get less, especially in this industry. Managers are used to making unrealistic promises. Until there are a bunch of engineers in the middle with their reputations and professional recognition on the line ... its not going to improve.
What an ominous question... (Score:5, Insightful)
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.
Re:What an ominous question... (Score:2)
You are right; the way to run a large project is to have lots of individuals with well-defined interfaces between their code. So you have a fraction (probably the majority) writing code that exposes APIs to fulfill all the requirements of the project, and the rest of the people develop "glue" that calls these APIs to actually implement the project. This highly modular approach is well suited to OO methods, and makes for great reuse, especially if you can retain your staff long term - someone comes along with a new project, and someone experienced with the codebase can "glue" it together very quickly.
Re:What an ominous question... (Score:1)
The famous 80/20 rule can be used effeciently by setting the goals for a group of software engineers or programmers at 125% of the actual goal. Done right, using techniques like nightly builds and refactoring, you can pull the software after 20-30% of the time and ask for productation in a branch.
Most likelly you will be able to deliver long before the 80% time limit (at 100% for the original goal) and then can do neccesarry refactoring and module redesigns awaiting feedback from the first field tests. This is hard todo building a bridge I guess.
Re:What an ominous question... (Score:2)
Although it sounds counter-intuitive, what management did is not strictly wrong. It just sounds like the managed it incorrectly. Contemprary constraint theory (I found a brief explaination [iastate.edu]) suggests that subordinating all processes to the speed of the bottleneck is the best way to improve throughput.
This is very difficult to do in a software development organisation, which is one of the most ego-driven working environments.
In my experience the only way to handle this effectively is to get your best developers/engineers to devote their time to mentoring and prototyping the next phase once they have finished their current deliverables. It is also useful to encourage them to learn new technologies and practices, especially best practices like configuration management.
Sadly most managers don't like this ... it seems like a waste of time. Throw away code (prototypes) never go down well, and learning is often something that employees "should do on [their] own time".
This is why it is essential that Software Engineers have management and communication skills, not only downwards, but upwards as well. Managing the knowledge and expectations of business managers is critical in the success of a project -- and of a company!
Re:What an ominous question... (Score:2, Interesting)
Please don't post as AC; I almost missed your reply.
That is a good point. I wasn't trying to go in quite that direction but now that you mention it...I do think that programming naturally progresses to engineering. That is, a person will either 'get it' or not. If not, then they will not be programming long. But if they do, then they will accumulate their own bag of tricks over the years, and gradually appreciate and adopt engineering principles.
So in that context, yes, I would consider a senior programmer equivalent to an engineer trainee.
I was trying however, to point out that the term engineer is more often used as a cludgeon by bad managers.
Re:What an ominous question... (Score:1)
Re:What an ominous question... (Score:1)
I.... (Score:1, Informative)
-I use dictionary.com and you should too -- it has a good definition and links to others, check here [reference.com]
Can you compare Software Engineering to other disciplines?
-Umm. yes I can.
What sets a 'Software Engineer' apart from the rest of the crowd?
-I guess that would almost entirely depend on the crowd.
Re:I.... (Score:1)
According to the HR director... (Score:5, Funny)
It also has something to do with like
Re:According to the HR director... (Score:2)
I can build a new wall in my garage and can install new electrical wiring, therefore I must be a good corn farmer. What?!
Re:According to the HR director... (Score:2)
The course I took in school called "software engineering" was mainly about the management, planning and processes involved in designing, implementing, and testing a software solution, and the tools for doing so.
Here's an interesting collection of definitions of "software engineer" [iit.nrc.ca].
My definition (Score:4, Interesting)
The term developer was coined (IMHO) by programmers who didn't like being referred to as programmers because it has an implied "lowly" in front of it or comes off as generally nerdy.
Going back to the rest of the original question:
It would be a minor miracle to know conditions precisely. What you do know are expected conditions and you want the software to work under them. But there are an infinite number of unknown conditions. What you would like to happen is that the software either flag the conditions as inappropriate and refuse to act or fail gracefully.Re:My definition (Score:2)
This is what we in the trade call a "designer". In many other trades (s)he would be called a "drafter". And engineer has many other responsibilities, most of which are related to management.
An engineer has to ensure that the project is technically sound, but also that it meets the requirements - that means time and budget as well. (S)he needs to be able to communicate effectively with customers, management and programmers in order to see this done. Quality comes through discipline, not random change, which means that knowing about and adhering to best practices are a huge part of an engineer's job.
Software Engineering (Score:2)
More Precise (Score:2)
Programmers have to be a hell of a lot more precise. When anarchitect screws up and the floor is 0.1 degrees from being level, no biggie. When a progremmer makes a similar-scale mistake, say hello to a remote root exploit or two.
Re:More Precise (Score:4, Interesting)
I think you are wrong. Remote root exploits are caused by much bigger errors than "0.1 degrees". Oversimplifying, such security bugs can be set into two classes:
The first problem should never happen with an experienced and competent programer. That kind of "mistake" is reckless programming. The second does happen, but designing the entire system properly will minimize the damage these errors can cause.
The heap and stack pages should not be allocated executable by default. If a special program needs the ability to write and execute code itself, it should use a special memory allocation routine. Executable code pages should not be marked as writeable. All programs should not be run as root, or if need be, run as root and drop to normal user status as soon as possible. For those programs that do require root, the kernel should be evaluated to see if a permission system can be used to eliminate this need. That way, a program which needs raw access to the video card can't mess with critical files or deactivate the door locks to your top secret room.
The kernel needs similar checks. High level things such as the TCP/IP stack should not be able to modify any I/O ports or hardware memory, only the network card driver should. If possible, hardware drivers should not be able to access any device they don't cover. For example, the network card driver shouldn't have access to video memory. In fact, a permission system should be applied to parts of the kernel. TCP/IP, network card drivers, video card drivers don't need to access hard drives, filesystems, or door locks at all, therefore they should be denied access wherever possible.
Architects and various engineers all design so that one minor mistake or unexpected event will not cause their building/device/whatever to come crashing down. Sometimes a manufactured part doesn't exactly conform to spec, many engineers know this. If your calculation shows a point will have 100lbs of stress, you can't expect a bolt rated for 100 lbs to be good enough. It may have a defect where it will only hold 90 lbs. Someone may put 110 lbs of stress on it. All sorts of variables can and do happen. That is why a good engineer will design beyond the spec. Software needs to be the same way. Yes, doing these precautions will cost extra memory, cpu time, and coding time, just like these precautions cost extra money, space, and design time in other fields.
Re:More Precise (Score:1)
A Software "Engineer" is someone who slaps some code up and says fuck it, the beta testers (read: customers) will find the bugs.
I'll try (Score:3, Interesting)
The things you typically trade off are speed, manpower, memory, diskspace, cost, delivery, algorithms, complexity etc.
If you're not trading things off, then you are a technician, not an engineer.
Name That Quote! (Score:2)
Re:Name That Quote! (Score:2)
http://www.crl.mcmaster.ca/SERG/parnas.hom
Honestly though (Score:5, Funny)
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.
Re:Honestly though (Score:2)
I'd argue that writing recursive, six-dimensional, self-modifying code has nothing to do with engineering. Engineering is about managing risks, among other things. Self-modifying code sounds risky: how do you know the code isn't modifying itself wrongly? Also, remember that "clever" code should be avoided if possible since it becomes impossible to maintain unless rigourously documented and unit-tested.
Re:Honestly though (Score:2, Informative)
I would hope that the employee would consider the cost & availability of said hardware, vs. the dollar amount of raise before making that decision. If not, I would certainly question their ability as an 'engineer'.
Re:Honestly though (Score:1)
Re:Honestly though (Score:2)
Your "MIS punks" make far better software engineers than cocky computer science geeks who don't understand or give a shit about risk management, or delivering the right product, on time, and in budget ... which is what software engineering is about.
As with most other posters here, you think software engineering is leet programming skillz. Wake up. It is a serious business discipline that is responsible for the production of quality software.
Quality means what the user wants, in time, on budget, and reliable and maintainable. This means using processes, methodologies and best practices. Rigerous design, clear documentation, source control, configuration management ... these are the concerns of a software engineer.
Compiler design, physics, calculus? Specialist knowledge that may be required on certain projects. If so, hire a specialist. Engineering is an applied science. Did you get that? Repeat after me: Engineering is an applied science.
If you need to design algorithms, improve the effectiveness of a compiler, model the universe ... get someone with a theoretical degree. That's what computer science is: a theoretical degree. You study THEORY; the only reason you do programming is so that you can get some application of that theory. Maths, physics, computer science; they all have practical application, but a graduate of one of these subjects is skilled in theory, not practice.
Engineers apply the theory developed by theorists. They need a working knowledge of the theory, not a knowledge of deriving the theory. In projects that include system reverse engineering, SCADA/MES, cryptography and high availability services, I have yet to see any engineer or developer in my teams need knowledge of ANY of the areas of theory you have mentioned. They simply aren't important to the discipline that is Software Engineering.
Apart from the rest of the crowd? (Score:2)
Definition (Score:1, Interesting)
I am a 4th year Bachelor of Software Engineering Student at Monash University in Melbourne Australia and that is pretty much the standard definition that is drummed into us constantly.
Hasn't anyone read a textbook?
Re:Definition (Score:1)
software engineering is a very young craft. It's controversial, the methods are controversial, question all assumptions, especially the one's your proffessors implied you didn't have to question (what... I don't need lisp?)
Still, I like your definition. Too bad there is one way to accomplish it, although the CMM give good directions to the promised land.
Software Engineering... (Score:3, Interesting)
Software Engineering != Computer Science.
My university [which will remain nameless] supposedly got in trouble with Professional Engineers Ontario because its Computer Science grads were calling themselves "Software Engineers" when there was a Software Engineering program running. After that, computer science was forked into computer science and "Software Design".
In Ontario, its illegal to call yourself an engineer of any kind without going through an accredited program. MCSEs are allowed to call themselves "MCSEs", and not "Microsoft Certified Systems Engineers".
Software Engineering != Programming.
The reason why it gets no respect is because its new, hence the earlier post that it is simply "akin to sanitary engineering" is just dead wrong. The argument that software engineers are sloppy "because if we built bridges the way we build software" is also useless for the same reason. Let the practice of Software Engineering mature.
Regulations are less than 10 years old. Imagine what Mechanical Engineering or Civil Engineering was when it began. Does anyone remember the building that twisted when subjected to wind?
Software Engineers != Programmers.
The bastards who wrote Slammer, Nimda, SirCam, Code Red, Klez (need I go on?) are programmers. Anybody who writes a program for release is a programmer. Software Engineers are obligated to produce good code (and other design documents) because they are subjected to a regulatory body (similar to the Bar for lawyers). This is at least true in Ontario.
So what is Software Engineering again? Take computer science, programming, engieering principles, legal obligations and ethics and combine them.
Re:Software Engineering... (Score:2)
What if the code they wrote is good, and documented? then would they be engineers?
Ethics has nothing to do with engineering. A Modern military aircraft is a marvel of engineering, but its primary use is for Killing people. Some people would call the less then ethical.
Re:Software Engineering... (Score:1)
If the code that they wrote is good and documented, then they would be good programmers. If they had X years of experience in the field, and passed a certification exam, and signed off that the code was good and that they took legal responsibility for it, then they would be engineers, in the context that the grandparent means.
Ethics has nothing to do with engineering.
Ethics have nothing to do with engineering? _Now_ you tell me -- that's two credit hours of my life that I won't get back! Some people may think that military aircraft shouldn't exist; those people probably do not design military aircraft. However, engineers also have documented ethical codes that they have to follow -- for example, not misleading people or concealing a danger to the public. If a PE is found to be in violation of those codes, they can lose their certification, just like a lawyer can be disbarred.
Way back machine. (Score:2)
Interesting note, while a Systems Engineer for a top two IT company, we were told that they would be renaming the Architects. It appears that some words (Engineer, Architect) have legal meanings in some states. Apparently in some states you cannot call yourself an engineer unless you can prove certification by a standards body.
IANAL, but I would be interested in hearing from one on how that gets resolved.
zerg (Score:4, Insightful)
Management does not like cowboys. When they say "BUILD ME SOFTWARE RAAWR" they usually want some sort of estimate of when the software is built, but more importantly they want to know what the likelyhood of it being built is. Single programmers cannot build large software on their own, so (large) teams of programmers must efficiently work together to get things done. Software Engineering is the who/what/where/when/how/why of building large software with large numbers of people.
I might start here... (Score:1)
Software Engineering is... (Score:2, Insightful)
No, really, I loved my job so much I retired early. Now, computers are fun again.
Simple concept. (Score:1)
It means "the quality goes in before the name goes on" [theregister.co.uk].
What is Software Engineering (Score:2)
Social responsibility (Score:1)
Re:Social responsibility (Score:1)
As a legal term (Score:3, Interesting)
First, a software engineer must be an engineer. I have a bachelor of science degree in physics and master of science degrees in mathematics and computer science. In most states, I cannot even take the licensing exams and never will be able to unless I go back to college and get a bachelor's degree in some engineering field from an ABET-acredited school. (In some states, anybody can take the exams. Either way, my "liberal arts" degrees don't count for anything. Some other states consider math, physics, and chemistry bachelor's degrees acceptable, but not computer science degrees.) At any rate, the exams cover general engineering: electrical, chemical, civil, mechanical, industrial. The goal is to ensure you're a well rounded engineer.
Second, some states (at the urging of the local professional engineering societies) think any "engineering" effort must have at least one licensed engineer. This is a bigger deal than it might first appear.
Sure, I'd like to see someone who knows civil engineering involved with every non-trivial bridge that's built, and if Union Carbide built a chemical plant next door, I'd like a chemical engineer to be checking things out. (See also below.)
However, sometimes (Texas again) embedded software development projects are considered close enough to "engineering" to require, under law, at least one licensed engineer to be involved. Those civil and chemical engineers are considered qualified; with a master's degree and twenty years of experience, I am not.
There are a handful software professionals who are licensed engineers. (Want to guess what state they're in?)
Having said all that, let me say this. All the traditional engineering fields have universally understood, univerally accepted bodies of knowledge, usual captured as some kind of code (as in "building code"). That's why I feel the way I do about bridges and chemical plants. On the other hand, while most individual software engineers think they have such a body of knowledge, no two agree on what it is. There is an effort to define this [swebok.org]; a draft version "is ready for field trials for a period of two years."
Even a school that offers a "software engineering" degree says [msoe.edu], "There is no universally accepted definition of software engineering, though there are elements of a forming consensus."
My humble opinion? Engineering disciplines have with good mathematical foundations: here's the equation for the tensile strength of steel, here's the formula for voltage as we increase power. Software development efforts do not have such a foundation. Some attempts [google.com] have been made to provide one, but they're almost never applied.
P.S.: I do not live or work in Texas.
Re:As a legal term (Score:2)
Lets say you pas said exams.
Now you sit down to do some engneering.
If the person next to you did not pass those exams, but do the exact same work as you, they are also engineering.
Software engineering DOES have such a fondation. Unfortunatly most people don't know how to use them, or what they are.
How fast do the switches move. How does the Compiler handle pipes. Software gets used a lot more then bridges and building, and it gets a bad rap for thnkgs outside its design specification.
If Bridges were held to the same standards as software, the architects would get blamed every time some drunk crashed into the guard rail.
Software engineer vs programmer etc (Score:3, Insightful)
Software engineers, if we define them as academic folks, do praise prediction and development processes. My experiences are that some of them do not consider development time as a valid design criteria. For them there are only one way to make the solution, the 'right' way. Often this means that they run out of budget or miss their time-to-market window.
Programmers on the other side, as I see myself, are often tied to a delivery time, a black box definition and some constraints in terms of design. A programmer can vary from 0 to 100 times in effeciency depedning on talent and circumstances. Given an algorithm, tools and a reasonable deadline a programmer will deliver. Any obscticle on the way is a challange and makes a thrill. A delivery is good fun!
A software engineer doesn't vary as much as a programmer in skills/talents and does often know how to work in teams better. Facing an obscticle may sometimes ripple down to massive re-analysis and re-designs to get it 'right'. A delivery is a scary thought, since most time have been spent analysing the problem and understanding the design, not coding, so ofcourse there will be bugs, but where??!!
A 'hacker' is a talent and a 'cracker' is a prank.
To rip Mark Twain (Score:1)
Software Engineering is to Engineering as Lightning Bug is to Lightning
Software usually isn't Engineering (Score:1)
You can't engineer most software, for the same reason you can't engineer a book; it satisfies emotion, not logic. Most of the time, "success" or "failure" of software cannot even be defined! (see staggeringly successful, stupid and unreliable systems such as Micros~1 Windoze(tm)). Failure in engineering projects is usually, tragically, easy to define (see "Columbia").
It simply takes a different kind of duck to do software than it takes to do engineering. Have you ever met someone who can remember what they had for breakfast on July 23 1993, can remember the specs on a specific type of transistor, but can't come up with a efficient method for solving some seemingly novel problem? Thats an engineer. Ever met someone who, in a "eureka" moment, manages to re-frame a sticky problem so that it suddenly becomes solvable? And then turns out the code to do it in an afternoon, and it works first try? That might be a Programmer. Sometimes, you might even get both in the same package (you'd call him a Genius). But usually, people that are good at engineering, are very frustrated by programming.
I just hope to sometimes be called a Programmer.
Looking at how the law defines it.... (Score:1)
So it appears to be more managment of the "cheap labor" of the construction workers to make sure they don't kill someone, or waste an ungodly amount of money.
As far as programming goes, there is no cheap labor involved, and the detailed specification is the end product. So there isn't, and will probably never be anything that is analogus to an EE, ME, or IE. But that doesn't mean programming is any easier.
Social Responsibility (Score:2)
And from my, admittedly narrow, view of software engineering, I don't see that sense of social responsibility. I design oil refineries for a living, and to do so I use some high end engineering software packages to simulate new plant designs. Using software allows me to evaluate more options faster and to design to tighter tolerances. This is more efficient, and engineers and their clients love efficiency. But if there is an error in the software I use to design this plant, the software company will in no way take any responsibility. I know this going in, and because I have a lot of experience with what does work, I know how to spot a software result that doesn't. The ultimate responsibility lies with me. And until I see software engineers taking that kind of responsibility for their products, I really can't see considering them as engineers. I have yet to see any piece of critical software that doesn't have disclaimers on it.
Hey, I'm a professional, and like other professionals, I have a vested interest in maintaining the standards of my profession.
Re:Social Responsibility (Score:2)
What if your design was perfect, but it was implemented by the builders using substandard components? Say, for example, they chose a cheaper grade of steel than the one you'd specified? Who would have the responsbility then?
Physical systems are specified from the ground up (literally, unless you include the basement... :-) ), and you have full control over what's happening. A software system relies on a myriad of components - function-specific libraries, OS libraries, the compiler, the quality of your hardware, interaction with other installed programs...there's far less control over the final product.
None of this is meant to make programming sound harder or loftier than designing oil rigs, it's merely to illustrate the environmental differences which is what leads to the lack of guarantees in software.
Cheers,
Ian
Re:A software engineer.. (Score:1)
Re:A software engineer.. (Score:2)
Example: in response to someone accidentally typing "way to much" instead of "way too much", saying "Way to much! You much like a pro!"
Flame-bait's goal is to get other people to get angry and reply. To "incite an online riot", as you say.
Example: going to a women's rights discussion group and saying "All Women who have abortions are murderers and those who die in clinic bombings DESERVE what they get"
There is of course a blurred line between the two. If someone is posting for no reason other than to be flamed, he is flamebait and a troll. Of course, if someone is posting something to provoke people, but only because he believes in what he is saying and is willing to back up what he says, moderators have no place giving it a "flamebait" rating- it is more likely that "offtopic" would be more suitable.
Generally, if a post does nothing but lower the average intelligence of the discussion, but offers little room for a response, it is Troll. If the same, but seems to beg response, it is Flamebait- it wasnt that the person said "Abortion doctors should die", it was that they said it in a women's rights board which made it flamebait.
the moderation "Flamebait" should be used sparingly. There really are very few flamebait posts, and those which are flamebait are made by Trolls anyway- you would be safe moderating all such posts as "Troll"
And finally: Don't thank people in advance you fucking cocksucker.