After the Gold Rush : Creating a True Profession of Software Engineering

Thanks to Jason Bennett for sending us a review of author Steve McConnell's lastest book After the Gold Rush. The book looks at the maturation of software development and what that means for us. Click below to read more. After the Gold Rush : Creating a True Profession of Software En author Steve McConnell pages 182 publisher Microsoft Press, 11/1999 rating 9/10 reviewer Jason Bennett ISBN 0735608776 summary One impression of the maturation of software development

Background

I've always been amazed that certain fields of endeavor exist in which many people prefer rank amateurs to trained professionals. I don't know many people who would choose their neighbor's kid to perform surgery, or hire a journalist to build a bridge, yet every day software development shops hire people whose only training is that they have read some book on Visual Basic or C++ or Perl, and put them to work on major projects. In fact, in the software development business, experience can sometimes be a liability (see the debate over immigrant programmers and age discrimination). Don't worry, you won't have to apply for a license to write code, and no one is going to confiscate your keyboard if you design your own web page. Accountability, however, is another story....

What's the book about? Steve McConnell, author of Code Complete , Software Project Survival Guide , and many other excellent books on software engineering, has returned. For those of you who might not be familiar with him, Steve is President and Chief Software Engineer of Construx Software, a software consulting firm based outside of Seattle. He's also the Editor in Chief of IEEE Software, and is generally regarded as one of today's best authorities on how to do software the right way. In After the Gold Rush, Steve gives his view of where the software world should go from here.

Currently, people don't know how to build software. Or, to be more accurate, there are good techniques out there to build software, but most people ignore them for one or more reasons, none of which hold up under close scrutiny. In addition, software development depends on death-march-style schedules, whereby programmers wreck themselves trying to get the software out the door at the appointed time. One major problem is that the developers are not trained in writing software in the first place. They are either trained in computer science, or some totally unrelated field. To compound this problem, very few if any continue their education in such areas as professional reading or training.

There is hope, however! Now that software development is moving out of its "gold rush" period, where the firstest gets the mostest, we can begin to develop software engineering as a profession. This means training people in engineering instead of science, and defining what it means to be a software engineer. Unfortunately, we have a lot of work to do both on the level of education, and in the mindset of today's software developers.

The third and final part of ATGR dwells on the future, especially as it relates to what these developments will mean for software developers of today. I'll spare you some of the suspense, and tell you that you won't be forced to be certified. Does anyone really care if your desktop clock was written by a true engineer? On the other hand, you bet I care that my air traffic control software and my medical scanning software and my car's control software were signed off on by someone who knows what he's doing. Licensing will be in software engineering what it is in other engineering fields: required in some areas, meaningless in others. In the end, however, software will be better for it.

What's Good?

Personally, I greatly enjoyed this book, mostly because it says what I've felt for some time now. The development of true software engineering will be akin to the development of true medicine. We will be able to move ourselves from the Age of Leeches to a more enlightened age where quality and process matter. McConnell makes a compelling case for why events will transpire in this way, and what the benefits are. No one thinks that these developments will be some sort of panacea or silver bullet, but when true software engineers, complete with a code of ethics and a professional organization, are responsible for developing software, there will exist an undercurrent of ownership and responsibility that currently does not exist.

What's Bad?

There's not much I didn't like about this book. If you develop software for a living, read this book. It describes where your industry is going in the next twenty years.

So What's In It For Me?

Maybe a lot, maybe nothing. If you develop your software purely as a hobby, these events won't directly effect you much. You will never need a license just to write code. If, however, you belong to that cadre of programmers that likes to think of themselves as "software engineers," or who would like to think of themselves as such, read this. You won't be forced to take a test tomorrow, but software development will never be the same.

Pick this up book up at ThinkGeek.

• Table of Contents
• Acknowledgments
• Introduction
  1. The Tar Pit
     1. Software Dinosaurs
     2. Fool's Gold
     3. Orphans Preferred
     4. Software Engineering Is Not Computer Science
  2. Prospecting
     1. After the Gold Rush
     2. Engineering a Profession
     3. Ptolemaic Reasoning
     4. Body of Knowledge
     5. Novum Organum
  3. Through the Pillars
     1. Stinking Badges
     2. Architects and Carpenters
     3. Hard Knocks
     4. The Professional's Code
     5. Alchemy
• Epilogue
• Notes
• Index

Comments

Re:Humdee dum dee dah

[dennisp]

"The worst problem I see today with the software-creation process is design. Programmers design software (I design software, and I am a programmer). However, the people who are writing code for software should not be allowed to design that same software"

I don't know about that. However, I do get a lot of peer review and help along the way (as well as 1001 new client demands to sort out).

Moving out?

[gorilla]

"Now that software development is moving out of its "gold rush" period, where the firstest gets the mostest,"

Seems to me that the pressures of 'first to market' are getting worse, not better. The marketing message is "Who cares how buggy it is, as long as it's available now?"

Re:Moving out?

[helarno]

Think Microsoft.

Then tell me that "bugginess" doesn't catch up to you. It just takes a while.

Re:Moving out?

[JordanH]

Hmmm... Microsoft just had a record quarter. Hasn't caught up with them yet.

There are warnings, including Microsoft's own announcements, that there are storm clouds on the horizon for Microsoft. I doubt that Bill Gates moved over to let Ballmer bask in the glory of every increasing profits.

By all accounts, Windows 2000 will be their most stable OS since DOS 6. A pretty amazing feat considering the umpteen millions of lines of code.

Now, what message will THAT send. Big software company puts out buggy, unstable Operating Systems, year after year to ever increasing profits. Finally, they put out an OS with greatly improved quality and profits turn down.

Software quality problems are not essentially problems of the "professionalism" of the practitioners. Management sets the tone. If they ask for bad products to meet arbitrary "market windows", they get bad products. Note that Microsoft Management made a priority of quality with Windows 2000 and things seem to have improved. It's just that simple.

Ultimately, it's not really management's fault either. The market windows are REAL. Businesses that put out good products too late, after other products have staked out the market, do suffer. The problem is customers who are willing to put up with low quality software.

-Jordan Henderson

Re:Humdee dum dee dah

[Foogle]

Well sometimes it can't be helped. I work for a very small software company that simply can't afford to pay for people just to design software. But any larger software developers (this includes Open Source) should be splitting up the tasks.

Interface design should be handled by a team separate from Programming. In this situation, the design is never built around code-logic, and therefore does not present the user with an interface based on the logic of the code. An interface should have logic of its own.

This is not to say that a programmer can't handle design as well as coding (certainly it's been handled gracefully before), but just that as a good guideline they should not. Moreover, I'll stick to my original statement: The worst problem I see today with software is design.

-----------

"You can't shake the Devil's hand and say you're only kidding."

