After the Gold Rush : Creating a True Profession of Software Engineering 152
| 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
- The Tar Pit
- Software Dinosaurs
- Fool's Gold
- Orphans Preferred
- Software Engineering Is Not Computer Science
- Prospecting
- After the Gold Rush
- Engineering a Profession
- Ptolemaic Reasoning
- Body of Knowledge
- Novum Organum
- Through the Pillars
- Stinking Badges
- Architects and Carpenters
- Hard Knocks
- The Professional's Code
- Alchemy
- The Tar Pit
- Epilogue
- Notes
- Index
Humdee dum dee dah (Score:1)
As for the "Gold Rush" - I don't see why anything is changing (maybe I should read the book). It's not like software is no longer a competitive industry. Hardly - it seems more competitive now than ever, and the "Firstest" is still sometimes the preffered, if not "Bestest"
-----------
"You can't shake the Devil's hand and say you're only kidding."
Licensing is here in another form (Score:1)
Sure software companies have lots of choices in the candidate pool, but the fastest way to the chaff from the wheat is to put a B.Sc requirement on the job. (Not that it always works, as there are some people I wonder how the heck they even PASSED with so little they know.)
People also seem to keep forgetting that software engineer is relatively new, 25 years, compared to the other hard-core engineering disciplines. With every company developing their own programs from scratch, instead of being able to use off-the-shelf re-usable software components, is it no wonder the quality of software is so bad? Everyone is forced to re-invent the wheel ! Fortunately, Open Souce Software is providing one solution: Developers are able to share code.
But then again, what do I know, I'm just a game developer.
Cheers
Re:Humdee dum dee dah (Score:2)
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).
Whats sad is I can read that ... (Score:1)
Moving out? (Score:3)
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:Humdee dum dee dah (Score:2)
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? (Score:4)
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?
2000: Where To? (Score:4)
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 (Score:3)
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?
Programming is design (Score:1)
The problems with "Software Designers" who don't code is opposite. They come up with wonderful "designs" that are completely impractical that cannot work. But at least they get to blame the programmers.
But what is engineering? (Score:1)
My current best guess is "don't do anything until you know what you want to do and then make it in a way so that its easy to change it when you later on realize you wanted something else".
I don't know if its the right definition but i'm sure they didn't teach me that in school.
My guess the problem of badly engineered projects is quite common. It's just more obvious in programming
Computer Science/Software Engineering (Score:1)
The one thing I haven't figured out yet is, if Computer Science (strictly) isn't really for software development, what is it for? I thought it was very useful to get some training in algorithms and grammars, etc. (the Science of Computer Science), but I sure as heck wouldn't want to do it for the rest of my life!
Fortunately, my school's CS curriculum mixes in plenty of programming and software engineering-type coursework, so I still feel I was left with a good foundation.
Re:Licensing is here in another form (Score:1)
Software development vs. solution design (Score:1)
This tends to work fairly well when you deal with single tasks, but starts to really crack when you try to fit in the application withing a larger context, such as a multi-channel CRM strategy or integration of applications within a larger enterprise.
What is required is a way of working that promotes thinking in a wider scope, and taking a more technology or method pragmatic approach to development. At the end of the day it's primarily a matter of wanting to solve a business problem, and the best way to do that is to go through a full analysis of generic functional service requirements rather than individual functions.
Hmm. Did I just get off-topic here? Hope not. What I really wanted to get across is that I really see a need for developers to start thinking more in terms of enterprise-wide design rather than functional-point development.
Live long and
Re:Humdee dum dee dah (Score:2)
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".
Code of ethics (Score:1)
What I'm wondering is how many programmers welcome training in and practice of software development processes? Many programmers that I know believe that what they do is create software -- that they are software craftspeople. They perceive software engineers as people who do more paperwork than programming, and who value process over ingenuity in programming. Now I'm not endorsing this view, but what do you guys think?
It all boils down to this:can you program? (Score:1)
Algorithms are the most important thing - does anyone do searching and sorting of large data sets without the aid of a SQL database anymore? Does anyone write their own search routine? I've found that for 97% of cases, searching and sorting is optimized by leaving it to someone else.
Software engineering matters - does anyone write specifications? Does anyone follow a development methodology? I've never worked in any market that executive felt was "slow" enough to allow for sound engineering techniques. Everything has been lost in the rush, and nearly everyone is rushing.
Now what I have found out is this:
Knowing the specific issues of particular systems (databases, operating systems), is far more important than knowing theory of any kind, almost all of the time.
Thoughts?
Re:Moving out? (Score:2)
Then tell me that "bugginess" doesn't catch up to you. It just takes a while.
Bah, humbug (Score:2)
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:Programming is design (Score:2)
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 (Score:2)
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:Licensing is here in another form (Score:1)
This touches on something that I rant about in the RW alot. If you want to build a hospital, you go hire an Architect (who legally must have professional association for a project like this), who in turn will likely hire engineering consultants (who must also legally have professional association). Then the client goes and hires a consultant to build the computer systems that will help run the hospital. If they're a smart organization then they'll know how to get a company that is qualified to do this, but it really could come down to luck.
How does the client know that the company they are hiring is capable of completing the project. How does the copmpany know that the programmers it hires even have some basic formal knowledge about testing, documentation, etc.
I read an article in a Transactions on... journal a couple of years back talking about exactly this. In fact the article was commenting on the way that programmers call themselves "Software Engineers". In some locales the term "Engineer" is restricted in its use -- you can't call yourself an engineer unless you legally are one. Since most (all??) "Software Engineers" have no legal (not trade) certification, they aren't engineers.
The argument that Computing is a relatively new field doesn't excuse a company that builds a critical app which subsequently fails (and possibly costs lives). In some areas, if a building collapses, the engineer can be brought up on criminal charges (ie criminal negligence). The company that build the critical app which failed might be sued, but the "Software Engineer" who runs the company will come out of it OK.
Now the question arises, "Where do you draw the line?" Analogous to construction, there are certain projects that there is no need for the developer to be qualified as an Engineer. In Canada, anyone can design and build a house. In fact, anyone can design a building less than a certain size, or for certain uses (residential and light commercial under 600 square meters, I think). Likewise, there is no reason that a game, word processor, or other application which isn't going to cause major problems if it fails should be designed by a (legal) "Software Engineer". But the person designing an app that has the potential to cause a great deal of harm if it fails should (in my opinion) have a legal certifcation that the client can view as a guarantee that the designer is qualified and capable.
Re:But what is engineering? (Score:1)
In Norman Mailer's book "Fire on the Moon" he described the difference between science and engineering. For example the science of how to go from Earth to the Moon was solved by Isaac Newton.
But to actually get people to the Moon required quite a bit of engineering.
In more general terms engineering is the art of building useful things on time and under budget.
P.S. See several books by Henry Petroski for more discussions of what engineering is.
Re:But what is engineering? (Score:2)
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 (Score:2)
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 (Score:2)
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?
Should we emulate the engineering profession? (Score:1)
I just had this discussion with my sister a few nights ago. She is a fire protection engineer and uses her stamp on a weekly basis.
There are many things wrong with the engineering profession. Many untrained (got their designation in the 50's) and unqualified (graduated in one field, works in another only exposure is on the job) engineering people. There is also the whole "closed, elite, old-boys-club society" of us vs. them ideology.
There are many good parts to being in an organized, well-defined professional but you need more reasons than just "we are slowing down, we can promote the best now".
Besides hasn't Slashdot already gone through this whole debate? (Project Managers should be licenced, how can you verify programs are correct, etc) (I would include a link but I'm just too lazy this morning. Its my unprofessional attitude.)
Re:Humdee dum dee dah (Score:2)
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
Re:It CAN be helped. (Score:1)
If I might suggest some reading on this subject. "The Inmates are Running the Asylum" is an excellent book by Alan Cooper. In it he does a truly wonderful job of discussing the concepts behind quality interface design, and task-designation.
-----------
"You can't shake the Devil's hand and say you're only kidding."
Relationship to Open Source? (Score:1)
I think that the Open Source/Free Software methodology challenges a lot of software engineering as it would appear this book is promoting.
How can software engineering handle the talent of many open source programmers many of whom are unqualified and very young? Yet the os/fs methods work well.
Products produced using os/fs methods can appear very quickly, can change rapidly (including major design changes - see KDE and it's use of CORBA for communication within a single machine as one example). Yet these same products typically have a much longer life than commercial products. How many commercial editors have been going as long as Emacs (and are still alive and well)?
It seems there has been a progression towards control and a "right way" in Steve's books which seems a pity. I would have much rather have seen a book on Quality Development to match Rapid Development. Such a book could have provided lessions for both os/fs and closed source programmers - there are things both can learn from the other as well as from best practice in their own camp.
Dave
Software Engineering Economics (Score:1)
Free software tends to suck less, but only the projects that are actually being worked on. If nobody fixes the bugs, the bugs don't get fixed.
ps: Software Engineering Economics is the title of a book by Barry Boehm. I haven't read it yet, but I intend to.
--
My opinions may have changed, but not the fact that I am right.
Re:Humdee dum dee dah (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:Programming is design (Score:1)
My current favorite programming language is Eiffel. You can express your designs much better in Eiffel than C++. You should check it out.
As far as getting a design right. How can you tell it's right unless you implement it? Except for very obvious things that have been tested by others before (like how do you design a hash table), you cannot tell a priori that a design is good.
Unless you have quite a bit of experience implementing systems you will not know how to design it.
Designing user interfaces is a completely different thing. This is not software design, but human factors design. I'm sure it wasn't an aircraft designer who thought that the knob that rasises and lowers the landing gear should be shaped like a wheel.
P.S. I'm not perfect either. I never said I was.
Commercial Software Developers are a Microcosm (Score:4)
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 (Score:1)
As a profession, one of our worst mistakes was to permit words like "design" and "creative" to be appropriated by graphic illustrators.
Re:Programming is design (Score:1)
And sure, I think I will check out out Eiffel.
-----------
"You can't shake the Devil's hand and say you're only kidding."
Licenses and certification (Score:1)
It provides for the illusion of competence that lets a big faceless organization hire a consultant they know nothing about, but they'll have a certificate to point to to justify the decision.
It allows those with licenses to arbitrarily charge more for their services than those without, regardless of actual competence.
It requires money to enter the profession - licensing and certification always costs money. Lots of money in some cases.
This guy works for a software consulting firm, right? Big surprise there. He's sick of seeing incompetence compete successfully against him, and thinks he can simply "outlaw" it by requiring licensing. Licensing never guarantees competence. Are teachers who are certified better than those who aren't?
Licensing is an integral strategy of the closed-source, proprietary, non-free model. Only doctors who are accredited are accepted by insurance companies - thus no "open-source" doctors. Open lawyering is just plain illegal. Home teaching, interestingly enough is legal, but culturally frowned upon. Licensing programmers will result in "accredited" software. It's an way to shut out the OSS developers, and a justification for business to never use OSS software.
Re:Humdee dum dee dah (Score:3)
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.
Software Engineering (Score:1)
a) My lecturers were just uninspiring
OR
b) The current state of SE is such a mess that there is _nothing to teach_ apart from how to get it wrong like everyone else does. In twenty year's time my children will actually learn things from their SE courses. Which is what this book seems to be saying.
Did anyone feel that the stuff they learnt in Software Engineering courses actually helped them engineer software?
Dammit Malda, fix /. already (Score:1)
is the link. I entered it as: Anchorname. SLASH translated it to
Software Engineering Economics. Apparently it can't deal with a newline between the first quote and the =. This bug probably occured because perl makes it much easier to deal with HTML on a line by line basis than with a proper HTML parser.
--
My opinions may have changed, but not the fact that I am right.
C: smaller,faster is still better for "platforms" (Score:1)
Smalltalk can probably be written off, and I doubt Dylan will ever get off of the ground. Python, Java and Perl are your best candidates in this field.
Re:Bah, humbug (Score:2)
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.
I dunno (Score:2)
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. (Score:2)
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.
moderate that one up! (Score:1)
Re:Humdee dum dee dah (Score:2)
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 (Score:4)
Why the plug for ThinkGeek? (Score:1)
I'd prefer not to see endorsements for specific vendors as a part of a book review. But if you have to do it, at least pick the vendor with the lowest price!
Thank you.
Designing Software (Score:2)
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.
Job Description: Information Infrastructure Design (Score:1)
Construction:
Some companies design IP components (bricks), other integrators (builders) bang them together along with necessary hardware, and if your lucky, an inspector (QA) comes along and declares the edifice adequate to live in (guarenteed not to crash within 30 days or your money back
Medical:
The consultant rolls along, eyeballs the requirements, then searches the black bag for the magic pill based on skill of diagnostics and brain-washing
Creative Arts:
A code scultor imagines this fantastic piece of language/world-builder which will do unimaginable things not possible through any other application. By enlisting the help of others and displaying it in public galleries, the work (though a bit fragile) eventually attracts a sponser who agrees to pay for the completion in return for the rights to make cheap knock-down copies in china.
While somewhat tounge in cheek, I suspect people need to think about what is really design. Essentially software is the codification and expression of human capabilities so it does have creative aspects but then once the general technique is mastered, it requires engineering discipline to propagate and train the next generation as well as the simple documentation so that DIY builders can assemble it at low cost.
There probably are a whole raft of specialisation that could exist, design, maintainer (sys-admin), inspector (auditor), etc
LL
Re:Management, anyone? (Score:1)
The sole purpose of corporate IT is to enable and support management objectives. It serves no purpose otherwise, and wouldn't even exist.
Software costs too much, so all the managers want to get some of that good object orientated stuff on the project.
It is management's responsibility to both ensure that sufficient resources are available, and to ensure that the resources are employed most efficiently.
So, the programmers dutifully build the system to be as re-usable as possible.
If the programmers think they could manage the company better, there's nothing stopping them moving into management themselves.
Re:Bah, humbug (Score:2)
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:It CAN be helped. (Score:1)
I can see this being a good idea for some teams on some projects, but I hardly think it should be universal. It is in the management of a project where the discrimination must be made, and we all know how that works.
Re:Programming is design (Score:1)
If I change the oil in my car, am I a mechanic?
If I pop a zit on my face, am I a dermatologist?
If I handle my father's stocks, am I a stock broker?
Why then is a person who can write a 20 line C++ program, a programmer?
I don't buy it.
Degrees are meaningless (Score:2)
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? (Score:2)
Who said that Andover buying Slashdot never changed anything.
Re:Programming is design (Score:2)
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.
Re:Bah, humbug (Score:1)
Nobel-prizewinning economist Milton Friedman makes a similar, and very well reasoned, argument in his book "Free to Choose" [amazon.com] (co-written with his wife Rose D. Friedman). The only profession for which he reluctantly concedes that a professional organization might be unavoidable is for MD's.
I agree with him that most such organizations are perfectly dispensable and over time mutate into money-gathering and lobbying organizations, paying only lip-service to their original goals. There have been examples galore of licensed MD's who have killed their patients, licensed engineers who built highrises that tumbled down and killed scores of people, licensed lawyers who've commited all sorts of imbecilities... the notion that these organizations are per se able to guarantee the professional competence of their associates is just wishful thinking.
I've also had several personal run-ins with such people. Over 25 years ago (and in another country), when I co-founded a software consulting company, we were pestered for over a year by a Business Administrator's Association, which claimed that we had to pay dues, employ at least two licensed administrators, and so forth, because according to their understanding "software" necessarily meant "administrative software" like payroll and accounting, and therefore fell exclusively under their charter... argumenting that we did systems software (of which they'd never even heard of) was to no avail. We let several thousand buck's worth of unpaid fees and penalties pile up and ignored them until they went away.
IMHO the solution is showing competence. If an engineer, architect, or programmer can show me solid, well-executed work, I don't care if he/she's certified or not - heck, I don't care if she/he/it's got a diploma, even.
Re:Bah, humbug (Score:2)
Re:Licenses and certification (Score:1)
Programmers vs. Engineers (Score:2)
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 (Score:2)
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:Programming is design (Score:1)
An interesting thing about Eiffel is that as well as a programming language, it is a design language. The distance between design and implementation is shortened, which is a good thing because energy isn't wasted in translating back and forth between separate design and programming languages.
Excuse me? (Score:2)
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.
They ARE a programmer (Score:1)
What is the DEFINITION of programming?
A person who writes a 20 line C++ program is an AMATUER or HOBBIEST. They may be good at it. They may not be. But they are STILL a programmer. No one ever said they were a professional software engineer with all the skills to design good programs.
Why does this discussion have to end with symantics?
Re:Programming is design (Score:1)
I once used a timing circuit to make a group of LEDs blink in sequence. Therefore I'm an electrical engineer. I think I'll put that title on my business cards...
I think you're confusing GUI design and the design of software. People in this thread should be using "software architect" when they're saying "designer".
A software architect's target audience is the programmer. If this person does not understand programming, and does cater to the programmer's needs and the limitations of the systems involved, then this person will design crap. It's that simple. No magic software engineering methodology will make happy little worker ants of programmers implementing the designer's grand vision.
Innovation VS Persperation (Score:1)
To understand the current state of "software engineering", consider the unique nature of software as opposed to other engineered products.
All innovation comes from a passion or creative source, which is then tempered by the scientific realities require to make the idea a reality. In most fields, specialization and fabrication is necessary in order to make this happen, therefore the "inspiration" and "engineering" become seperated, decoupled, which allow the creative side to think and act feely, and the scientific side to focus and operate within the constraints of the disipline.
This is not always true, in face, in the beginning of any disipline, boths tasks are ususally managed by a single individual, exibiting the unusual traits of being creative and analytical. It is especially untrue in the case of software developers, but also in the original "computer hobbists" of the 60's and 70's.
My first computer experience came from my grandfather's SWTP 6800. Watching him load the bootstrap from a programmers console (eight switches and a commit button) ingrained in my mind what passion for technology really means, and it is something I don't see much anymore in the industry.
The really good software engineers balance the artisan nature of the creative scientist, and find a way to make a living doing it.
...or wait for the next bandwagon...
Re:It all boils down to this:can you program? (Score:1)
As for "does anyone write specifications?" The answer is yes. Don't get me wrong, it's very hard to get management to stick to them, but at my company they have seen the benefits of using them (faster development, better development), and they actually *want* us to use them. As I said, they have a tendancy to stray from them from time to time, but it's getting better each time.
As for your last thought about knowing particular systems being more important than the theory, my experience is the opposite. I might have to write my code for the Mac one day, Windows the next, and both plus Linux after that (which is the case with my current project). It's more important for me to know how to abstract the parts that will vary between the systems (file handling, UI, etc.) than it is to know the specifics of how to implement those parts on each system. I can read a manual to figure out how to get data from disk into memory, but if I can't architect it properly, it'll be a mess getting it to compile on all 3 platforms.
-D
Re:It all boils down to this:can you program? (Score:2)
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... (Score:2)
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:C: smaller,faster is still better for "platform (Score:1)
Why? Is this for technical or social reasons?
Lisp and Smalltalk have been used to implement operating systems,HTTP servers, and database systems and quite efficient and powerful ones at that. What advantage does C have besides being close to the hardware?
examples:
Li sp Machines [uni-hamburg.de]
CL-HTTP Hypermedia Server [mit.edu]
Squeak [squeak.org]
Pluggable Webserver and Swiki [gatech.edu]
MinneStore [k12.mn.us]
GemStone [gemstone.com]
re: bah humbug (Score:1)
BUT programming is completely separated from designing a SYSTEM. When you build a solution for a company, you don't only look at how a computer program should fit into the business, you look at what changes need to be made to the business. Software engineering is a discpline of designing stable programs. Programming well doesn't make you a software engineer. If we take the Denver Airport Baggage System as an example (a case study in system failures in my first year at uni: UMIST), one person would have a very hard time designing a system like that all by him/her self. You need teams of people who know how to look at the problem first. These people need to know how to express this formally so they can even remember whats going on or hand over to someone else to take over. There are good ways of doing this and bad ways, where do you suppose people are going to learn this sort of stuff with out unis? How can you prove you know what your doing without a BEng or MEng?
The thing about Engineering as a profession is that projects tend to involve many people, the question of one person being incompetent is not important if you have trustworthy(ie. professionals) there to catch them. Since doctors often work alone, we don't detect any malpractice until later on. Usually when it's too late.
As for the law in this matter, I think the BCS (British Computing Society - it even has a royal charter as far as I know) is trying to get Software Engineering accredited as a proper engineering discipline that needs a proper engineering degree!
Re:C: smaller,faster is still better for "platform (Score:1)
Why? Is this for technical or social reasons?
Obviously, tweaked C code will always be smaller and faster. As for your examples, the success of Lisp machines speaks for itself, Squeak is going nowhere, and I've never even heard of the other projects.
Re:It CAN be helped. (Score:1)
You get people working on what they're best at, and you get them doing it all the time. I'd much rather have excellent programmers programming and excellent designers designing than have a bunch of excellent people doing two things that maybe aren't their strongest skills.
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:Two types of programmers (Score:1)
It wasn't always that way, even at Rice. Even just a few years ago, during my sophomore year (1993-1994), they stressed abstraction quite a bit (algorithms, Scheme, etc.), but reuse was barely even given lip service, much less graded. Even within two years, the department had finally started to modernize and teach code reuse. (I'm assuming you mean the COMP department, not ELEC.)
And yes, licensing is a two-edged sword. Accountability is a Good Thing where safety's on the line, but there are plenty of incompetent doctors and lawyers who still have their licenses. Make no mistake, requiring such an "insider's club" for software engineering would attract the same kind of buddy-buddying and industry-wide lobbying (to the detriment of the consumer) we've seen between, for example, the AMA and the pharmaceutical industry. (You know some folks wanna make you pay for a prescription for Vitamin C?)
I always thought they'd simply create a new category of Professional Engineer, or make it a subset of Electrical Engineer. That system is definitely a racket. I've personally had to read, debug, and scrap really--really--lousy code written by licensed professional engineers. Licensing kinda makes me wonder why I would have to pay to take two expensive tests (in Texas, anyway, barring some exceptions), accompanying classes, and make a fscking diary of all my projects for four years, just so I can be in the same esteemed company as the idiots whose code I had to destroy.
Perhaps licensing would solve a few problems, but I agree with other commentators here that, with or without licensing, we need more clueful managers. We need people who can design the software as a whole. We need user interface specialists. In small shops, a developer might have to become an expert at all of these things.
So how do we do that?
I welcome suggestions.
--unDees
Re:Moving out? (Score:2)
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
Programmers, Engineers, and Computer Scientists (Score:1)
I think there is a difference between the three. The programmer writes code. Anyone can do that. The CS grad knows the fundamentals and theory of algorithms, data structures, information science, etc. The software engineer applies sound engineering practices to software design and implementation.
They aren't the same. A PhD in computer science may not know anything about software engineering: construction of real systems. A software engineer may not know the little details of languages, automata, etc. And a programming wizard may not know either, but dwarf them in his C expertise and knowledge of an OS.
They can all work together. Each contributes something to the team.
One thing I've noticed, though, from where I used to work, with "computing" engineers and CS grads. The engineers cut more corners, are far more cowboy. Perhaps it is a rebellion against their training, a chance to cut loose in the abstract world of software. At any rate, I found their lack of rigour disturbing, and invariably it bit us in the end.
--
Dangers of Software Engineering (Score:2)
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 (Score:2)
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? (Score:2)
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:Management, anyone? (Score:1)
Except for perhaps the bias against promoting technical people into real management positions? Why should those technical people be promoted? They've never been able to meet our expectations before...
If you don't believe me, just check out the ranks of board rooms. Few people with any kind of technical background there.
I notice you ignored the parts of the comment that dealt with how management rarely bothers to become educated in the issues surrounding Software Engineering and Software Project Management. I think you'll find that management does not ignore principles of accounting or marketing.
-Jordan Henderson
Re:Code of ethics (Score:1)
As a software guy who used to practice law for a living, I've lived both sides of the street.
Lawyers live under a code of ethics that in most states has literally become enacted as part of the statutory law, and also is enforced, at least in theory, by the courts and Bar Associations. Some of the ethical codes work to help protect the clients, some work to better some view of society I guess, but many of these rules simply operate to keep other working folks from practicing law without a license. It is turf protectionism in its rawest form. Further, some lawyers actually spend time pushing the envelope on what practices are "ethical" by finessing the rules. Not a pretty picture. And, of course, there are now lawyers who specialize in the lawyers' ethical rules themselves, making lucrative practices out of defending other attorneys accused of malpractice. Do we in software really want this stuff to happen in our field?
The existence of the lawyers' code, and mandated degrees, and bar exams, and mandatory legal education do little to the ensure competence of the individual lawyer. Word of mouth from satisfied customers you know is still the best way to find a good attorney.
Regarding the IEEE/ACM SEEPP Code of Ethics, I was for a while a member of the task force that drafted the current code. It's all very nice and noble, but there isn't much in it that all of us didn't learn by the time we got to kindergarten.
Worse, there are a few things in there that I wouldn't want to be held accountable for as a practicing programmer. Here are the highlights:
1) Once you are a "professional", you can be held liable for malpractice, and you must legally exercise a higher standard of care than other mortals have to in their chosen fields. For most software, there is little societal benefit to be gained for the added burden placed on the practitioner (and their malpractice insurers). The costs for such insurance are just passed on to consumers, anyway. (Some software does require high standards of care, but really, not most.)
2) The Code effectively makes programmers responsible for respecting and enforcing other people's intellectual property rights in their workplace. So, if your boss won't pay for a site license for that software everyone is using, does that mean you should be sanctioned by a professional organization for continuing to work there? For not sticking your neck out? Where's the line? Why do software people have to live with this explicit ethical responsibility and not, say, secretaries? Don't we all have to follow copyright law anyway? I don't get it.
3) The Code also places the responsibility for quality on individual programmers, where it often belongs, but doesn't magically imbue programmers with any means to impose this goal on the their employers. The Code itself does not speak to the non-programmers' employers' ethical responsibility. So, in practice, this stuff rings a bit hollow.
Finally, when thinking about the ACM/IEEE Code of Ethics, I find it helpful to remember that most of the good folks on the task force aren't actually practicing programmers (though many of them were at one time or another). The task force was predominantly composed of academics who make their living teaching computer ethics courses. I don't mean to question peoples' motives; I found all my colleagues on the task force to be good and honorable folks pursuing ideals in which they passionately believed. I mean, why else be an ethics professor? But I really couldn't ignore the fact that most of these folks' passions will be essentially guaranteed places in the curricula of our universities once software ethics is legislated.
So I still can't figure out how a software ethics code makes the world a better place, even though the ethical practice of software development is a good thing unto itself.
Re:Management, anyone? (Score:1)
Just as management have a responsibility to define the requirements as clearly as they can and define reasonable dead-lines, you have a responsibility to tell them when what they demand is impossible.
If they want to throw more people onto a late project, don't just tell them it won't work. Tell them *why*, quote Fred Brookes, *reason* with them.
> Gantt charts and org charts are something that programmers should never see
Disagree. To do a good job, you need to know where your piece of the machine fits in, what it affects if you deliver late (if you have to make a compromise, is it better to devliver late or slightly incomplete?).
If you want to stick your head in the sand about management issues, that's fine too. But there's still a lot you can do. I'm sure you've seen the figures about the difference between the most and least productive developers. It's not magic, you can *learn* many of the techniques that the most effective developers use.
Read the books your manager doesn't and educate them! Not all companies are that bad. I work for a FTSE100 company and only have a small number of management horror stories.
Re:Management, anyone? (Score:3)
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...
Well said! (Score:1)
Re:Licenses and certification (Score:2)
Re:Bah, humbug (Score:1)
How about this:
In Brazil we don't have the profession that is called optometrist. Such work is done by oftalmologists only, that's the law. So, I went to the doctor's office this morning just to learn that my glasses are still exactly what I need, after 2 years since my last visit. She did a comprehensive examination, ok, but I wasn't feeling anything wrong when I got in there. I expressed my feelings about the need to go to a doctor to have e prescription for glasses and her answer was much in the lines of "would you trust your eyes to someone else other than a medical doctor?", so I saw there was no point mentioning that *that* is precisely what is done in societies where doctors don't have such a strong lobby. I have a friend who is an optical technician, perfectly capable of doing these things, but she's not allowed, so she helps clients choose frames!
OTOH, I have a degree in Business Administration, and I earn a living as a tax auditor. Guess who wrote the system for the company in charge of controlling parking tickets in the town I live...
Very personal and punctual examples indeed, but that analogy of "trusting one's life to an incompetent person" as having to do with writing good software = being a member of some computer bar is just too exagerated. Sure, it has been expressed in this discussion more than once.
Re:Erm... (Score:1)
One of the main differences is size. The *biggest* program I looked at/developed at uni was around 10000 lines. The *smallest* I've worked on since has been over 50000. Hell, I write 30000 lines of PL/SQL in the first few months of last year!
My 'credentials': I read CS at Durham just over four years ago (we had a similar course) and am now a software engineer (/developer/programmer/whatever).
Programming environments (Score:1)
And guess what I've picked for my last two jobs?
At my previous job, where my department had its budget restrained, my boss was really quite happy that my choice of software tools (which included gcc set up as a cross-compiler for two different targets) was nearly free of costs.
Re:Are we doomed? (Score:1)
Re:OSS Red Herring (Score:2)
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.
Re:Bravo! (Score:1)
*snort!* What a crock of bullshit. I'd like to see "a couple of smart kids" crank out a few million lines of code to compete with something like SAP R3, the SABRE airline reservation system, or any other significant piece of software. Give them an impossible deadline and a bunch of conflicting user requirements (none of which are any fun to write solutions for) and tell me what you think they'll come up with. Sure, you can find dozens (if not hundreds) of small start-up companies who serve vertical markets (e.g. web page design) that could easily be run by a couple of smart kids, but don't "kid" yourself that you're going to find one of those companies producing a monster ERP system.
Re:Bah, humbug (Score:3)
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
They write the right stuff (Score:2)
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 (Score:2)
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! (Score:2)
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) (Score:2)
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? (Score:2)
http://linuxtoday.com/stories/13652.html [linuxtoday.com]
Re: Bah, humbug (Score:2)
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:Erm... (Score:2)
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