Slashdot Mirror

If you think you're "missing something" regarding software engineering, have a look at the SWEBOK, published by computer.org. It's a bit out of date, as it's lacking in security and quality sections, but it does have a compendium of knowledge.

As far as the actual practice of software engineering at a large company goes, my list looks like this:

1. Testing, and particularly developer-driven testing using automated unit tests. Why are you writing code if you can't prove it works? More importantly, why would your boss pay you to write code that you can't prove works? Really, if you learn nothing but Test Driven Development, you'll already be ahead of 50% of the people who call themselves programmers (including 50% of the commenters above spouting nonsense like "just keep doing what you do".) Of course, once you truly get it you'll realize that it touches all the disciplines of software engineering and design, and that a well-written test serves as your best documentation. And don't forget usability testing.

2. Design patterns. Civil engineers understand materials and shapes, and use tested and measurable components to accomplish tasks. A civil engineer doesn't need to reinvent the I-beam to build a bridge, they know the I-beam pattern exists and that that if they use them, they obtain performance of X, but have requirements of Y, and side effects of Z. Similarly, a software engineer should understand patterns serve a somewhat similar function in our domain. Pub/Sub will act this way, and it scales this way, but doesn't address retries. Note that patterns are abstract concepts, which makes them distinct from libraries or frameworks. I trust a pattern, because it's mathematically understood to behave a certain way. I don't have the same implicit trust of libraries and frameworks, because those are code implementations that may or may not be 100% correct.

3. Design principles. I like the SOLID principles myself, as I think they're exceptionally clear.

4. Security. Understanding concepts like default deny vs default allow, input validation via whitelisting or blacklisting, sanitized outputs, etc., are crucial in the modern world. Check out OWASP and SANS for long, long lists of reasons why security matters to software engineers.

As an engineer, it turns out there's an awful lot you have to do that isn't directly programming, but is still important, either to you, to your software, or to your company. So the list keeps going.

5. Estimating. If you end up at a shop that isn't at least Agile (I am, and I wouldn't recommend it) you'll have to provide estimates. Experience is the primary teacher here, but you may find modeling tools like COCOMO II to be valuable.

6. Code reviews. Understand how to hold an effective peer review, one that helps improve software quality without making the coder feel like an idiot, or afraid for his next review score.

7. Methodologies, processes, metrics, regulations, standards, and governance. Waterfall, iterative, RUP, Agile, emergent design, test-driven, behavior-driven, lean, all are processes for writing software. Processes also cover things like source code management practices, defect tracking and fixing, project management, etc. At one level metrics are useless things managers want to see regarding productivity, but as an engineer you can use them to help understand code written by others. Standards and governance likewise exist primarily to make the people signing the checks feel like you're doing something for them. They may not matter in a one-man shop, but when you're in a big organization, leading teams of developers, or working with offshore teams, these take on a level of importance that you unfortunately cannot ignore.

There's a pile of other stuff, of course. Data modeling, software architecture, packaging, deployment, languages, the UML, optimization, encryption, key management and certif

Yes, there are obstinate and stupid people out there, but not everyone with those questions is either. And the moment we respond to a question like the one above with a groan or a "duh!" comment, we do become condescending and anti-business.

You're too kind. They've taken a chunk of my sanity, having to resolve arguments by defining words only to discover their meaning of the word sort. It's because their vocabulary is too limited to use the right word, or any other word, to describe what they want.

Careful, that's also a steep slope down into being labeled anti-business. We all have to deal with users whose only stated requirement is "Make it work like how I want it to work!" Everyone in IT knows that the users themselves are not capable of describing in perfect technical terms what they need. A good business analyst learns how to probe deeper to uncover the real requirements, and to uncover a more complete set of them.

It sounds like you could benefit from learning a few techniques as to how to elicit requirements from your users. Check the SWEBOK, and see Chapter 2 section 3 for ways to get at them.

Programmers have to learn the gist of how a business works, in order to do their job.

Someone on the IT side has to understand the business problem domain and be able to speak the language of tech. Whether that's a developer or a business analyst is more a function of your company's structure than anything else.