Management, anyone?

[PD]

The problems with software engineering are fundamentally a management problem. It's been many years since the "Mythical Man Month" showed us how adding programmers to a project can only make it later because of communications overhead. But, many many managers are still doing just that. Furthermore, many managers are afraid of the technology, proclaiming loudly that they don't know anything at all about programming computers; good managers can manage anything at all without knowing about it.

Gantt charts and org charts are something that programmers should never see. But yet in many companies I work with, you can't get anything done unless you've got a big graph of the organization to help you find someone who is high enough to have some weight, but low enough to actually have some brains.

And even worse, technologies are often driven by management needs. Software costs too much, so all the managers want to get some of that good object orientated stuff on the project. So, they hire a few C++ programmers out of school and give them Visio. The programmers are told that their highest goal is re-use. Never mind that the system they are building is meant to handle 320 contradictory/arbitrary business rules for selling widgets to a client in New Zeeland. So, the programmers dutifully build the system to be as re-usable as possible. And, those 320 business rules never get used anywhere else but New Zealand. Meanwhile, the primary goal of re-use has caused the maintainability of the system to go to hell, because management ignored the faster/cheaper/better trichotomy and gave the team a week and half to design the system.

I could go on and on and on about management horror stories. Every place I've ever worked has been the same way, and a lot of those places were Fortune 500 companies. Books outlining ideal software development worlds are great. We really need some new ideas in that area. But how much progress can we make if our managers have never READ the books?

Re:Management, anyone?

[0xdeadbeef]

The sole purpose of corporate IT is to enable and support management objectives. It serves no purpose otherwise, and wouldn't even exist.

And managment objectives exist to enhance shareholder/owner value, which is done by bringing products to market in the most efficient manner possible. So you could say that technology is driven by the market's needs, and that managers who misdirect the development of technology to satisfy their own unpractical whims (ie, buzzword compliance, irrational attachment to specific languages/platforms/etc) are in fact causing a problem, which is what I think the original poster meant by that statement.

And remember, a lot of developers aren't in corporate IT, they are themselves developing a product, and most likely understand the product and related technologies far better than management.

So get off your authoritarian high horse, management can in fact be fallable. :-)

If the programmers think they could manage the company better, there's nothing stopping them moving into management themselves.

Except politics, glass ceilings, an aversion to pretentious clothing, etc. I should quit now, their spy programs are watching...

2000: Where To?

[washort]

The art of programming has come a long way since its modern inception. Advances have largely come in stages: the advance from hardwiring to machine language, from machine language to assembler; from assembler to low-level compiled languages; and from low-level compiled language to high-level compiled (native and virtual-machine) languages.

The question now becomes: what next? What obstacles exist to the advancing of the art?

In my opinion, one of the main obstacles is the widespread use of C and C++. Both are low-level languages designed for close interaction with the hardware. (C++ may share features with high-level languages but is too tied to C to actually be an HLL.) This is a useful design for many tasks, but not for general application programming, at least at this time. Moving to safer, more powerful languages (Smalltalk, Dylan, Eiffel, Ada, ML, and Haskell to name a few with useful free implementations) is necessary, IMHO, to further the creation and maintainability of complex software systems. C still has its place of course -- critical inner loops will probably be implemented in many applications where the high-level language does not perform adequately -- but general development should move along to more useful tools.

I believe that the free-software community is uniquely prepared to do this, simply because language choice is a technical and not political problem.

Happy hacking.

It not just the coders

[spiralx]

Currently, people don't know how to build software. Or, to be more accurate, there are good techniques out there to build software, but most people ignore them for one or more reasons, none of which hold up under close scrutiny.

Yes unfortunately most people who program have learnt to program well before they come into any contact with actually being part of a team writing a large application. When it's just you sitting in your room at home coding something just for the sheer hell of it your style of coding and the method you use to design and implement the code are relatively unimportant. I'm sure the most popular method is the 1) Think of something you want to code, and 2) Sit there and start coding it as soon as possible :) Unfortunately this doesn't, in my experiance, work at all well for larger projects.

The software house I currently work for has a lot of problems with how the project is managed. The man in charge of the overall development for our application is far more interesting in trying to code things which have caught his fancy at the time than in making the product consistant, efficient or even bug-free. Designs have generally been of the "here's what we want - go do it" kind, and once someone has done a particular client, they're the only person who knows exactly how it works. When people leave someone else needs to spend a good two weeks just trying to figure out the code. We've recently started to move into a more structured approach to coding, but it remains to be seen whether this will have any impact.

Now that software development is moving out of its "gold rush" period, where the firstest gets the mostest, we can begin to develop software engineering as a profession. This means training people in engineering instead of science, and defining what it means to be a software engineer. Unfortunately, we have a lot of work to do both on the level of education, and in the mindset of today's software developers.

Very true - we've got a lot of good programmers, it's just that they don't know how to write a large piece of software. This is something I see a lot of, and it seems that it takes not just good programmers, but also a good structure for them to work in, to produce something that is consistant, efficient and can be easily maintained. For people out there involved in the same sort of work ask yourselves - if everyone involved in your project left at once, how long would it take for a new team to pick up where you left off?

Re:Humdee dum dee dah

[jilles]

It's an illusion to think that design and implementation can be separated. Software development is an iterative process rather than a linear process (req->des->impl->test->deploy). Separating design and implementation therefore is a bad idea because the design would get outdated rather quickly (and since time is money most companies wouldn't bother updating them).

In the case of OSS you'd have complete anarchy where the design people would simply be ignored if the programming people would disagree.

Rather I'm in favor of having an integrated approach such as in TogetherJ where design level changes are reflected in the code and vice versa. When working in a project you typically let the more experienced design people work on the designlevel while the programmers fill in the details. Since changes in design affect implementation and vice versa both coders and designers are forced to think about each others work. This leads to interesting things as a coder discovering design flaws and communicating with designers to solve the problem Similarly designers learn about implementation issues for their beautiful design since what they do directly affects the code.

"The worst problem I see today with software is design."

Well I think the problem really is lack of design. Often coders are ahead of the design team after a while. I.e. the design team is strugling to capture the current implementation rather than designing the next version. This leads to interesting stuff like "the source is the documentation".

Bah, humbug

[joss]

I have a degree in CS, 10 years professional experience, and I think this is misguided. Try as hard as you like, software just isn't like other "professions". Of course experience counts, but trying to become like other professions with certificates and other bullshit is the worst thing we could do. Professional bodies exist to monopolise fields of study and provide a bar to entry. Organisations like the American medical association and the Bar council are just protection rackets. There only purpose is to raise the salaries of those in the club, not "protect the consumer". We should irradicate them, not copy them.

