Slashdot Mirror
After the Gold Rush : Creating a True Profession of Software Engineering
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
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."
We already have a form of licensing, its called "education papers" aka a Degree.
;-)
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
Hey, post the source for your 3l33t h@ck3R -> english translater ;-)
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?"
...is to kill all the babies, This is certainly not the first gold rush and it sure won't be the last, everytime a new technology comes out a group of people say "Hey you don't need to listen to those old guy's over there in the IT (or whatever) department, I can get want you want really quickly because of this new thing PCs/VB/Perl etc"
What happens is that the first thing they implements usually sort of works but the forth or fifth thing never does.
While we are all excited about new stuff this process will continue and as we get older and hopefully wiser we will try and caution the next younger generation and we will be ignored exactly like as those who tied to warn us.
The problems with software engineering are fundamentally a management problem. It's been many years since the "Mythical Man Month" showed us how adding programmers to a project can only make it later because of communications overhead. But, many many managers are still doing just that. Furthermore, many managers are afraid of the technology, proclaiming loudly that they don't know anything at all about programming computers; good managers can manage anything at all without knowing about it.
Gantt charts and org charts are something that programmers should never see. But yet in many companies I work with, you can't get anything done unless you've got a big graph of the organization to help you find someone who is high enough to have some weight, but low enough to actually have some brains.
And even worse, technologies are often driven by management needs. Software costs too much, so all the managers want to get some of that good object orientated stuff on the project. So, they hire a few C++ programmers out of school and give them Visio. The programmers are told that their highest goal is re-use. Never mind that the system they are building is meant to handle 320 contradictory/arbitrary business rules for selling widgets to a client in New Zeeland. So, the programmers dutifully build the system to be as re-usable as possible. And, those 320 business rules never get used anywhere else but New Zealand. Meanwhile, the primary goal of re-use has caused the maintainability of the system to go to hell, because management ignored the faster/cheaper/better trichotomy and gave the team a week and half to design the system.
I could go on and on and on about management horror stories. Every place I've ever worked has been the same way, and a lot of those places were Fortune 500 companies. Books outlining ideal software development worlds are great. We really need some new ideas in that area. But how much progress can we make if our managers have never READ the books?
If tits were wings it'd be flying around.
1. Weekend experts
... cut and paste is a wonderful thing.
... but their ego's are too big to actually do it. "I think this can be done better ..."
:-)
2. Experts
The first category is made up of people who just bung together any old thing and it works - after a fashion. This group have made the most of code-reuse
The second category is made up of people who know all about their language, they're familiar with good design and when they write code they're usually pretty good at it. This group have made little of code-reuse. They know it should be done, they design mammoth systems and hierarchies to promote it
After that gross generalization we should recognise that there are shades of grey (gray - for our US cousins), but the gray is either very dark or very light
The book looks good. Onward with the march of engineering!
The art of programming has come a long way since its modern inception. Advances have largely come in stages: the advance from hardwiring to machine language, from machine language to assembler; from assembler to low-level compiled languages; and from low-level compiled language to high-level compiled (native and virtual-machine) languages.
The question now becomes: what next? What obstacles exist to the advancing of the art?
In my opinion, one of the main obstacles is the widespread use of C and C++. Both are low-level languages designed for close interaction with the hardware. (C++ may share features with high-level languages but is too tied to C to actually be an HLL.) This is a useful design for many tasks, but not for general application programming, at least at this time. Moving to safer, more powerful languages (Smalltalk, Dylan, Eiffel, Ada, ML, and Haskell to name a few with useful free implementations) is necessary, IMHO, to further the creation and maintainability of complex software systems. C still has its place of course -- critical inner loops will probably be implemented in many applications where the high-level language does not perform adequately -- but general development should move along to more useful tools.
I believe that the free-software community is uniquely prepared to do this, simply because language choice is a technical and not political problem.
Happy hacking.
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?
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.
...richie - It is a good day to code.
I'm graduating in a few weeks (not comp Sci) and still don't know the definition.
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
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.
Powers&8^]
One of the basic problems is that most developers think in a very narrow scope. Most of the time developers are called in to tackle a specific problem, and think only in the context of solving that problem, rather than thinking about the rest of the operating environment.
... whatchamacall ... enjoy.
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
"That's funny. I just had this conversation the other day!"
Some programmers already are compelled to abide by a professional code of ethics as terms of membership in either the ACM or the IEEE. Admittedly there is no substantive penalty for breaking these codes. But the codes are there and most members (that I know) take them seriously. Codes of ethics are good.
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?
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?
I have a degree in CS, 10 years professional experience, and I think this is misguided. Try as hard as you like, software just isn't like other "professions". Of course experience counts, but trying to become like other professions with certificates and other bullshit is the worst thing we could do. Professional bodies exist to monopolise fields of study and provide a bar to entry. Organisations like the American medical association and the Bar council are just protection rackets. There only purpose is to raise the salaries of those in the club, not "protect the consumer". We should irradicate them, not copy them.
Writing great software has more in common with writing poetry than law, medicine or even civil engineering. You can stuff huge organisations with "professionals" following "best practice engineering" and they'll still get trampled into the dust by a couple of smart kids working in a garage somewhere. I'm not saying you should hire any old moron to write software, but the trick is to have clueful (developer) managers and they can make up their own mind as to who to hire. Organisations *should* have the right to hire the neighbourhood children to write software, just like they have the right to go bankcrupt.
If you want to see something sensible on programming check out the programmers stone at http://www.melloworld.com/reciprocality
http://rareformnewmedia.com/
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...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
If programmers don't learn design, they will NEVER write anything of any value, and the bad software that they do produce will create troubles and inefficiencies that they can never begin to imagine.
When a company hires a programmer, the programmer MUST be a designer. Programmers who are not designers should go find another job.
The only thing a program that compiles and links is a bunch of code that does not violate the rules of compiling and linking. Apparently you call that a design, per se. Well, no, it's not a design. I will not accede that a wonderful design can be impractical and cannot work. That is a shit design. A wonderful design is created hour by hour, day by day, and programmed as an ongoing extension to an extensible design. The PROCESS of good vision, design and coding is what happens about 3 percent of the time. They are inseparable and essential. Take any one away, even for a brief period, and the whole thing turns to shit.
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.)
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
I have 3 of Steve's books and have found them all helpful. But it seems to me that this latest one is much less relevant to where I find myself now.
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
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.
****Gfx Scrollbar Special case hit!!*****
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.
Shut up and eat your vegetables!!!
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.
We need to remember that the field of software, at least for the forseeable future, is so competitive that results are going to be the only metric of use.
I haven't read the book, but I want to respond to the idea that software needs licensing and certification to improve. It's bull. Getting a license or certificate proves nothing except that you could get a license and certificate.
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.
First, make it work, then make it right, then make it fast, then, make it bloated!
When I did Soft Eng courses as part of my CS degree, I was left feeling very strongly that I had learnt nothing at all. All the talk about waterfall models, spiral models, and object models had left me none the wiser about a sensible way to design a real live large project. At the time I concluded that the only way to learn SE was to watch it actually in progress. So, is this the case or is it that:
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?
http://www.amazon.com/exec/obidos/ASIN/0138221227/ qid=948810740/sr=1-3/104-3114364-8512462
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.
****Gfx Scrollbar Special case hit!!*****
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.
It depends on whether we want to have accountability - of software to run airport baggage systems (refering to an oldish Scientific American Article called "The Software Crisis" which featured the Denver Airport programming disaster) - not to mention real mission critical systems like hospital life support, nuke plants, and my payroll. The SciAm 'solution' IS adopting 'formal methodes', at least for critical sub-systems - which basically means VERY expensive, time consuming, and very well thought out, kinda like the software in the space program - it may not be 'latest and greatest' but it's GOT to work, particularly for wo/man'd flights. I'm not sure I can trust the local whiz-kid or starving artist to fulfill that role. An artist or garage band can royally screw up and the worst that happens is nobody buys their art - but I sure wouldn't want a surgeon who has to go into a trance before cutting into the old appendix!
Licensing and professional organizations may SEEM like just an exclusive club but I think they add a sense of professionalism for critical jobs - they may still screw up, but then they can be 'disbarred' and booted out, held accountable - so we don't end up with just anybody claiming to be a power engineer, and having their system crash and kill thousands with the only repurcussions being 'opps! Sorry about that!'. But that's pretty much the state of the art with contemporary software licensing - the consumer bears the entire risk of product defect liability. Read any EULA. I'd like to see software where defects mean someone's head rolls on the production end! We used to call it "bet your job".
The Scarlet Pimpernel
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
I am contatly defending the craft of programming to my "artistic" friends who seem to have all decided that since what I make is useful and involves (eek!) math, it must obviously not be "creative". Looks like I have another Steve McConnel book to buy. If it's even close to as good as Code Complete, it's well worth it.
As a software consultant I change jobs somewhat frequently so I go to lots of job interviews and must stay in touch with what skills the industry is looking for. Invariably, when I'm asked to provide information on my work experience, nobody wants to know what aspects of the Capability Maturity Model I've found to be most useful in ensuring project success, what design and documentation techniques lead to testable event-driven user interfaces, or asked to discuss performance engineering trade-offs between a databases' conceptual model, logical model, and physical model. Nope, their requirements only want to know what programming languages, operating systems, and application types I've worked on. And they want the latest versions of this stuff as well. If you stay on and contribute to the successful conclusion multi-year project from start to finish, you will be really helping your customer but potentially cutting your own throat. And what's really ironic is that the worst programmers and engineers in this profession change jobs the most frequently and are therefor constantly exposed to the latest technology. I easily spend 10-20 hours a week and thousands of dollars a year (my book bill alone is approx. $2000/yr) keeping up with new technology. And it doesn't help when software tool vendors hawk their wares by duping IS management into thinking that using their IDE or modeling tool or methodology causes good designs, good code, good documentation to pop out the other end. A fool with a tool is still a fool. It still takes smart people doing smart things to make projects succeed. And until IS management understands this its going to be business as usual. And you will know when the change has taken place when the posted job requirements call for engineering skills rather that tool skills. Lets face it, a decent programmer can learn VB or Perl pretty quickly. But building reliable, scalable, distributed object-based systems on time and under budget ... that's tough.
I want to be alone with the sandwich
I was rather disturbed to see the plug for ThinkGeek at the end of the review. I was even more disturbed when I found out the book is $5 cheaper over at Amazon.com.
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.
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.
What is software engineering? Any 10 year old can learn to program (and many probably have) but are we trying to define the job in too narrow a fashion. For example, if we had to use a real-world analogy, would an IT career be caompred with the construction industry, the medical industry or the creative arts industry?
:-) )
... err ... training. If the problem is too complicated, iti s refered to a specialist and they can arrange for major surgery with this top notch indian team.
... Perhaps over time, IT will become as big a career option as medicine and the allied health services sector. However, it would be nice to have professionalism recognised in some standardised official way to reassure customers/clients they're not getting done over with shoddy work.
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
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.
For good software engineering practices to be adopted, I see one large hurdle. Everybody thinks Software Engineer == Programmer.
Programmers are the work-horses of the industry. They are the ones in the trench typing the code to get the daily jobs done. Perl is their friend.
Software Engineers are the ones who build large systems, they spend three-quarters of their time on design and review. This is the only acceptible way to build good large systems that aren't Crap. Perl is usually not their friend.
The problem I see is that most of Management assumes a Programmer can product a beyond-small sized program as good as a Software Engineer in less time. The Engineer will take 6 months to build a elegant system that scales well, and requires little maintenance in the future. The Programmer can do it in 4 month, but it will require a lot of maintenance and shoe-horning in the future.
Which one is better for the job? It depends, but in general Programmers are great at small one-off systems. The Software Engineer knows that true small one-off systems are very rare.
The Kernel Hacker is curiuos mix of Software Engineer and Programmer.
Comparing OSS and a need for licensing (and there is a need) is a huge red herring. The OSS process is intended to produce maintainable, repairable, and reusable code; who writes the code, on the other hand, is of no concern to the process. It exists whether written by rank amateurs or seasoned professionals. Thus a move towards licensure is neither pro- nor anti-OSS.
However, there are cases where who writes, or at least who signs off on the code is a concern. For example, industrial or other mission-critical software. Reputation may presently be sufficient measure, but over time a quantitative, rather than a qualitative, measure is required.
Licensing is chiefly a matter of lawyer-speak rather than a guarantee of competence (and any manager who expects otherwise is an idiot). This doesn't make it somehow unfair; licensure protects both the developer/engineer and the client through limits on liability and collective organization of developers/engineers. Bringing this back to OSS, any amount of code may be reused or appropriated from an OSS project; what matters is where you can lay the blame for project failure.
On the other hand, I worked as an electrical designer and the act of programming (PLC's, but still programming) was frowned upon by the old style EE's (and perhaps frowned is a nice way to say it). The attempt to bring software development into the engineering field can be viewed, and justly, as a power grab by the engineering profession.
I suggest another form of licensing, where a counterpart to the professional engineer's act (modify this as required for your jurisdiction) is enacted. This should give licensed programmers certain limits to professional liability, the right to organize and accredit programs, and a clearly stated purview for software engineering.
I don't, however, think that software engineering should become an exclusive profession with reserved duties, like many professions have become. Programming as an act is too broad for this, and the act of programming is certainly broadly distributed enough that anyone should be able to try their hand at it. With the rapid influx of computers into our daily lives, software should be written by all and sundry, most of all by the people who need them, and professional sw engineers should be only priviledged where absolutely necessary.
--
--
There is no premature anti-fascism. -Ernest Hemingway
The Bar Assoc and the Medical Board may protect their members, but they do a lot more.
They provide assurance of the credentials of the people they accept into their ranks. Some quacks slip through the ranks, but many fewer than would be able to practice were these governing bodies not there. The alternative is federal management, and that bodes ill.
I do not want a cheap, home-grown surgeon taking out my kid's appendix. I do not someone with little more than a strong opinion to represent me in a Court Of Law. I require proof of competency!
In the consumer market, software will most likely remain Caveat Emptor, but I do not accept the future where missle guidance systems, air traffic control software, embedded pacemaker logic and other critical systems are written by self-taught lowest bidders.
It is these fields where professional training, professional certification and licensing will debut. After that, we'll see professional designers offer higher-cost alternatives to commercial software - and some people will choose this over the quick and dirty versions.
Now, I won't argue that experience counts for a great deal. It's crucial. This is BTW why people fresh out of medical school have to do residency - where their every move is scrutinized and approved before it becomes terminal (pun int).
In mission critical, safety minded and heavy-financial application, where lives and big money is on the line, accountability is required. Even in many consumer goods markets, the sort of accountability and competency assurance that comes from having a Professional Engineer design the anti-lock brakes and air-bags is a Good Thing.
-- What you do today will cost you a day of your life.
> Why then is a person who can write a 20 line C++ program, a programmer?
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?
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...
second society
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
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
>> C will always be the language of choice for platforms.
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
CL-HTTP Hypermedia Server
Squeak
Pluggable Webserver and Swiki
MinneStore
GemStone
I agree completely with joss that programming is an art form. Akin to poetry, you can look at the world in a whole new way after reading a well written program. It reinforces the fact that there are many ways in which to view things. You can look at a table and see 4 poles and a wooden sheet. Someone else might see something else.
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!
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.
Note: I am a programmer with a CS degree, who isn't afraid of software engineering.
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.
--
--
Marc A. Lepage
Software Developer
I recently left a shop (in disgust) that had been taken over by people espousing "Software Engineering" and McConnell. I had been through many crunch projects, and was tired of it, and was willing to give anything a try to be able to go home once in a while.
So, I bought a copy of "Software Project Survival Guide", read it, learned it, loved it. I was willing to start to implement the good ideas, and ignore the ones that did not apply to our warez, and make a go of it. We still had to make software, but there might be a better way.
Well, it turned out the the push behind our embracing of "Software Engineering" was not a way to get schedules and process under control, it was a new, novel way for executives (who were lawyers and accountants!) to micromanage the architecture and coding of our systems! We would generate all of the "Upstream" documents, and they would be picked apart by people who couldn't tell the difference between C and ASM. So, we went back, and regenerated (meetings, meetings, months).
The other problem was that during the time we were generating the "Upstream" documents, we were not actually coding. That in itself was not bad, but to people above us, it appeared that the only output of my group was the paperwork. Since no real implementation work could be done, then it was SIMPLE for the execs to drastically change the nature of the product we were working on. After all, we hadn't DONE anything, right?
After months of this, and 3 complete sets of docs, I left. I went to a small software house, and hacked for a good 3 months to get back into the groove. At the new place, we use some of the ideas in the "Big Orange Book", but we are thankfully able to concentrate on the real job: Making software.
Bottom line: Software engineering is a means to and end. Beware the motives of those who would make you concentrate more on that process, and less on the actual output. Make sure that the people managing the process are actual engineers.
Customers could care less about how you made the software, they just care about the end product.
Being able to effectively plan out your story, your characters, and how it unfolds is taught to most college students who take composition and literature courses. A writing class generally helps a person become better at communicating and arranging their thoughts in a succinct manner.
It's a top down technique with bottom-up feedback and iteration (rough draft, edit, next draft, edit, etc)
On the other hand, the vast majority of programmers are not taught techniques for arranging their "thoughts" and putting them into code effectively. Software engineering courses on campus are little more than a *REVIEW* of current SoftEng literature, and not much of a workshop. And usually only one class is required or even exists. In an english composition class, you might have to write 5-6 essays throughout the course of a semester, all putting into practice the techniques you learned.
So much time is spent in CS departments teaching algorithms, programming languages, and analysis, that precious little time is left over for teaching effective software composition. Which probably means that colleges need to make a distinction between Science and Engineering. Right now, colleges have both CS and IT classes (IT usually emphasizes technology, and not science), and I think IT should add more requirements related to teaching style and technique. After all, the IT people are the "grunt" workers who actually have to go out and design/build the bridge, not study the materials engineering that goes into the steel used to build it.
As a minimum, "engineers" in addition to getting some required science background, should be able to concentrate in "design", such as the following:
1) requirements analysis
2) design (booch, rumbaugh, jacobsen, design
patterns, et al)
3) process
4) management/team building
5) risk analysis
And, like any good engineering school, there should be heavy emphasis on actual real projects.
This is no way takes away from the "art" aspect of programming. Can't a scientist use his skills for building a bridge or building a sculpture? All I'm asking is that the people building the applications I use and depend on (and moreover, that the nation's infrastructure depends on) be a little more "serious" and a little less focused on "coolness" vs design/maintainence.
of course, anytime someone calls for this, there are always cries that it will kill innovation, passion, etc etc. Personally, I see far more "failures" than I do innovation from most of the amateur coders. People like to focus on the successes, but that doesn't give you the whole picture.
Don't sweat it, dude. Most Slashdotters are kids in school (grade school, college, etc.) or Taco Bell employees. Not too many professionals here. Professinals don't dick around with this Open Source bullshit. It's just for the kiddies whose parents won't let them use their credit cards any more. We've seen the future, and Linux ain't it.
because it is compiled just like C, except that the compiler is 10 times faster. Unlike C, Oberon is type-safe and garbage collected. It makes a fine system-level language. The ONLY justification for using C or C++ is that they are widely used. Oberon S3 Native runs on bare Intel hardware -- no other OS required. Try it. "A Comparison of Object-Oriented Programming in Four Modern Languages", Robert Henderson and Benjamin Zorn url = "ftp://ftp.cs.colorado.edu/pub/cs/techreports/zorn /CU-CS-641-93.ps.Z", abstract = "The paper evaluates Oberon, Modula-3, Sather, and Self in the context of object-oriented programming. While each of these programming languages provide support for classes with inheritance, dynamic dispatch, code reuse, and information hiding, they do so in very different ways and with varying levels of efficiency and simplicity. A single application was coded in each language and the experience gained forms the foundation on which the subjective critique is based. By comparing the actual run-times of the various implementations it is also possible to present an objective analysis of the efficiency of the languages. Furthermore, by coding the application using both explicit dynamic dispatch and static method binding, it is possible to evaluate the cost of dynamic dispatch in each language. The application was also coded in C++, thereby providing a well-known baseline against which the execution times can be compared.", }
I agree, as most of the true "professional" software engineers I've met were incapable of writing software. And although you compared software to poetry, I believe writing software is more like writing a novel. Sure, there are "engineering" aspects to writing a novel, such as plot devices and techniques for character development. But basically, some people have the talent for writing a decent work of fiction, and most don't. From what I've seen of software development, the same is true there.
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.
Heh, yeah, EROS is the future, and EROS IS opensource. The 'professionals' don't dick with opensource software, they're too busy creating quick&dirty unstable solutions for Windows.
Yes they do, they assure credentials... but not cost-effecive quality. Instead, they create market inefficiency leading to wasteful pricing.
While they may start out as well-meaning -- imagine the world before they existed -- they unfailingly fall prey to the forces of the "invisible hand", market economics, and selfishly become white-collar trade unions in response. In economics texts, these organizations are used as examples: they use certification as a means of erecting barriers to competition. Perfect market theory would predict the availability of a continuous spectrum of quality of medical care or legal advice, such that you could find providers who you knew weren't quite as good, but who cost less so you might rely on them for non-critical issues. However, these services would threaten the profitability of the specialists, so they use their political clout to eliminate this source of competition.
Much of the training for certification for "professionals" is not directly related to quality of service, or is overkill for many applications of a profession. The most egregious example of this is teachers' unions: now (in the US) you need a degree in "education" to be a history teacher, rather than a degree in history. The extensive certification process is designed to make sure that unemployed historians do not become teachers and threaten the continued employment of teachers who have no particular skills. In the medical field we see extensively trained doctors monopolizing healthcare when lesser skilled practitioners could provide many more narrowly focused services.
There is some positive benefit to consumers of these organizations. It's a second order effect, so I'm putting it second, so don't walk away with the impression that it somehow balances out. That is, all of the dedication of effort to achieve "unnecessary" certification does provide some (game theory) information "signals" that the practitioner is "serious" about becoming a practitioner.
Of course, what I'm advocating here is that I should be allowed to get legal advice from someone who hangs out a shingle that says IANAL. Good idea? YMMV! ha ha. Look at it this way: it would open up a whole bunch of newly desirable domain names : )
Therefore the most important thing is to have all specifications written down, cause otherwise you'll find yourself wasting days and weeks arguing over what was included in the project and not.
Also, the *most* important thing is to have a clue about how your product is supposed to be used. Learn the terminology of those that are supposed to work with it on an everyday basis. Your application must speak *their* language, since they most likely don't know yours.
If you write software for, lets say, a law firm, you must take your time to learn a thing or two about how things work there. What procedures are done with a tight schedule? They must be optimized. What is frequently done by newbies? That must be simple. What is done by experts on an everyday basis? That must be quick, so that your system is not percieved as slow. (A seconds delay while I'm watching always seems slower than a minutes delay when I'm doing other stuff)
Yes, you must be a decent programmer, but unless you see why something as stupid as a talking paperclip actually can be called a feature you will get in trouble.
All opinions are my own - until criticized
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
There certainly are both good an bad sides of these organizations. I wonder how 'corrupt' medical organizations would be if the Bar Association didn't make it so easy to sue a Doctor for malpractice. ;)
These organizations need to be held accountable for the practice withing the field they claim to advocate. For example, it should be a part of every legal oath (is there such a thing?) to not entertain a frivilous lawsuit (with parameters provided and kept up to date, to define such a suit), just as all doctors swear to 'first, do no harm'...
Also, you seem to suggest that teachers have no skills. If I misunderstand, then I apologise. Teachers need special training to impart knowledge onto students, especially in the age group most resistant to being taught. They need special training is child psychology, conflict resolution, structuring of the learning process and other things, that make education uniform across schools and regions.
The requirement of being degreed in Education in order to teach in any field is not true at University levels, and also not adhered to in many private schools. In these areas, an expert in the field is preferable - especially in education. Once education is no longer required, and students make the choice of being there, then the Educational training otherwise required is no longer needed.
But I do agree with you in principle. Education is a great place for a lazy person to get comfy... This is why the whole idea of tenure prings up a systemic deficiency in the educational system. It takes literally years to remove a tenured teacher from their position. You need to use the words 'sexual abuse' just to get the overseeing 'bored of ed.' to wake up and take notice.
Returning to the topic of the article though, Software Engineering is not the same thing as programming. The difference is that a programmer implements the design of the SE. The SE needs professional training and programming experience, the programmer needs skills. The degree to which the programmer has freedom of design is a managerial matter, dictated largely by the legal department, and mostly (in the final tally) by the accountants.
The engineering firm I work in has very few P.E.'s. Most are degreed engineers who just never took the PE exam, or don't bother to keep paying the fees for maintaining the license. The thing is that the PE's have 'sign-off responsibility' which allows them to authorize design changes. Even if the changes are the idea of a non-PE. They have approval, they are the ones to get hit if the changes are wrong, and they get paid a bit more for that.
As an SE/Programmer (still fuzzy for us in CS) I can make design changes, and all I have to do is get buy-in to the idea from other developers and management. I can argue the point, and the only repercussion for failure is that it was MY idea. My professionalism, or the integrity of my career or employability, is never at stake. Unlike an architect who is branded for life if his building collapses, when my software crashes, I get to say 'oops' and try again.
There are significant portions of the CS industry where this is not acceptable. Colliding jumbo-jets is one such area. Cratering a probe on Mars, because they said feet, and you heard meters, is another.
A P.S.E. certificate would not really set up a racket. I really don't think it would. It WOULD reduce wages for people who do not hold the cert. The head architect(s) of the system would still make in the six figures per annum. The guys that crank out 10 KSLOC per week straight out of high-school, having read a single VB in 21 days book would realize their value in the grand scheme of things right quick.
-- What you do today will cost you a day of your life.
>>>C will always be the language of choice for platforms.
>>Why? Is this for technical or social reasons?
>Obviously, tweaked C code will always be smaller and faster.
In a time where a machine with 500Mhz CPU, 128MB RAM, and 10GB HD can be had for around $1000, the limiting factor is programmer productivity, not machine productivity. As I said previously, inner loops and performance critical sections may be best coded in C or assembler -- but less than 1% of the code in the typical software system meets that description. The Lisp Machine was a huge success, technically -- poor marketing, licensing, and pricing destroyed it. Squeak is doing a lot of amazing things for a project going nowhere. And even something like Oberon (which someone else mentioned) or Eiffel is better than C.
C code will certainly be smaller and faster, but assembly is smaller and faster still, and you don't see anyone using that, except maybe for some critical inner loops.
I think a shift to higher level languages is unavoidable, for economic reasons if nothing else. Since the inception of computers, everything (cpu, memory, networks, etc) have been getting better exponentially. The only thing in CS that has been getting less reliable and more expensive has been a line of code. High level language, perhaps not reversing the trend, at least help alleviate the problem.
> the information about programming and computers learned would now be about 15 years out of date.
:-) (Ok, so the C++ class was up to date.) How do I know? I finished my degree a few years ago.
;-) (Notice I didn't say learning is done for life!) I can go back to EA anytime.
Thats not true, its only around 10.
Was it a waste of my time? Partially. But I learnt a few gems that I wouldn't of learnt on my own. I was a self-learning already by the time I got to University, so didn't find the system to be all that beneficial.
I gave up a career at Electronic Arts to pursue my education. Do I regret that choice? No, because the degree is done for life
> Some of the best developers I know have either no degree or a non-engineering degree.
Agreed. Remember you don't need education to be successfull, but it will help in the long run, all other things considered.
Cheers
> A degree is not any form of licensing.
I didn't mean literally a degree is a form of licensing. I meant that it is being used like one, requiring it for jobs, and "dis-qualifying the people who don't have one."
I agree with the rest of your article. Excellent post.
Cheers
> I'm sorry, I had to; the irony was just too thick.
;-)
Now that was funny. Nice thinking.
Since you didn't attempt any rebuttal I guess the argument is over
Cheers
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++.
Some have wondered how OSS fits into this. Well - it doesn't really make any difference from the software engineering point whether the piece of code is open source or not. Good software engineering techniques can be applied for open source as well - and it is certainly being done. See Mozilla, for example. It should be noted, though, that most open source projects, especially smaller ones, aren't really disciplined with regard to software engineering, which makes them inefficient. On the other hand, for commercial software this is not acceptable; in the industry such projects get the axe, one way or the other.
Maybe you had a bad professors for your courses. Mine really knew his stuff. In fact, he recently started a Software Engineering major at MSOE.
There were a few good things about my SE class. (I only had one). One thing was that we were split into teams (not of our choosing). This simulates the real world. We also had project to work on where the professor was the client. And we did the project in 2 phases. (We only had 10 weeks!) The 2nd phase added some requirements and we got to see how good our design from the first phase was. We got to use Rational Rose, which is a pretty nice CASE tool. Once you put your model in as UML, you click the "Generate" button, and Bam! Out comes the skeleton code in either C++ or Java. We used C++ and put a MFC based front end on our app. Doing the actual programming was the easy part!
Then as an outside project I took the back end code and wrote a KDE front end for it!. And I did it in you a couple of hours!! I think this shows the importance of creating a design that is as non interface-specific as possible. (Depending on the purpose of the app, of course). One thing I like to do is think of what the back end code would have to look like so that the interface could be either text mode or GUI. It makes you think! Perhaps a good example of this is Linuxconf, with a text, X, and web interface, but I haven't looked at the code at all.
The SE course I took was probably on of the hardest (most work) courses I had in my four years, but it was also the most interesting.
I do agree that SE is a young field. Compare it to something like Architechtural Engineering. Architechture has been around for thousands of years. Computers have only been around for, what, about 50. And the idea of actually doing software engineering is even younger.
Hopefully the good ideas (I hate the phrase "best practices") in Software Engineering will stick and we will have better software to show for it soon. I agree with another poster though in that market pressures make this difficult for commercial software development.
It's like trying to build a skyscraper with a hammer and a saw.
Why do so many people and organizations want to build skyscrapers? Metaphorically speaking, the needs of many organizations and people are better met with a tent, or a hut, or a simple house. People waste so much time trying to save time, but when you are building a skyscraper, its complexity and sheer size make it difficult to do efficiently.
Steve M. had written some excellent books. I have not read ATGR, his earlier SPSG tried to strike a good balance between rigor and efficiency. I think that a better and more realistic balance is described in Kent Beck's Extreme Programming Explained. In this book, they tell you "You ain't gonna need it" when it comes to adding extra generallity (you might change your mind later, or have the project cancelled). Think about it before you jump into building a new skyscraper!
--
Mike
Hi,
I just came off a B2B integration project between a major ERP vendor and a Travel partner that had some major problems, and I was wondering if anyone else has had similar experiences. The project vision was pretty cool. We were making it possible for users of the ERP system to book Airline, rental car, and hotel reservations through their browser, and have their ERP expense reports be automatically populated with their major trip costs.
The project ran into problems because it was run across corporate boundries. Neither partner wanted to give the other access to its source control system, bug tracking system, or schedule system. The net result was 1)Lack of project visibility 2)Lack of change control 3)lack of version control of shared assets (the spec, xml docs, DTDs) 4)No visible shared schedule 5) History of the project stored in emails (when people left the project, their project knowledge was lost with their deleted email accounts)
Has anyone else tried to run a B-to-B (B2B?) software project across corporate boundries? Did you experience similar problems? Most importantly, how did you solve them?
Finally, has anyone implement an "eCommerce-in-a-box" solution like Ariba Inc., Commerce One Inc.? When doing so, did you run into any cross-corporate project management issues similar to the ones I
mentioned above?