Take a look at the chapter 3 of the Software Engineering Body Of Knowledge. It's the most complete source of information I've ever found on the subject (and the project is managed by the University where I did my master's degree !! ). Of course, check the list of recommended references for more information.

The question is, is this more to do with the field than the fact that they received their degrees overseas? Engineering, medecine, accounting and other business areas strike me as fields where there'd definitely be some difficulty in finding jobs outside of the degree-issuing country because each has very strict rules in practice that differ from one country to the next. Thus, immigrants might come in to the country as valid skilled workers, but realistically can't get equivalent jobs to what they could get in their home countries because they weren't taught up to the standard required in the new country.

Now, unless something like swebok gets its way, there isn't as much of a standard practice in CS and thus foreign degrees shouldn't, in theory, be shunned... I think?

As for foreign experience being of no value to employers, I'm really not sure what to say. Maybe it's politically incorrect to say so, but it's possible this is more of a factor in new immigrants rather than expats, because immigrants really have nothing to account towards being able to fit in with the local culture. Someone who expatriates themselves for education or work might not be seen in that same light. At the same time, I have a hard time believing the original quote--would you turn someone down if they worked at Ericsson or Nokia?

Developers in the US, in addition to not working for 4K/year, do not generally get the benefit of a methodology. While nobody in their right mind would send work offshore without a very clear statement of what they expected, careful management of requirements and deliverables, and a detailed plan for implementation, the same people will expect their local team to produce a product with none of those benefits.

A quick study of the decades old literature of Software Engineering would reveal that if US developers worked to the conditions of foreign development groups huge amounts of money (50-75%) could be saved. That would reduce the difference between off and on shore projects by so much it would make little sense to send most work offshore. With both wage and efficiency differences against them, US developers will watch their marketshare decline.

What do I think US developers should do? Well, first of all, start or at least support efforts to get project management, methodologies, and other efficiency improvements implemented. Learn architecture, requirements management, design skills, and other elements of Software Engineering. Get your employer to pursue CMM or other standards-driven objectives. Then, continue to work like H*ll (but smarter this time) and the erosion may well reverse.

I disagree with Dave Thomas in that I think the trend can be reversed if only we can adopt processes that improve efficiency and quality. I am not ready to concede our livelihood to others when I know that it needn't be that way.

Remember that the US car makers lost huge amounts of market share until they improved their quality and adopted the originally US-invented (AT&T) quality processes that the Japanese had implemented so very well. Now, the Japanese are building cars here, using their processes and our people to compete with the US manufacturers. That, alone, should show that it is not the pay difference but the process difference that matters.

Software Engineering started in the 60s and 70s and has been ignored by too many for two long. What is Software Engineering, you say? look at computer.org and swebok.org for the Software Engineering Body of Knowlege (SWEBOK) for a not so quick overview.

... there's the IEEE's effort on what's called the "sweet box of software body of knowledge."

Clearly you know nothing about software engineering, or you would have concentrated on knowledge encompassing project management, best practices and quality assurance ... in much the same manner as civil engineers don't lay bricks.

The Software Engineering Body of Knowledge is an international effort to codify the knowledge involved in software engineering, in the same way as other engineering disciplines do, with intent to standardise a SE qualification.

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 for more information.

Please read the Software Engineering Body of Knowledge and stop calling yourself a Software Engineer.

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 at CMU and the Software Engineering Body of Knowledge (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:

• Managing resources (budget, time, people / expertise)
• Understanding user requirements
• Designing a solution using Best Practices
• Have the technical knowledge to evaluate possible technologies for the solution
• Have technical knowledge of design and implementation principles (algorithms, data structures, methodologies, patterns)
• Introducing predictability and risk management into the development process (software process management)
• Implementing the solution, or overseeing the implementation
• Communicating

Management (including risk management, project management and Best Practices) is a more important skill for an engineer than development.

To call yourself an "engineer" in several of the states in the U.S., you must pass two licensing exams. Texas in particular has been known to come down hard on people who use that title without taking the exams and being a licensed engineer. That's why I call myself a "software developer" instead of a "software engineer" if I can help it.

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; a draft version "is ready for field trials for a period of two years."

Even a school that offers a "software engineering" degree says, "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 have been made to provide one, but they're almost never applied.

P.S.: I do not live or work in Texas.