Writing great software has more in common with writing poetry than law, medicine or even civil engineering. You can stuff huge organisations with "professionals" following "best practice engineering" and they'll still get trampled into the dust by a couple of smart kids working in a garage somewhere. I'm not saying you should hire any old moron to write software, but the trick is to have clueful (developer) managers and they can make up their own mind as to who to hire. Organisations *should* have the right to hire the neighbourhood children to write software, just like they have the right to go bankcrupt.

If you want to see something sensible on programming check out the programmers stone at http://www.melloworld.com/reciprocality

Re:Bah, humbug

[jacobm]

Professional bodies exist to monopolise fields of study and provide a bar to entry. Organisations like the American medical association and the Bar council are just protection rackets. There only purpose is to raise the salaries of those in the club, not "protect the consumer". We should irradicate them, not copy them.

That's pretty harsh. Would you trust your life to a doctor who didn't know what they were doing? Would you want the poor who can't afford the likes of Johnny Cochran to try their luck with public attourneys who might well not know the law well enough to see an obvious and powerful defense for their clients? More to the point, would you want to drive your car over a bridge that was designed by a guy who thought he would like to try his hand at bridge building and who gave the city the lowest quote?

Computers don't usually have as high profiles as doctors or lawyers, but it would be pretty naive to think that their flawless operation is not increasingly critical to first-world society. (Can you imagine what would happen if the software that runs Wall Street turned out to have a bug that misreported stock prices in strange circumstances? Just a teensy example.) And Microsoft has a built-in feature in every copy of Windows that says, in white letters on a blue background, "Market forces do not ensure high-quality programming."

It is increasingly important that we not only have high-functionality programs, but also that we have highly correct programs. Unfortunately, it is obvious that the industry doesn't have a good way to produce them. Does that mean that an equivalent of the bar is required for programmers? I dunno. I sort of like the idea, myself, but I would be happy with any system that ensured that all software products that were sold had at least a reasonable guarantee that they were correct.

Re:Bah, humbug

[joss]

Would I trust my life to a doctor who didn't know what they were doing ?

I would prefer not to. Unfortunately, I don't have any choice, since once the guy has qualified as a doctor, he can get away with gross incompetence for decades. The "ethics" of his "profession" mean that the worst thing a doctor can do is point out that another doctor is incompetent.

> Would you want the poor who can't afford the likes of Johnny Cochran to try their luck with public attourneys who might well not know the law well enough to see an obvious and powerful defense for their clients?

Exactly my point. Profession qualifications don't make you competent, they make you complacent. They take away the power of ordinary people to challenge the priesthood. You have no right to an opinion without the professional acreditation. Watch "Lorenzo's oil" sometime.

The law is just the worst example of this. As an example, you are incapable *by definition* of determining whether you are infringing on a patent unless you are a qualified patent attorney. You could be the worlds leading expert on something, but your firm won't let you look at the patents in your field because this ruling means that there is no possible upside in doing so.

Re:Bah, humbug

[jacobm]

Ah, I think I see where our disagreement lies. I am not defending boards per se as opposed to any other method of ensuring high quality and consumer protection. I think that a licensing organization is better than nothing at all (a.k.a. "total free market," in my opinion a really dangerous idea for areas in which it is difficult to tell whether a craftsman is competent or not before something bad happens- law, medicine, civil engineering, software engineering are all examples of that), which is what you seemed to be advocating. However, I don't mean to imply that a board is infallible or that it's the best possible way to protect consumers. If you (or anyone) has a better idea, I'd love to hear it.

Re:Bah, humbug

[speek]

I don't get your examples of the lawyers or the doctor. Are you suggesting that it's the certification that guarantees your doctor is competent? Poor people do have to use public attourneys, so I'm not at all sure what your saying there.

Your bridge example is more interesting, becuase it gets more to the core of the issue. It's a better comparison to software. Doctoring and lawyering are performance skills, and thus, the skill of the person involved is the only measure to use to predict the quality of the outcome.

A bridge, however - you can test it and see how well it works. You can go over it's design to understand it's theoretical limits. Who made the bridge is irrelevant at this point (except that the honesty of the person is involved in as far as the documented design might not have been followed).

This is even more true with software. It can be tested and studied, and there are no hidden elements. It is not important who wrote it, it is only important who signs off on a seal of approval for it.

Therefore, license software, not software developers. Companies can become certifiers and guarantors of software, as a business model. Kind of like Red Hat with Linux - they service it, and essentially lay themselves open for blame for it's failures, in exchange for money

Re: Bah, humbug

[speek]

Missing apostropes[sic]?

Regarding the Tacoma Narrows, it's nice (note the apostrope[sic] where it belongs) to have a ready made example, but it doesn't invalidate my point. A license on the bridge builder wouldn't have (didn't?) made a difference. And you point out there wasn't anyway to know beforehand it would fail.

The answer to that is, shit happens - you can't prevent all of it. What you want is recourse once it does happen, and licensing the software gives you that recourse. Licensing the programmer would be a less optimal solution.

Re:Programming is design

[Foogle]

If it can't be created, it can't be created. I won't argue with that. But if a design-team is competent, they will create an interface that is best-suited to their target audience, *not* to other programmers and people who are used to dealing with shoddy applications.

A person who writes a 20-line C++ program is a programmer (they have written a program; the very act of doing so defines them as one). It does not, however, make them a *good* programmer. Sure, if you happen to be practically perfect in every way then you don't to split up the work into different teams. If you're perfect, you can write an entire operating system by yourself. You can leap tall buildings in a single bound and stare down charging llamas.

I don't know about you, but I'm not perfect. I don't write all my code in assembly either. I write it in C++ because I find it easier to break my work up into protected objects. Along the same lines, I don't always trust myself to design the very best interface for my software. I'd rather get it right then be right.

-----------

"You can't shake the Devil's hand and say you're only kidding."

There are a lot of piss poor programmers

[Greyfox]

Back when I was in college, there were a lot of people who had never touched a computer before in the CS program. They were attracted by the sky high salaries of the profession and to them it would never be more than a job.

I've found that even if you have no idea what you're doing, it's still quite easy to get a job somewhere. You can bluff your way through six months or a year an then bail and no one will question the short employment times because they're so common in this industry. The company goes out and hires another programmer and if they get lucky they find one who knows what he's doing and that programmer takes a look at the previous programmer's code, realizes that person was an idiot, and has to start the project from scratch. I've been that second programmer a number of times now.

Compounding this problem are managers and recruiters whose expectations are often very unreasonable. They'll give you three to five programmers' worth of work and set impossible deadlines or they'll plunk you down in a completely unfamilar environment because you happened to mention that you looked sideways at the environment 10 years ago.

Further compounding this problem is the fact that when you get into the "Real World" you find that they're still doing DOS and are lagging a decade behind the OSS community and educational institutions in coding practises and hardware. Several times I've wanted to completely rip out the environment we were working in and replace it with a nice clean Linux system and of course I didn't have the authority to do so.

Lately I've decided that the first company to abandon all this crap will win, so I decided to hit the management track and carve out a small empire to demonstrate this. It'll be interesting to see if I can pull it off...

Re:But what is engineering?

[dingbat_hp]

Engineering is making things that don't break any more often than you expected to, or more often than the budget allowed you to.

Re:Humdee dum dee dah

[Foogle]

That's such an elitist view of design, but it's hardly uncommon. But let me reiterate. The person who does the design should not be ignorant of programming. They should have experience in the game; enough to know what is and is not possible to implement. But don't for a minute think that non-programmers cannot create decent interfaces. You're kidding yourself it you do.

I know dozens of programmers (who are great coders by the way) who wouldn't know a good interface from a poke in the eye. And I'm not necessarily talking about aesthetics either. I'm talking about serious *interface* issues such as navigation and control. Being a programmer does not make someone a designer. The reverse is true as well, although it helps to intimately know who you are working with.


-----------

"You can't shake the Devil's hand and say you're only kidding."

Re:Two types of programmers

[jacobm]

Is that really true about experts? Can people with industry experience vouch for that as a widespread phenomenon?

I am a student, not an industry worker, but at my department (Rice University) the idea that you must abstract and reuse code as much as possible is drilled into our heads pretty unrelentingly, and is taught both in an object-oriented framework (via [increasingly] Java and [decreasingly] C++) and a functional programming framework (via Scheme and perhaps a smidgen of ML or Haskell depending on what you take and when), just so we'll be sure to get the point that the principles of abstraction aren't language-specific. I honestly can't imagine anyone who did well in our department going out to industry and writing code that didn't have a lot of code reuse built in.

Is Rice just an exceptional school?

Re:Humdee dum dee dah

[Salamander]

>However, the people who are writing code for software should not be allowed to design that same software.

I strongly disagree, for the same reasons others have. They've done a fine job explaining the problem(s) already, so I won't duplicate their efforts. Instead, I'd like to suggest what I think is a better solution than what you propose.

Here are a couple of ideas that should warm the hearts of /. types: openness and shared ownership. Yes, even if the product is proprietary, these things work wonders. The problem you're worried about occurs not because the same person does both design and implementation, but because they're allowed to do either in a bubble, isolated from other opinions and views and influences. If both the design and the implementation are laid out for other people to see and comment on, and if those other people feel that they "own" any potential bugs in the code as much as the primary author, those potential bugs will be prevented from becoming real bugs. There's nothing worse than a programmer who never lets on what they're up to, and nothing better than a programmer who realizes that leading other people through the process is even better than excluding them.

Re:Humdee dum dee dah

[Foogle]

Yeah, I think at some point or another we have all been guilty of writing code that had no business being written because the application it was being written for had yet to be fully designed. Application development is not a "figure-it-out-as-you-go" process. Decent products require cafeful planning, design and documentation. Unfortunately most products ship without a decent amount of any of those things.

-----------

"You can't shake the Devil's hand and say you're only kidding."

Commercial Software Developers are a Microcosm

[cshotton]

It's never surprising to see yet another attempt to herd the cats that are software engineers towards the greater good that is structured design. And there doesn't seem to be anything particularly interesting or new in this iteration either.

The one important flaw to note about this book is that it treats software engineering as if the lone example of its practice is in the offices of commercial, shrinkwrapped software vendors. It may surprise a lot of people to realize that the total software sales of commercial software products (including all of Microsoft's products, Oracle's, and SAP's) are only a small, small percentage of the amount paid for custom software solutions for industry, government, and the military.

In these non-commercial arenas, strong software engineering disciplines have been the norm for decades. Good design, long development cycles, and carefully engineered software are an absolute requirement when human lives are involved (air traffic control, avionics, flight control systems, manned space flight applications, command and control systems) or extremely expensive hardware is affected (factory production lines, communication satellites, telephone systems, railroads, etc.)

To lump all software developers under the umbrella of the frenzied exercise that passes for software "engineering" in the commercial marketplace is a myopic view at best and is pretty much wrong. Yes, commercial software developers could do a better job. But market pressures don't allow for this, and frankly, they never will. So ranting about making the engineers do things "better" without addressing the market pressures is a waste of effort.

Until the tools, processes, and automation that surround software engineering improve beyond handwritten code in a text editor, this situation cannot improve. If the market continues to apply innovative pressure on the developers, the only way to catch up is to give developers a higher level platform to develop from. Twiddling around in the O/S, pushing bits around in a frame buffer, and spewing characters to and from a hard disk are far, far below the level where software engineering should be practiced, yet that's what most engineers have to suffer through given the relatively primative state of operating systems and development tools.

It's like trying to build a skyscraper with a hammer and a saw.

Re:Humdee dum dee dah

[Salamander]

Lest anyone think that I'm saying the open-sourcers have "gotten it right" let me set the record straight. Closed source has its characteristic problems, some (but not all of which) can be addressed by looking to the open-source model. Open source also has its characteristic problems, which I'd say come down to lack of discipline.

The first symptom of this is that open source tends to be all about programming, without anywhere near enough attention to design, testing, documenting, etc. As much as we bash MS for using their users as guinea pigs, open source tends to rely on users even more heavily in lieu of real testing. Yes, I know, at least open-source users have volunteered to be guinea pigs and haven't paid for the honor, but I think that's an inadequate excuse for developers shirking an important part of their role.

The second symptom is lack of a means to control the jerks. I think the majority of open source folks favor cooperation, but a substantial number are more competitive than cooperative. They want to be top dog, or they don't want to be in the pack. When this attitude is recognized, they can be removed from a project by those that remain, but that recognition is often preceded by a lengthy period during which they're allowed to be obstinate and disruptive and generally counterproductive. When dealing with volunteers, it's harder to get people to shut up and do their assigned task, because there's no repercussions to them. They won't suffer for years from bad reviews or bad references, the fear of which is at some level a powerful motivating force in the commercial world not to be too much of a jerk.

As I said at the top, each approach has its problems. The benefits of open source may well outweigh the problems I've described, but it's not a panacea.

I dunno

[ch-chuck]

It depends on whether we want to have accountability - of software to run airport baggage systems (refering to an oldish Scientific American Article called "The Software Crisis" which featured the Denver Airport programming disaster) - not to mention real mission critical systems like hospital life support, nuke plants, and my payroll. The SciAm 'solution' IS adopting 'formal methodes', at least for critical sub-systems - which basically means VERY expensive, time consuming, and very well thought out, kinda like the software in the space program - it may not be 'latest and greatest' but it's GOT to work, particularly for wo/man'd flights. I'm not sure I can trust the local whiz-kid or starving artist to fulfill that role. An artist or garage band can royally screw up and the worst that happens is nobody buys their art - but I sure wouldn't want a surgeon who has to go into a trance before cutting into the old appendix!
Licensing and professional organizations may SEEM like just an exclusive club but I think they add a sense of professionalism for critical jobs - they may still screw up, but then they can be 'disbarred' and booted out, held accountable - so we don't end up with just anybody claiming to be a power engineer, and having their system crash and kill thousands with the only repurcussions being 'opps! Sorry about that!'. But that's pretty much the state of the art with contemporary software licensing - the consumer bears the entire risk of product defect liability. Read any EULA. I'd like to see software where defects mean someone's head rolls on the production end! We used to call it "bet your job".

The Scarlet Pimpernel

It doesn't have to be that way.

[Jim Hammond]

Unlike this book, I foresee an increasingly dynamic and profitable future if the government continues to allow the naturally exponential pace of innovation. Any government involvement would inevitably be a form of order-by-means-of-stagnation.

However, stuff happens, and any problem at all is a chance for a politican to champion the interests of the people, and just as with so many other fields, we would never realize the wonderous future we had given up to benefit the careers of politicians and the fears of bureaucrats.

As for why there are some problems:

The benefits of good design such as extensibility, flexibility, and reusability seem less important now that a monkey can rapidly develop software with a slick interface using today's development tools. If software needs change, it is not such a big deal to write new software.

Most businesses are also ignorant of any critical and yet not blatantly obvious requirements such as security, scalability, data integrity, and reliability.

The way that this issue will be resolved in a free market is that the more far sighted companies, who are able to build on their past technology (like MS), will eventually out compete those who want it ALL and want it all NOW. Another way that competition will solve this problem is that companies will develop tools that make it easier to develop software that has a good architecture. Such technologies are currently known as components combined with application servers. Two examples are COM+ and EJB/NAS. Yet a third free market measure is certification tests like those given by Sun and MS.

The fourth, and perhaps the best argument against government involvement, is reputation. The reputations of companies and individual developers will become public knowledge given the Internet, and thus accountability will modify their behavior. Government on the other hand is not accountable - try to stop paying taxes - try to elect someone who is not a Republican or Democrat.

Re:Humdee dum dee dah

[dennisp]

"But any larger software developers (this includes Open Source) should be splitting up the tasks."

Splitting up tasks, yes; but I feel that almost everyone should have input (as in review) on the design process throughout the project. Design is never perfectly linear.

"Interface design ..."

Uhh, I'll let the UI guys do whatever they want. They can also have input on design - as there can be conflicts between team goals.

"but just that as a good guideline they should not"

You must not be working in a very good team environment. Yes, some guys should be doing conceptual design -- but in my experience, logical design can be worked out in teams and even change as requirements sometimes do as the project progresses.

Nobody wants a software engineer

[bubbha]

As a software consultant I change jobs somewhat frequently so I go to lots of job interviews and must stay in touch with what skills the industry is looking for. Invariably, when I'm asked to provide information on my work experience, nobody wants to know what aspects of the Capability Maturity Model I've found to be most useful in ensuring project success, what design and documentation techniques lead to testable event-driven user interfaces, or asked to discuss performance engineering trade-offs between a databases' conceptual model, logical model, and physical model. Nope, their requirements only want to know what programming languages, operating systems, and application types I've worked on. And they want the latest versions of this stuff as well. If you stay on and contribute to the successful conclusion multi-year project from start to finish, you will be really helping your customer but potentially cutting your own throat. And what's really ironic is that the worst programmers and engineers in this profession change jobs the most frequently and are therefor constantly exposed to the latest technology. I easily spend 10-20 hours a week and thousands of dollars a year (my book bill alone is approx. $2000/yr) keeping up with new technology. And it doesn't help when software tool vendors hawk their wares by duping IS management into thinking that using their IDE or modeling tool or methodology causes good designs, good code, good documentation to pop out the other end. A fool with a tool is still a fool. It still takes smart people doing smart things to make projects succeed. And until IS management understands this its going to be business as usual. And you will know when the change has taken place when the posted job requirements call for engineering skills rather that tool skills. Lets face it, a decent programmer can learn VB or Perl pretty quickly. But building reliable, scalable, distributed object-based systems on time and under budget ... that's tough.

Designing Software

[mprovost]

In my experience it is very tough to get taken seriously as a professional by others because the whole world has a bad attitude about programmers. I'm the database admin for a pretty good sized architectural firm so I can see this first hand. Here are people that produce incredibly detailed drawings and multivolume specicifications for even the smallest project. Why? Because every drawing has to be sealed by a state-approved architect and that architect is liable for those drawings.

So these people should be used to a very meticulous way of designing things - but when it comes to a computer project it might as well be something sketched on a napkin. It is assumed that computer people don't need to have something designed and specified ahead of time. And computer people don't care because you can always quit and find a new job and who cares if the thing has bugs.

I guess the argument could be made that architects and engineers and professionals like that design things that can have life or death consequences. But these days how can you separate computers from any job? The engineer designing a new car is relying on crash simulation software designed by some untrained programmer somewhere. If the simulation produces bogus results, the car is designed and kills people, who is responsible, the car engineer or the software engineer? What if a shoddy print driver in Autocad prints out incorrect symbols on a blueprint and the roof falls in? I think to say that computer programs don't matter is simplifying things too much.

Degrees are meaningless

[wboatman]

Programming is all about attention to detail, and knowing the results of your changes. Based on my experience, that isn't taught in school. Probably because the schools can't or won't assign large, team based projects to give students some real experience.

Started work in a shop that is in the medical industry. Since they won't pay well, they get the people that are willing to work below scale. We started with a COTS database package, and it is utter crap. It works more by 'magic' than by design.

The original programmers would do things like open a record set, count the number of rows until they found a match for the other key, and use that counter as meaningful data elsewhere. God forbid that the orignial record set would change.

Or the programmer that said 'oh, I thought that might happen' after I spent all day digging through his code to find out why it didn't work after his last change.

Nevermind that half the bugs fixed have side affects because nobody really understands how the system works, or why global variables are a bad thing.

Nobody here knows how to test to see if the code works, no one knows how to get real requirements, no one knows how to write code that does error trapping. I've spent 5 months trying to get management to buy into a peer review or at least a design review so that we can get out of a continual maintenance mode. Of course that would eliminate interfaces with 30 parameters, most of them named product1, product2, product3

No one else can understand why I spend 3 days writing code, then a week writing the test script, then another week writing all of the documentation. Oddly enough, they can't understand why I don't have to keep going back to fix my code. Hmm, wonder if the testing and the lack of bugs are related.

Sure glad I bothered to finish my degree in CS. Then I'd be as clueless as all the degreed people (some with Ph.D's) I've had to babysit during my career.

Re:Why the plug for ThinkGeek?

[irix]

Becuase ThinkGeek is owned by Andover.net - that's why.

Who said that Andover buying Slashdot never changed anything.

Re:Programming is design

[Bob Ince]

if a design-team is competent, they will create an interface that is best-suited to their target audience, *not* to other programmers and people who are used to dealing with shoddy applications.

Doesn't seem like there are that many competent design-teams about, tho, does it? :-(

I think the important thing is that the internal design should follow the interface design, not the other way around. I always start with the user interface, what sorts of objects and models I'd want to interact with as a user. This often suggests much of the implementation. You could call it outside-in programming, or something; design top-down, then implement bottom-up. Of course, for me, designing how things should work is a lot more fun than actually making them work, so I guess less than 50% of my pet projects actually ever get implemented.

A lot of programs, alas, seem to have started their design with a few simple internal classes, and layered as many UI elements over them as are needed to make the software usable at all, ending up with horribly counter-intuitive interfaces. (I've been guilty of this in rushed projects too, natch.) Then you end up having to add crud like Wizards to perform common operations because the normal interface makes them too hard. Yuck poo smell. And bum as well.

As it happens, I did used to write much of my stuff in assembler. Wouldn't say that exactly made me perfect, but hey. I used to be able to understand my programs at the time, as well. My habit of labelling subroutines .thing_thing_kludge or .john_prescotts_face doesn't make it entirely fun maintaining the code now...

(Of course, ARM assembler doesn't count anyway, since it is far too easy to be classed a proper assembly language.)

--
This comment was brought to you by And Clover.

Programmers vs. Engineers

[SheldonYoung]

For good software engineering practices to be adopted, I see one large hurdle. Everybody thinks Software Engineer == Programmer.

Programmers are the work-horses of the industry. They are the ones in the trench typing the code to get the daily jobs done. Perl is their friend.

Software Engineers are the ones who build large systems, they spend three-quarters of their time on design and review. This is the only acceptible way to build good large systems that aren't Crap. Perl is usually not their friend.

The problem I see is that most of Management assumes a Programmer can product a beyond-small sized program as good as a Software Engineer in less time. The Engineer will take 6 months to build a elegant system that scales well, and requires little maintenance in the future. The Programmer can do it in 4 month, but it will require a lot of maintenance and shoe-horning in the future.

Which one is better for the job? It depends, but in general Programmers are great at small one-off systems. The Software Engineer knows that true small one-off systems are very rare.

The Kernel Hacker is curiuos mix of Software Engineer and Programmer.

OSS Red Herring

[twit]

Comparing OSS and a need for licensing (and there is a need) is a huge red herring. The OSS process is intended to produce maintainable, repairable, and reusable code; who writes the code, on the other hand, is of no concern to the process. It exists whether written by rank amateurs or seasoned professionals. Thus a move towards licensure is neither pro- nor anti-OSS.

However, there are cases where who writes, or at least who signs off on the code is a concern. For example, industrial or other mission-critical software. Reputation may presently be sufficient measure, but over time a quantitative, rather than a qualitative, measure is required.

Licensing is chiefly a matter of lawyer-speak rather than a guarantee of competence (and any manager who expects otherwise is an idiot). This doesn't make it somehow unfair; licensure protects both the developer/engineer and the client through limits on liability and collective organization of developers/engineers. Bringing this back to OSS, any amount of code may be reused or appropriated from an OSS project; what matters is where you can lay the blame for project failure.

On the other hand, I worked as an electrical designer and the act of programming (PLC's, but still programming) was frowned upon by the old style EE's (and perhaps frowned is a nice way to say it). The attempt to bring software development into the engineering field can be viewed, and justly, as a power grab by the engineering profession.

I suggest another form of licensing, where a counterpart to the professional engineer's act (modify this as required for your jurisdiction) is enacted. This should give licensed programmers certain limits to professional liability, the right to organize and accredit programs, and a clearly stated purview for software engineering.

I don't, however, think that software engineering should become an exclusive profession with reserved duties, like many professions have become. Programming as an act is too broad for this, and the act of programming is certainly broadly distributed enough that anyone should be able to try their hand at it. With the rapid influx of computers into our daily lives, software should be written by all and sundry, most of all by the people who need them, and professional sw engineers should be only priviledged where absolutely necessary.

--

Re:OSS Red Herring

[speek]

Comparing OSS and a need for licensing (and there is a need) is a huge red herring. The OSS process is intended to produce maintainable, repairable, and reusable code; who writes the code, on the other hand, is of no concern to the process. It exists whether written by rank amateurs or seasoned professionals. Thus a move towards licensure is neither pro- nor anti-OSS.

It is anti-OSS the moment the government passes a regulation requiring certain types of software systems (such as medical) be from "licensed" programmers. The list of such regulations will inevitably grow as time goes on. So, I very much disagree with you here.

However, there are cases where who writes, or at least who signs off on the code is a concern.

No, who writes the software is of no concern - ever. Who takes responsibility for it is what you're referring to. That's why Red Hat can be a money-making business. They sell service for Linux. They place themselves in blames way in return for money. Linux doesn't work for you? Blame Red Hat, and make them fix it.

Licensing is chiefly a matter of lawyer-speak...

Yes, true. That's why I think it's the wrong tool for the job. Because Licensing, in practice, is interpretted as a quality issue, not a lawyer/legal issue. Licensing doesn't prevent people from dying from bad medical software - it gives an outlet for blame and compensation.

Let me suggest an alternative: license software instead of people. A company sells service regarding a peice of software. They have tested the software, studied it, and pronounced it "good". Good enough to make money on anyway and not get bankrupted by its failures. Now you've gotten to the core of the issue - is the software any good, and who is responsible for it. It could have been written by a hailstorm on my keyboard for all I care.

Licensing, for this purpose, has everything to do with the software, and nothing to do with the developer. License software, not people. It'll work better, and it won't be a barrier to people.

Excuse me?

[jabber]

The Bar Assoc and the Medical Board may protect their members, but they do a lot more.

They provide assurance of the credentials of the people they accept into their ranks. Some quacks slip through the ranks, but many fewer than would be able to practice were these governing bodies not there. The alternative is federal management, and that bodes ill.

I do not want a cheap, home-grown surgeon taking out my kid's appendix. I do not someone with little more than a strong opinion to represent me in a Court Of Law. I require proof of competency!

In the consumer market, software will most likely remain Caveat Emptor, but I do not accept the future where missle guidance systems, air traffic control software, embedded pacemaker logic and other critical systems are written by self-taught lowest bidders.

It is these fields where professional training, professional certification and licensing will debut. After that, we'll see professional designers offer higher-cost alternatives to commercial software - and some people will choose this over the quick and dirty versions.

Now, I won't argue that experience counts for a great deal. It's crucial. This is BTW why people fresh out of medical school have to do residency - where their every move is scrutinized and approved before it becomes terminal (pun int).

In mission critical, safety minded and heavy-financial application, where lives and big money is on the line, accountability is required. Even in many consumer goods markets, the sort of accountability and competency assurance that comes from having a Professional Engineer design the anti-lock brakes and air-bags is a Good Thing.

Re:It all boils down to this:can you program?

[twit]

Not to rain on your parade, I'd say that a properly engineered project goes at least as fast, and usually faster, than one engineered on an ad hoc basis. This is especially true for work completed for clients rather than internally, since they can use every excuse not to pay you. Having scope and spec on paper denies them that excuse.

Honestly, I wouldn't even consider working on a project without appropriate spec and scope laid out; it's a recipe for exhaustion and doomed to failure. I've done this in the past, but my self-respect is worth more than

However, this is a matter more of project management methadology rather than software engineering methadology. Why is it worth mentioning here? A software engineer isn't, or shouldn't be, just a code hack. They should be a leader, like a P.Eng is. Plain old developers are technicians - talented technicians, quite often, but they don't need to keep their eye on the ultimate goal of the project like an engineer or systems analyst would.

The techniques that you're mentioning are more development techniques than anything else. That isn't to say that they're unimportant, and they can be very important when you're rolling your own code as a researcher, but in the workday world they're of less and less importance as you ascend the food chain.

--

Erm...

[GregWebb]

One major problem is that the developers are not trained in writing software in the first place. They are either trained in computer science, or some totally unrelated field.

UK CS undergraduate here, for reference.

The second year here (Reading) is basically the bits the department have to put in to get course accreditation from the British Computer Society. It includes Software Engineering and Formal Methods.

I don't know what US courses are like and that's certainly not the whole course, but it's a decent percentage and it's effectively requred over here.

Greg

Re:Erm...

[GregWebb]

I agree absolutely that size is a big difference, but...

Firstly, the basic principles hold no matter what size you're developing. They may not actually save time on a 100 line project, but once you clear a few hundred LOC you need them IME.

Secondly, how on earth would we have the time to develop anything that large? We're taught using examples and the principles scale.

Greg

Dangers of Software Engineering

[Donut]

I recently left a shop (in disgust) that had been taken over by people espousing "Software Engineering" and McConnell. I had been through many crunch projects, and was tired of it, and was willing to give anything a try to be able to go home once in a while.

So, I bought a copy of "Software Project Survival Guide", read it, learned it, loved it. I was willing to start to implement the good ideas, and ignore the ones that did not apply to our warez, and make a go of it. We still had to make software, but there might be a better way.

Well, it turned out the the push behind our embracing of "Software Engineering" was not a way to get schedules and process under control, it was a new, novel way for executives (who were lawyers and accountants!) to micromanage the architecture and coding of our systems! We would generate all of the "Upstream" documents, and they would be picked apart by people who couldn't tell the difference between C and ASM. So, we went back, and regenerated (meetings, meetings, months).
The other problem was that during the time we were generating the "Upstream" documents, we were not actually coding. That in itself was not bad, but to people above us, it appeared that the only output of my group was the paperwork. Since no real implementation work could be done, then it was SIMPLE for the execs to drastically change the nature of the product we were working on. After all, we hadn't DONE anything, right?

After months of this, and 3 complete sets of docs, I left. I went to a small software house, and hacked for a good 3 months to get back into the groove. At the new place, we use some of the ideas in the "Big Orange Book", but we are thankfully able to concentrate on the real job: Making software.

Bottom line: Software engineering is a means to and end. Beware the motives of those who would make you concentrate more on that process, and less on the actual output. Make sure that the people managing the process are actual engineers.
Customers could care less about how you made the software, they just care about the end product.

Programming is like writing literature

[rcromwell2]

Being able to effectively plan out your story, your characters, and how it unfolds is taught to most college students who take composition and literature courses. A writing class generally helps a person become better at communicating and arranging their thoughts in a succinct manner.

It's a top down technique with bottom-up feedback and iteration (rough draft, edit, next draft, edit, etc)

On the other hand, the vast majority of programmers are not taught techniques for arranging their "thoughts" and putting them into code effectively. Software engineering courses on campus are little more than a *REVIEW* of current SoftEng literature, and not much of a workshop. And usually only one class is required or even exists. In an english composition class, you might have to write 5-6 essays throughout the course of a semester, all putting into practice the techniques you learned.


So much time is spent in CS departments teaching algorithms, programming languages, and analysis, that precious little time is left over for teaching effective software composition. Which probably means that colleges need to make a distinction between Science and Engineering. Right now, colleges have both CS and IT classes (IT usually emphasizes technology, and not science), and I think IT should add more requirements related to teaching style and technique. After all, the IT people are the "grunt" workers who actually have to go out and design/build the bridge, not study the materials engineering that goes into the steel used to build it.


As a minimum, "engineers" in addition to getting some required science background, should be able to concentrate in "design", such as the following:

1) requirements analysis
2) design (booch, rumbaugh, jacobsen, design
patterns, et al)
3) process
4) management/team building
5) risk analysis

And, like any good engineering school, there should be heavy emphasis on actual real projects.



This is no way takes away from the "art" aspect of programming. Can't a scientist use his skills for building a bridge or building a sculpture? All I'm asking is that the people building the applications I use and depend on (and moreover, that the nation's infrastructure depends on) be a little more "serious" and a little less focused on "coolness" vs design/maintainence.



of course, anytime someone calls for this, there are always cries that it will kill innovation, passion, etc etc. Personally, I see far more "failures" than I do innovation from most of the amateur coders. People like to focus on the successes, but that doesn't give you the whole picture.

Re:It all boils down to this:can you program?

[wrook]

I don't want to sound overly harsh, but this comment is classic in many ways. It is exceptionally common and exceptionally wrong. The premise is, "I live in a disfunctional family. No-one knows how to communicate. Therefore, communication is an utterly useless skill". Communication is not useless, it is merely useless in this particular environment. If you fix the environment, you find that the previously useless skills become your best assets.

If you are working in an environment where you are always rushing, where computing theory has no place because there is no time to think, then you are working in a disfunctional system.

I believe that this type of environment is common in the industry for 4 reasons.

1. Get rich quick syndrome. Venture capitalists want to see a 20 to 1 return on investment on high tech firms. Breaking even is seen as a failure. The goal is to find a rapidly growing niche market and to dominate it. Quality products are secondary to market penetration. Features are everything (sell the sizzle, not the steak).

2. First to the market wins syndrome. For some reason being first to the market is seen as essential to obtaining market dominance. It is irrelevant that there are virtually no software products where the first to the market maintains dominance for the long term (I dare anyone to give me an example -- I can't think of any). Time to market is seen as more important than quality.

3. Like rewards like. If you work on a project, deliver tons on functionality and get it out the door really fast, you will be promoted. In fact, most people are promoted well before anyone realizes that their code was complete crap. In some cases, they may even get promoted before the product ships. These people maintain and extend the disfunctional environment (they promote the environment that made them successful).

4. A legacy of ignorance. People are not taught any better. How many people got out of school looking forward to the day when they finally get to work with fantastic people in industry. How many people fantasized about how much they would learn from software gurus that they would meet in their career. How many people were crushed when they got out of school and found semi-literate neandrethals (sp?) hacking away in the most bizarre ways. How many were disappointed to find that even if you could find one or two guys that knew what they were doing, that they couldn't (or wouldn't) teach anything to you. In a world where the experienced can't teach the newbies, everyone has to learn from first principles. You can't build on the experience of others. Only the very best people become at all competant. The vast majority struggle in valiant ineptitude.

Confusious said that if society is corrupt, then your must remove yourself from society. This is perhaps a bit extreme. However, you *can* change the world one step at a time. Think globally, act locally. Grab a new person out of school and become their mentor. Teach them what you know. Take responsibility for your own code. Struggle with all your might to add a small bit of quality to *your* code. Advertise your success. Dare others to match it. Propose a project to your management where you take a commonly used product and enhance it (you'd think that we would eventually learn from East-Asian culture...).

OK.... Enough ranting..... Maybe I should write a book :-)

Re:Licenses and certification

[speek]

Of course a licensed programmer might write open source software. But that wouldn't make that software "licensed". Of course there's a place for both open-source and proprietary. My main point is that licensing doesn't guarantee anything about quality, but that's exactly what it will be advertised as. Software from a "licensed" developer will be automatically billed as better than from a non-licensed, and they'll charge more for it. The government will outlaw non-licensed code in certain areas. And that list of outlawed areas will inevitably grow. Amateur programmers will get slowly squeezed out.

They write the right stuff

[karkle]

This reminds of an article about writing "perfect" software in Fast Company

The article discusses the process NASA uses in its attempt to write perfect software. And it does not require programmers to stay up all night

White collar unions

[jabber]

There certainly are both good an bad sides of these organizations. I wonder how 'corrupt' medical organizations would be if the Bar Association didn't make it so easy to sue a Doctor for malpractice. ;)

These organizations need to be held accountable for the practice withing the field they claim to advocate. For example, it should be a part of every legal oath (is there such a thing?) to not entertain a frivilous lawsuit (with parameters provided and kept up to date, to define such a suit), just as all doctors swear to 'first, do no harm'...

Also, you seem to suggest that teachers have no skills. If I misunderstand, then I apologise. Teachers need special training to impart knowledge onto students, especially in the age group most resistant to being taught. They need special training is child psychology, conflict resolution, structuring of the learning process and other things, that make education uniform across schools and regions.

The requirement of being degreed in Education in order to teach in any field is not true at University levels, and also not adhered to in many private schools. In these areas, an expert in the field is preferable - especially in education. Once education is no longer required, and students make the choice of being there, then the Educational training otherwise required is no longer needed.

But I do agree with you in principle. Education is a great place for a lazy person to get comfy... This is why the whole idea of tenure prings up a systemic deficiency in the educational system. It takes literally years to remove a tenured teacher from their position. You need to use the words 'sexual abuse' just to get the overseeing 'bored of ed.' to wake up and take notice.

Returning to the topic of the article though, Software Engineering is not the same thing as programming. The difference is that a programmer implements the design of the SE. The SE needs professional training and programming experience, the programmer needs skills. The degree to which the programmer has freedom of design is a managerial matter, dictated largely by the legal department, and mostly (in the final tally) by the accountants.

The engineering firm I work in has very few P.E.'s. Most are degreed engineers who just never took the PE exam, or don't bother to keep paying the fees for maintaining the license. The thing is that the PE's have 'sign-off responsibility' which allows them to authorize design changes. Even if the changes are the idea of a non-PE. They have approval, they are the ones to get hit if the changes are wrong, and they get paid a bit more for that.

As an SE/Programmer (still fuzzy for us in CS) I can make design changes, and all I have to do is get buy-in to the idea from other developers and management. I can argue the point, and the only repercussion for failure is that it was MY idea. My professionalism, or the integrity of my career or employability, is never at stake. Unlike an architect who is branded for life if his building collapses, when my software crashes, I get to say 'oops' and try again.

There are significant portions of the CS industry where this is not acceptable. Colliding jumbo-jets is one such area. Cratering a probe on Mars, because they said feet, and you heard meters, is another.

A P.S.E. certificate would not really set up a racket. I really don't think it would. It WOULD reduce wages for people who do not hold the cert. The head architect(s) of the system would still make in the six figures per annum. The guys that crank out 10 KSLOC per week straight out of high-school, having read a single VB in 21 days book would realize their value in the grand scheme of things right quick.

Re:Bravo!

[joss]

They don't crank out a few million lines. They crank out a few thousand that make the million obsolete.

OK, so nobody is going to rewrite SAP on their own, but SABRE I'm not so sure about. Almost all significant new developements comes from individuals or pairs of programmers. It happens all the time.

Unix - written by Ken Thompson and Dennis Ritchie, while 100s of programmers worked on Multics, and 1000s worked on MVCS.

dbx - the best debugger of it's time written by 1 guy, while 100s of people worked on xdb. It was not only more powerful, it had more functions.

Borland, Lotus, Linux, even fucking microsoft. Later on large organisations grow around the original innovation, but the *significant* software does NOT come from large teams.

Re:Two types of programmers (and code re-use)

[belswick]

Yes, experts frequently accomplish very little code re-use, except perhape their own code. Why?

1. Because you can't verify that code is correct unless you understand it and can at least audit the source. This leaves out closed-source "objects". How do you know if you are testing all possible path through the code if all you can do is black-box testing?

2. Because there are no guarantees on software. Just read the license agreement on the next box of pre-constructed objects you purchase. "No guarantee of merchantability of fitness for purpose" leaves a hole big enough to drive a truck through.

3. Optimization. If you don't thoroughly understand the code, you can't fix bottlenecks that crop up in that code.

4. In the case of closed-source code reuse, you can't even step through it with a debugger unless you want to do it in assembly.

Another point. While it's very nice to learn OO design in a teaching language, it is the very unusual real-world application that you can code up in Scheme. And now that the buzz is wearing off of Java, I actually see a trend back to C++.

Re:Why the plug for ThinkGeek?

[drivers]

Because most of us are boycotting Amazon.
http://linuxtoday.com/stories/13652.html