Fog Creek Software
Discussion Board




Software Engineering licenses

In the past few years, some states such as Texas have begun to recognize software engineering as a legitimate engineering field and allow qualified candidates to become licensed engineers.

Here in Texas, many of the universities are now offering software engineering degrees. How common is this practice in other states? I believe Washington also recgonizes software engineering as an engineering field. Are there any others?

What do you think this means for the future of our industry? Do you think that in 10 years it will be common for larger companies to have licensed software engineers on hand to "bless" designs?

I read McConnell's "After the Gold Rush" a few years ago during the "boom" while demand for developers were still increasing as well as their salaries. Although I agreed with much of what McConnell wrote, I knew that the market just wasn't ready for maturity.

Today, things are a little different. Demand and salaries are softer and companies are beginning to learn that cranking out software isn't a guaranteed goldmine anymore.

With the boom gone, I can see how our industry might be slowly changing to the more mature profession that McConnell wrote about.

Where do you think licensed software engineers will fit into a more mature industry, say 5-10 years down the road?

Mark Hoffman
Tuesday, April 22, 2003

I find it almost inconceivable that the test of licensing will be some form of guarantee about how good a "big-picture" person the applicant is.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, April 22, 2003

In my personal opinon that would be completely the wrong approach, and is an obsolete concept from the yesteryear where we had "information keepers" (when information wasn't as accessible as it is now), to have "annoited ones" (which is what government sanctioned engineering designations are) in software development. Instead, quality comes about because of a process: Appropriate up-front design [UML, etc], documentation, code walkthroughs, peer reviews, etc. The cold hard reality is that professional engineers, despite their personal claims of martyrdom, are no more professionally, criminally, or civilly responsible for their creations than anyone else, though they like to pretend such.

Dennis Forbes
Tuesday, April 22, 2003

I think you're wrong about  professional engineers not being more responsible Dennis, at least in the eyes of the law.

When you become a licensed P.E., you're given the rights to sign off on something (plans, etc.) as being proper.  If what you signed off on wasn't indeed proper, then you can lose your license.

My wife is now eligible to become a P.E. after 6 years of school and 4 years of internship.  Her workplace is filled with stories of people that have lost their licenses. 


Tuesday, April 22, 2003

hopefully the licensing thing doesn't take off. i'd hate to see my earning potential reduced to what a licensed engineer makes...

choppy
Tuesday, April 22, 2003

I would love to see some actual statistics on the number of professional engineers who have lost their license, as what I've heard is that the industry is very similar to the medical industry: More of a protection racket than an accountability system, and where actual, bonafide sanctions are less common than speedy government service. In any case when you get down to it, if a professional engineer does something negligent that causes great peril, they can face criminal, civil, and professional punishment. How does this differ from any person who has exactly the same criminal, civil, and professional responsibilities?

Dennis Forbes
Tuesday, April 22, 2003

IMHO what our profession is missing is a "master/apprentice" relationship paradigm - in any workplace there should be senior developers doing design & rough implementations and junior developers "filling in the cracks", doing the scut work, and learning from the masters.

The problem is that business has a mental block on "paying people to learn their jobs" and feels that they shouldn't hire two people when one will do (not understanding that that one person will generally get annoyed with doing scut work and leave, leaving nobody in their wake that understands the systems).

More than PE's what we need is for those who make hiring decisions to buy into master/apprentice relationships.

Philo

Philo
Tuesday, April 22, 2003

"Where do you think licensed software engineers will fit into a more mature industry, say 5-10 years down the road?"

I would agree with people who think we may be there today.  Try and find a job as a windows developer without an MSCE.  a Red Hat System Administrator without your Red Hat Certification or a JAVA developer without your SUN Certification.  Can it be done? Certainly, but it is becoming the minimum requirement.

If you implement a system with MSCEs, and it has issues you can still claim you had the "best" people working on it.  Is it true?  Microsoft thinks so.  As in the 70's no one ever got fired for choosing IBM, the same will be for certification.  As for whether it will determine how successful you are as an "engineer?"  I believe it will become an addition to a college education.  You are certified to show a base level of understanding and more importantly a common working vocabulary. 

This will be a necessity as more projects are put under legal scrutiny.  I see where Dennis was going with his point "despite their personal claims of martyrdom, are no more professionally, criminally, or civilly responsible for their creations than anyone else," it is the "than anyone else" that is starting to prove an issue.  As an engineer you can be held VERY accountable for what you say will and will not work.  A bridge that collapses, a walkway that falls, or a building that implodes are looked at to determine if the engineer did in fact create the issues or more importantly did not prevent them.  And the firm as well as individual is responsible. 

It is that accountability I am beginning to see required in contracts.  Where a business is unwilling to accept that you "did your best" but the system does not work nor meet the requirements.  Unlike buildings where those requirements have been worked on for centuries, software is in its infancy. 

Also, the buyer is getting more adamant about what they want to see.  Many more contracts are bid on the project level.  You say it will take $2 million, that is what you get and if it fails a single requirement penalty's apply.  Go over budget, you eat it.  The expectation of failed projects being blamed on the requester is starting to go.  They hire us as the experts.  Like asking for an exterior door on the 115 floor of a high-rise, we are expected to foresee issues.

The lesson of the VASA [ http://www.abc.se/~m10354/publ/vasa.htm#I.%20Brief%20history%20of%20the%20birth%20and%20disappearance%20of ] applied to ship building.  Then engineering and soon software.  It will be interesting to see where the line really ends up being drawn.  Dollars will tell. 

Mike Gamerland
Tuesday, April 22, 2003

Dennis,

Why do you consider licensed engineers as government sanctioned "annointed ones" who are just "information keepers". I'm not certain how someone can come to that conclusion.

I would disagree that engineers are not held responsible. Legally, they can be sued for malpractice and the State can be petitioned to remove their licenses.

I agree with you that quality comes about as a process, but how does a company know that a person understands these processes, or even that certain processes are necessary? While having a license or engineering degree is not an absolute guarantee, it *is* an indication that the person should know what they are doing.

Mark Hoffman
Tuesday, April 22, 2003

The fact that software engineers are discussing licensing demonstrates the desperation now felt in this industry; not maturity or professionalism.  All I can say, is that it will be a cold day in hell...

Nat Ersoz
Tuesday, April 22, 2003

I got my Computer Engineering degree from Texas A&M about 6 years ago, and this was a favorite topic of one of my profs.

In order to be a P.E. you have to intern under another P.E. for x number of years.  If we start allowing programmers to become P.E., who are we all going to intern with to get the ball rolling?

Jason
Tuesday, April 22, 2003

sometimes i feel like i'm one of the only people on this forum who LIKES the fact that software engineers get no respect, and that software is not a "mature" industry. i'll let the ivy league kids with overbearing mothers go to medical school...i'll just continue making $14,000+ a month working at my kitchen table in my boxer shorts.

more seriously, i could maybe forsee people working on big boring enterprise applications needing licenses, because what they do is pretty well defined. if you can't figure out how to connect an input form to a database, you probably should be held liable for whatever you are doing. however I still see a lot of creative applications of software: doing things that no one has thought of doing yet, and i'd rather be in that boat.  dean kamen , one of the higher profile (and more prolific) contemporary engineers, is a college drop out.

choppy
Tuesday, April 22, 2003

Jason,

Actually, in Texas being an internship is not required anymore. From the Texas Board of Professional Engineer's web site:

"Although it is recommended that the engineering experience be obtained while working under the supervision of a licensed professional engineer, this is not a requirement for licensure."

(http://www.tbpe.state.tx.us/lic_basic.htm)

As of a few years ago, an internship was required. I believe this is a recent change. (Probably for the very reason you mentioned!)

Mark Hoffman
Tuesday, April 22, 2003

The comment regarding "information keepers" referred to an era of yesteryear where everyone's knowledge and responsibilities was heavily partitioned because information was so difficult to gather that the need for specialist was a necessity. It wasn't specifically related to engineers, but rather an idea that we had specific, life-long entrusted individuals for certain tasks, and only they would do.

My comment regarding criminal liability relates to the fact that every single one of us is criminally, civilly, and professionally responsible for our work. We can't throw up our hands and go "Sorry, I'm not a professional engineer, therefore I can't be held responsible for the gross negligence that killed that guy". In the eyes of the law having a professional designation is mostly a veneer of responsibility, as the same responsibilities and laws apply to all of us.

Don't get me wrong: I am not saying that PEs, or having "annoited ones", is always wrong. I like to make sure my doctor is a Phd and is medically certified, and perhaps where lives are truly on the line a board sanctioned individual may be worthwhile at least to audit the plans (just as a housing inspector comes out to see what you're doing). However I think the whole professional engineer designation is an illusion of competency when process and standards, and the measurements of the same, are what brings quality. People usually hold up crappy software as an example of why we need PEs, showing a gross ignorance for the whole time-quality-features balance that defines the industry (yeah all software could have perfect quality if it had no features . I just don't want to see the engineering racket start to try to give themselves job security by imposing themselves, in a statist manner, into a dynamic industry like software development so we can have a "professional engiener sanctioned spell checker").

Dennis Forbes
Tuesday, April 22, 2003

Damnit. It's too bad I didn't have a professional engineer certified spell checker for that last post. :-)

Dennis Forbes
Tuesday, April 22, 2003


I don't think that there are too many people advocating that anyone developing software has to have an engineering degree or be licensed by the State.

Rather, I think what many people are wanting is that software engineering be elevated to the same level as mechanical, electrical or chemical engineering for those that want to make the effort. I think everyone would agree that there is a huge difference in the skills of people who all claim to be software developers.  How does someone truly distinguish themselves from the rest of the pack? Certifications offer a little distinguishment, but the flaws in commercial certifications are well known.

By having the State recognize a person as a licensed engineer means that that person has at least a degree in engineering, has proven that they possess engineering skills and that they have experience in their field.

It doesn't guarantee the person won't ever screw up, just as a license to practice medicine is no guarantee against malpractice. However, it does demonstrate to the world that they have reason to put some degree of trust into the hands of the PE, until the PE proves otherwise.

Once again, I don't think the idea is to make everyone a licensed software engineer. Most engineers, be it electrical mechnical, etc are not licensed either. For software engineering, I think a primary reason is to allow a person to distinguish themselves from the masses of people calling themselves software developers, architects and programmers.

Mark Hoffman
Tuesday, April 22, 2003

"Rather, I think what many people are wanting is that software engineering be elevated to the same level as mechanical, electrical or chemical engineering for those that want to make the effort. "

My issue with this is that every mechanical, electrical, or chemical engineer I know left their respective engineering field to work in software, because software pays better!

choppy
Tuesday, April 22, 2003

There are serious problems with making software engineering a profession.

In the States only a professional can be sued for malpractice. All others can only be sued for negligence. The former is much easier for the plaintiff than the latter.

Also, although universitites have courses in software engineering which are supposed to teach students how to write software for the real world (as opposed to Computer Science which teaches people how to write programs for another world)  there are vast differnences between the two.

A bridge builder is working with constants that don't change. The forces that affect the structure don't change every two or three years, and most of the work involved could actually have been done by his grandfather. Software "engineering" by definition changes. If it worked before then it should have already been automated and so the engineer isn't going to write it.

Luckily the practical details will hit the idea on the head. You don't even know what country the guy who wrote your programs is in, let alone what qualifications he possesses.

Stephen Jones
Tuesday, April 22, 2003

Stephen,

I agree that malpractice suits against engineers could degenerate into the same cash cow that lawyers view medical malpractice suits. However, the clientele of a PE is different than the clientele of your average physician. But you do bring up an interesting point: Are PE's required to carry malpractice insurance?

I would disagree with your characterization that other engineering professions don't experience change. I'm fairly familiar with the construction industry and I assure you, the state of engineering changes there too. New techniques, new technologies and even new regulations mean that the way a bridge was built 20 years ago is vastly different than the way it is built today.

Some people like to paint software development as this mystical, magical process that involves secret incantations, smoke and a little black magic that has nothing at all to do with standardized practices, let alone engineering.

Regardless of some of the artistic sides to programming, there are still standardized practices that can be applied to most projects. Items such as requirements gathering, architecture and design skills, knowing how to properly test software, the use of patterns, etc.  are all items that a good software developer should be skilled in.

That doesn't mean that every aspect of software engineering will be applied to every project, not any more than the skills required to build a house are the same that are required to build a 120 story office building.

What it does mean is that there are essential skills that have been proven to help build solid software in a repeatable fashion and to become proficient in these skills takes more effort than just picking up a copy of "Learn VB 6.0 in 21 Days"

Mark Hoffman
Tuesday, April 22, 2003

Who are these people that pick up a book and become software engineers? I have yet to meet one but they are often cited as real people. I am interested in meeting one of these ne'r do wells and I will provide a large sum of chicken gravy and mash potatos to anyone who can arrange a meeting.

trollbooth
Tuesday, April 22, 2003

Trollbooth,

Warm up that gravy!

I can introduce you to plenty of people whose sole software development education consist of a handful of "21 Days" books and warez copy of VB.

These people would be fine if left to build small applications for ma and pa shops, but the trouble is that many of them love to brag about their "uber" programming skills because they can write a half-ass adventure game in VB.

During the boom, these cowboy coders manage to worm their way into many companies where some of them still cling to their jobs by a thread. They know nothing of design or testing. They just cobble together crap and then call themselves "Software Engineers" because that's what their business card says. When someone suggest a better way of developing software, they turn up their nose and deride "those college boys" as Ivory Tower Idiots. All the while, their miserable code fails.

Fortunately, the downturn is exposing these McProgrammers and forcing them to either truly learn what it takes to be a professional developer or find another industry in which to work.

Go Linux Go!
Tuesday, April 22, 2003

Uh, *I* have no formal software education. Should I stop deploying successful enterprise-level applications?

Philo

Philo
Tuesday, April 22, 2003

Philo,

No you shouldn't. I've read your blog and seen your post here. You are far from a cowboy coder. You clearly understand good engineering principles and it's also clear you strive to become a better developer.

The point that I was making in a previous post is that there are plenty of people who call themselves software engineers who have absolutely no engineering skills whatsoever, and have no desire to become better programmers. They've managed to earn a fat paycheck for doing very little and they will resist anyone who suggests anything that might change that.

Go Linux Go!
Tuesday, April 22, 2003

I think it's a good idea in principle. I don't know how on earth one certifies software engineers with some kind of standard test. Is there an agreed-upon and meaningful  body of knowledge for software engineers?

One thing to mention is that most professions that require a license (or similar) do require ongoing committment to continuing education. You have to earn so many "credits" a year to keep your license.

I have a good friend who is an architect. She had to intern for 10 years before she was *allowed to apply* to be a professional architect. And then she had to take 9 different tests (that lasted several hours each) and pass ALL of them to get her license. All of these tests were on different parts of architecture, some of it is material she doesn't use every day, either. She specializes in public buildings, mostly elementary and middle schools - different kinds of building than custom homes or performing arts centers, etc. She just had to earn that material to pass the test.

She does have to do follow up education to keep the license, as I stated above. On the good side, her firm has every interest in her keeping her license, so they support her continuing education by paying conference and course fees.

Her profession certainly makes me reflect on how there are no similar structures in software.

Sure, licensure doesn't separate all of the wheat from the chaff, but it gets a lot of it out.

Lauren B.
Tuesday, April 22, 2003


..and just to be clear, I'm not advocating that someone is not a professional developer if they don't have an engineering degree or a degree at all. I'm taking aim at the dolts that I think most of us have had the displeasure of working with.

On the same hand...I cringe whenever I hear someone refer to a programmer as an engineer. I don't refer to myself as an engineer nor do I let my clients refer to me as such because I don't have an engineering degree. I have a lot of respect for folks that bust their butt to get an engineering degree and I think it waters down their accomplishments when everyone calls themselves an engineer just because they are a software developer.

Go Linux Go!
Tuesday, April 22, 2003

Dear Go Linux Go,
                            Who writes adventure games (half-asssed or full-assed) in VB? Dark Basic, Power Basic and plenty of other flavors of Basic, but VB?

Stephen Jones
Tuesday, April 22, 2003

A lot of people on this board sound like they have a job working for MS R&D.  Now, I don't know whether a license would solve anything, or if there's even a problem, but come on people, you're not doing anything that special.  Apologies if you are working for MS R&D.

To answer a question above, no, you aren't required to carry liability insurance if you're a PE. but most PEs work for a firm that carries the insurance, therefore they're covered.

         
Tuesday, April 22, 2003

Lauren-
You'd think that's true, but whenever I see real software professionals talking, the same things come up over and over again about process, requirements, bug tracking, testing, etc. So there are some very consistent things that define a professional, and the absence of those things seem to generally define failure.

Go Linux -
I was busting your chops to some degree, but it did seem like you were implying that formal education is necessary to be a professional. I'll grant that formal education helps a LOT, but as you amplified later, it's not indispensible. It is certainly a good indicator, just not a boolean flag. ;-)

As for "engineer," don't sell yourself short. As an engineer let me say that being a competent & successful senior software "dude" is generally harder than engineering, simply because of the user management issues involved - you don't get to just sit behind a drafting board and work to a fixed spec. Ever. I wouldn't have any problems calling someone who's ridden a large software project through while being involved in both requirements and coding an "engineer."

Philo

Philo
Tuesday, April 22, 2003

"simply because of the user management issues involved - you don't get to just sit behind a drafting board and work to a fixed spec. Ever"

I'll grant that they work from better specs than we do, but there's a reason for that.  And it has nothing to do with the nature of the work.  Building an airport or a car or a gizmo is every bit as complicated as the most complicated software projects.

And if you think there isn't 'user management' issues in engineering, you've got another thing coming.

amp
Tuesday, April 22, 2003

Heh. I guess it depends on
a) How you define "user"
b) What kind of engineering

For some reason I was envisioning IC designers or hydroelectric dam engineers talking to the true end users (which is silly). However, in those cases I was thinking of the wrong "user"

Sorry about that. :)

Philo

Philo
Tuesday, April 22, 2003

" wouldn't have any problems calling someone who's ridden a large software project through while being involved in both requirements and coding an "engineer." "

I would and the reason is simple: They aren't an engineer.

Surviving a difficult situation doesn't grant someone the title of engineer anymore than surviving as a combat medic makes that person a doctor.

In today's society, everyone likes to have fancy and lofty titles and the word "engineer" gets appended to titles all the time to make it sound more impressive and give people warm fuzzies. You aren't a mere garbage man, you are a "Sanitation Engineer". What a crock.

If I called myself a lawyer because I read a handful of lawbooks and watched Night Court, I'd get laughed at. (And probably arrested and fined.)

Likewise, if you want to call yourself an engineer then go to college and get a Bachelor of Science in some form of recognized school of engineering.  Upon graduation, then you can call yourself an engineer.

Of course, if you want to hang out a shingle as an engineer, then you'll need to take a few exams that your State offers and get a license from the State.

There's a reason that the States regard engineers as people that have met very specific requirements.....

An Engineer
Tuesday, April 22, 2003

"If I called myself a lawyer because I read a handful of lawbooks and watched Night Court, I'd get laughed at. (And probably arrested and fined.)"

Agreed. But if you were an integral part of a large class-action suit from filing through verdict and appeals, I'd be more willing to call you a lawyer than someone who just passed the bar exam. [setting state licensing issues aside]

I consider myself a software engineer, and it has nothing to do with my BSEE or the 97th %ile I scored on the EIT exam before leaving circuits behind forever. It has to do with the knowledge I've gained and the work I've done in the software field.

And I'll never call someone an engineer just because they have the piece of paper from some school. Just as I feel uncomfortable calling myself a lawyer just because I hold the license.

Philo

Philo
Tuesday, April 22, 2003

What is a software engineer and how does this person's job duties and responsibilities differ from that of a specialist who mainly works for/at a large corporation (i.e. such as a programmer, tester, technical writer, architect/analyst, project manager, etc.) Is a software engineer simply a fancy name for someone who must wear many hats? 

I am being serious here. I don't believe I have ever read a definition from Steve McConnell. Does he have one? Does any of his books talk about team building and how one should construct a project team given all the various project scenarios and resource limitations that exist in the real world?

In the software development arena there seems to be three dominant ways of staffing a new development project.

Code and fix - Gather together one or more software developers (heroic programming geniuses) and have them build an application or a software system (several applications that work together in some manner) and hope that somehow everything turns out okay.

Big upfront design - Occurs only within organizations that have lots of money to spend? Gather together a bunch of hardware and software specialists and have them build an application (i.e. something that cannot be done in a reasonable amount of time by one or two people) or a software system.

Agile development - Gather together one or more software engineers** and and at least one customer and have them build an application or a software system.

** I really don't consider people who follow an Agile methodology to be "software engineers". While it seems that all team members are expected to be familiar/experienced with every aspect of the software development lifecycle (wear many hats), most Agilers seem to have specialized around a specific development platform (i.e. Java and all the tools and technologies that are typically associated with this programming language). Also, all the agile methodologies seem to follow the release-early-and-often philosophy which in some ways conflicts with certain existing software engineering best practices.

Mark Hoffman wrote, "Where do you think licensed software engineers will fit into a more mature industry, say 5-10 years down the road?"

IMO, before practitioners of our craft can even consider establishing any type of profession someone has to establish clearly defined roles and responsibilities for all to follow. Yes, you read the last sentence I wrote correctly, I am saying that bureaucracy is the answer! The fact is that companies often do things in haphazard, less-than-optimal ways and the only way that I know how to change this is to hold upper management accountable for their mistakes. Now having said this, I don't see how this is possible in circumstances that don't involve the safety or health of the general public. It seems to me that software development work will always be more of a craft than a true profession.

While law and medical students might be required to study the entire discipline of law or medicine -- once they graduate -- most are expected/required to choose a "discipline of study" and specialize. Why? Because the fields of law and medicine are simply too huge and diverse. Can't the same thing be said about the IT industry?

To answer my own question -- Yes, the same thing can be said about the IT industry. However, most employers only pay lip service to this fact and most developers cope with the current situation (chaos) by living in denial and playing the "as if game". That is, they simply act as if their only work responsibilities are software design and coding and quit as soon as they are put into a work situation that doesn't match their view of reality. Unfortunately, many people (i.e. authors of technical books and published articles) help to prop up the myth that most people can have a profitable long-term career by simply knowing how to cut code better than the person working next to them.

One Programmer's Opinion
Tuesday, April 22, 2003

A few points:

1. Licensing would be good simply in ensuring that someone can invest several years refining their software engineering capabilities - whether at university or in experience - and not be undercut by cheap turkeys. It would not be perfect, but it would be useful.

2. On the other hand, licensing would be dangerous if it simply equated degrees ( in CS?) with competence, for that's not what software engineering is about. Software design has commonalities with other talent-oriented occupatons like writing. Assessing competence would need to be done fairly.

3. It would be very dangerous if licensing simply imposed responsibilities on practitioners without providinig authority. Licencing must be accompanied by penalties against companies that USE software, not those that make it. As with the law, if companies get penalised, they pay for expertise.

4. Re point(2), it's scary to see people claiming MSCE and Sun certification represent competence.


Tuesday, April 22, 2003

I find it funny you mention "best practices". To me that word simply means that someone is saying, "The way I do it".

And that's really the problem with selling software as being an engineering discipline. Everyone has their own ways of doing things, there's no widely accepted processes (or even a widely accepted way of coming up with processes).

Not that I consider that to always be a bad thing. But I do consider it a showstopper to calling software engineering engineering.

Licensing people would be useless in software. It's not like accounting or law where if you've worked in a job you have transferable skills, due to the fact that there are standard accounting practices and laws. In software, if you take a new job and end up using even 50% of what you did in your previous job (in terms of process, methadology, tools, etc) you're doing really well.

So how would licensing people work when there's so much variability? It simply can't, because in this industry, one man's meat truly is another man's poison.

And the horse you rode in on
Wednesday, April 23, 2003

I always thought that one of the reasons engineers were paid so well was that they were expected to *find* ways to solve problems, not that they could apply their boilerplate knowledge to a specific issue and everyone would come up with the same answer.

I'm pretty sure that in just about any engineering discipline if you show five engineers the same "hard" problem, you'll get five different answers.

In addition, there is much of software development that should be repeatable but isn't, and that, I think, is what some of us are lamenting. Methodologies and processes that *should* be standard aren't.

Can you imagine a building architect being told "oh we don't have time for that silly stress analysis stuff. Just start nailing together 2x4's"?

Philo

Philo
Wednesday, April 23, 2003

Good discussion. I thought some more about this and how it would be difficult to build a practice of licensure in our field....

Back to my architecture analogy - my architect friend was kept at a very low salary before she became a prof. architect. Imagine. 10 years of experience (or more, if you
don't pass the tests right away) and you started at say $25K, and now you're up to $35K, only for cost of living increases over that time.

All this experience makes you almost as good as or just as good as a new professional architect, but you don't have the license. There is no way your salary can get get up to the next level.

Once you get the license, BAM! Salary leaps to $75K or more (I'm making these numbers up, but I'm in the right ballpark). Now you can start getting REAL merit increases, etc.

That's motivation to pass those tests.

In software, we already generally start high, and have no official, professional barrier to high salary, stature, or amount of responsibility. So, what benefit would a license get?

This problem is solvable, it's just going to take many years to work its way into the culture....and right now, the culture doesn't seem quite ready for it.

As  someone pointed out in my earlier post there probably is a common body of software knowledge; but again, defining precisely what that is and then making sure every degree program includes those things will take time.

Thanks!

Lauren B.
Wednesday, April 23, 2003

BTW, I don't really have any interest in software licensing to protect my job or justify my pay - all I want is for management to treat me like a professional and respect my opinion.

But I think the problem there is that the stakes aren't perceived as high enough. When a building architect says "if you do that, the building will collapse and people will die" or the lawyer says "if you do that you will go to jail" it generally gets people's attention (tho even then, not always). When I say "you cannot build this project in six months" ... who cares? If they try and fail, nobody dies. Nobody goes to jail. I still get paid. And generally nobody gets fired.

[shrug]

Philo

Philo
Wednesday, April 23, 2003

re:  hydroelectric dam engineers, talking to end users is 'silly'

It depends on how you define 'end users'.

You wouldn't believe the amount of face time you have to do when installing a single traffic light.

Meeting with the city manager.  Meeting with interest groups (some will object, some will demand).  Town meetings (open to the public).  Meetings with the contractors.  God forbid if you throw local politicians in the mix.

I couldn't imagine the amount of effort involved in putting something as big as a dam in.

amp
Wednesday, April 23, 2003

>"master/apprentice" relationship paradigm

Philo, you've been in too many management meetings old son, you're starting to talk like them now :-)

>you don't get to just sit behind a drafting board and work to a fixed spec. Ever

Sorry, but I don't agree. I suspect that is because we disagree as to what the end result is. If, to you, the end result is code, then you're right. But if you are really just writing a specification when you write code, what then? Your assumption that you /should/ have a water tight spec would be incorrect, because you are the one who has to write it (albeit in C or whatever). I think we have seen this discussion here before, but correct me if I am wrong (something about software engineers not being bricklayers but architects, and the compiler being the brick layer).


Wednesday, April 23, 2003

Philo perfectly summed up at least what I feel about the state of our industry:

"In addition, there is much of software development that should be repeatable but isn't, and that, I think, is what some of us are lamenting. Methodologies and processes that *should* be standard aren't."

Many people have come up with tests to indicate the quality of a department or company developing software. We've all seen the Joel Test, McConnel has a number of them, McCarthy has written them, etc, etc. Most of them center around a number of proven techniques such as prototyping, source control and proper project management techniques. The obvious idea is that if you aren't doing a majority of what the items in the test, you are going to fail at delivering software. And most of the test are remarkably accurate.

Now, if we took a straw poll to determine how many companies received an 80% or higher on these test, I'd be willing to venture it's a very, very low number. To me, that is the problem. The techniques that are widely known to help deliver software aren't even being followed....with predictable results.

My opinion is that while there are a number of reasons that these very basic practices aren't followed, a large part of it is because many software developers *simply aren't skilled in them.* Period. They need education.

Another reason is that many in management don't fully understand the complexities of delivering software. By elevating software development from a craft to an engineering field that is recognized by the state as such, it has the possibility of slowly raising management's understanding that software development is complex and that it's standard practices are invoidable. (Philo's blog perfectly demonstrates this problem.)

Can you imagine a customer telling an architect that he doesn't want to invest the time in building a level foundation. "It's too much time. Just start construction. I'm paying for this after all!!" The architect would simply tell him to go shove it. But yet, in our industry, we let that happen every day.

Mark Hoffman
Wednesday, April 23, 2003

Very good point Mark.  Software managers can push impossible deadlines, ship knowingly unfinished or improperly tested products, and skip over steps that promote quality, because if the software developers refuse they'll just find somebody else who will do it.

But management can't get an architect to agree to skip important steps to save cost, because the architect's license and reputation depends on the integrity of what is constructed, and the manager won't be able to get another architect to agree to skip the steps.

Until the software industry has something in place where managers' and/or developers' professional reputations are jeopardized whenever they cut corners improperly, poor quality will continue to be the rule.

T. Norman
Wednesday, April 23, 2003

Mark Hoffman wrote, "Now, if we took a straw poll to determine how many companies received an 80% or higher on these test, I'd be willing to venture it's a very, very low number. To me, that is the problem. The techniques that are widely known to help deliver software aren't even being followed....with predictable results."

That is why software industry needs some bureaucracy. If the construction industry didn't have to conform to local building codes does anyone really believe that many construction businesses would care about following standards and using widely known techniques?

Have you ever worked at/for a large corporation? Did you ever wonder how some of these organizations can be making so much money when from your vantage point it appears that headquarters is infested with nothing but incompetent managers? Well, in many cases it is because the money generating part of the business is regulated in some manner.

Mark Hoffman wrote, "My opinion is that while there are a number of reasons that these very basic practices aren't followed, a large part of it is because many software developers *simply aren't skilled in them.* Period. They need education."

Well, that seems to be what Steve McConnell is arguing about in his Gold Rush book. I don't disagree with your assessment of the situation (the skill level of practitioners) just your conclusion (biggest reason why very basic practices aren't followed). Also, what do you mean by "They need education"? Do most college engineering programs currently teach the techniques that are widely known to help deliver software?

Mark Hoffman wrote, "Another reason is that many in management don't fully understand the complexities of delivering software."

Bingo! IMO, this is the biggest reason why very basic practices aren't followed. Managerial misguidance is something all technologists rant about. Good management is more important than good technology.

Mark Hoffman wrote, "Can you imagine a customer telling an architect that he doesn't want to invest the time in building a level foundation. "It's too much time. Just start construction. I'm paying for this after all!!" The architect would simply tell him to go shove it. But yet, in our industry, we let that happen every day."

Unlike a software architect a building architect is almost never an employee of the customer! Also, a building architect can always pull out a copy of the local building code manual and wave it in front of the customer's face and say, "Sorry, but the government says you have no choice in this matter".

One Programmer's Opinion
Wednesday, April 23, 2003

" Do most college engineering programs currently teach the techniques that are widely known to help deliver software?"

Most universities that offer Software Engineering as a degree offer courses that teach requirements gathering, testing, design techniques as well as basic project management skills. Perhaps it isn't complete, but it's far cry better than what the average Computer Science major learns about software engineering.

And you had a good point about the fact that most architects aren't employed by the people paying for the project. That is a problem in software. However, I'm a consultant and even with that my clients tell will often say "Well, we don't have time for a design. Get to work on the code."

Mark Hoffman
Wednesday, April 23, 2003

Certification is an information problem.  Trust metrics.  Advogato played with it (but they solved a problem NO ONE CARED ABOUT, because it doesn't matter if some opensource guy happened to be better than another).

I think we're a decade or two away from a useful certification method naturally popping up.

revenge of the anonymous
Wednesday, April 23, 2003

Mark Hoffman wrote, "And you had a good point about the fact that most architects aren't employed by the people paying for the project. That is a problem in software. However, I'm a consultant and even with that my clients tell will often say "Well, we don't have time for a design. Get to work on the code."

Well, if you are an independent consultant (someone who finds their own work) then you do have the option to say no. Of course, you have to weigh your decision do so against the possibility of losing the contract.

If you happen to work for a consulting or staffing firm then you can only say no if your employer agrees with your opinion and is willing to walk away from the client. I know, this scenario falls under the "not likely" category.

One Programmer's Opinion
Wednesday, April 23, 2003

It doesn't really matter if you're an employee of the entity for whom you building something.  What matters is whether they can find somebody else who will do what they want if you refuse to take the shortcuts.

An accountant who is an employee of a software company won't cut out important steps just so the company can publish the quarterly profits sooner.  And that accountant can refuse to cut corners with confidence, because they know that the professional and legal accounting standards ensure that there won't be another accountant who will come in and cut the corners (with the possible exception of those who worked for Enron!).

However, the programmer who consults for the accounting firm often just has to do whatever crap the firm says regardless of the quality impact, because if they don't do it, another programmer will.

T. Norman
Wednesday, April 23, 2003

So what we really need is for managers to be certified.

.
Thursday, April 24, 2003

Someone mentioned earlier about medical specialisations and so on.  What this always gets back to is: who makes the decisions.

If software was run like a hospital, with senior doctors making the decisions that affect surgery and patient care, then software development would be ten times as expensive.

Until we have laws that require the _use_ and _deployment_ of software solution meet certain standards, business will not pay that extra cost.

The horrible part of all this is that developers get blamed for the inevitable failures.

On the other hand, software in the marketing sense often needs to be finished quickly, so there's a conundrum there.

.
Thursday, April 24, 2003

It is really strange that the accountants who work with figures that can have financial impact to the public have to be certified, but there is nothing for the people who make the software they use.

Software would not have to be ten times as expensive; it may be more expensive in the short run (just as it is less expensive if you shorten your testing cycle just to get it out the door quicker), but upgrading the quality of the people and processes involved saves money in the long run. Overall, it really isn't cheaper to hire lesser-paid code monkeys and forget about doing design and version control.

T. Norman
Thursday, April 24, 2003

You don't have to be certified to produce an accountant's or lawyer's or engineer's or doctor's software, but you don't have to be certified to produce his breakfast, his toilet seat or his toliet paper either.

There is no advantage to the consumer whatsoever in having certified software engineers. The same people that would be certified or do the certifying are the same people that have been responsible for the biggest software disasters of all time.

You want respect buy yourself a pedestal, you want more money rob a bank.

Stephen Jones
Thursday, April 24, 2003

Actually, I haven't seen any references in this discussion to wanting respect, thankfully. That sort of thing figures in engineers' discussions on this issues, but not here. It's not important.

I think what people are exploring are the structural issues that create issues in our professional lives.

.
Thursday, April 24, 2003

>...upgrading the quality of the people and processes involved saves money in the long run. Overall, it really isn't cheaper to hire lesser-paid code monkeys ...

This is certainly true, but it doesn't have anything to do with accreditation or 'engineering'.

The reason most companies don't wish to hire quality people is because they cost more, sometimes substantially so, and they think they can get by without them. Or they don't fit in the stardard pay structure and HR isn't willing to change. Or... 

Also, most, though thankfully not all, managers hate having employees that are paid more than they are paid. Which is often a consequence of hiring the best.

Several years ago I worked on a project that had 10 full time developers (most contractors) for one year. Three of us performed approximately 70% of the work and we were paid accordingly. We were all paid substantially more than the project manager but that didn't bother him in the least because we were producing. Shortly after the official launch, he left that department and was replaced with a more typical manager who absolutely hated the fact that we were paid more than she. We were all released as soon as possible even though there was still a few months worth of work left and the first service pack suffered as a result. Because the main project was complete this wasn't a huge loss to the company but if she had been the project manager on the original project it would have been toast.

This doesn't really have anything to do with accreditation or lisencing but rather more to do with knowledgeable, committed management that doesn't let ego get in the way of work.

Stephen Martin
Thursday, April 24, 2003

---"all I want is for management to treat me like a professional and respect my opinion. "----

From one of Philo's postings in the thread.

In general the thread has been missing it I agree, though it keeps on cropping up.

There are two themes that we keep seeing; the need to restrict entry to the profession and thus artificially inflate salaries, and renting software to ensure an income flow whilst sitting on one's 'arse.

Both great ideas, and only stopped from becoming reality by the customer's completely irrational aversion to being screwed.

Stephen Jones
Thursday, April 24, 2003

"There is no advantage to the consumer whatsoever in having certified software engineers."

Hmmm..Through all 50 replies on this thread, nobody once said anything about consumers or advantages to consumers.  I suppose one could argue that since we're talking about the end result being better software, it's sort of implied, but I don't think you follow the context of this thread.

You make a fairly broad blanket statement by saying that the people that would be certified are the same ones responsible for the "biggest software disasters of all time."  I'm guessing that that was just hyperbole on your part because it certainly isn't a factual statement.

Is your last comment suggesting that you feel that the only reason people want software to be elevated to engineering is because of respect and money? Do you really feel that everyone that is pushing for this is only doing it for their ego and a few extra bucks? That's their only motivation, huh? Couldn't be anything else, could it?

Mark Hoffman
Thursday, April 24, 2003

"There are two themes that we keep seeing; the need to restrict entry to the profession and thus artificially inflate salaries, and renting software to ensure an income flow whilst sitting on one's 'arse."

Huh? Are you reading the same thread we are? Or are you just trolling?

Where did anyone suggest that licensing be used to restrict entry to the industry? The discussion has been around offering licensing as an added credential, not a requirement for entry to the industry.

And I have no idea what you are talking about with the renting software comment.

Mark Hoffman
Thursday, April 24, 2003

One point overlooked on the licensing issue that should be considered is how the government currently uses professional licenses often has nothing whatsoever to do with professional competance. For example, let's say that you are a professional engineer and your spouse is a house-husband. You get laid off and the board gives themselves generous bonuses while declaring bankruptcy. In the stress of it all your husband divoces you and gets child-support since he was the primary caregiver for Jr. Now you are living on the street and can't find work. You send in money from panhandling but it's not enough - now you are labelled a dead-beat mom. Guess what happens next? Your drivers license and professional software engineer licence are REVOKED based on your 'non-payment' status. Yep, that's how it works now. Hey, good luck getting those payments in on time now that you don't have a car and can no longer work in the field you are trained in.

Ed the Millwright
Thursday, April 24, 2003

Dear Mark,
                  Maybe trolling a little, but look at what you've posted

---"Hmmm..Through all 50 replies on this thread, nobody once said anything about consumers or advantages to consumers. "---

The whole point of certification is to protect the user. Why else should the government intervene?

You look at the companies responsible for the really big software snafus and you will see the likes of Oracle, EDS and Siemens and the big consulting firms. Of all those guys working for them a fair number would gain certification on your scheme and a smaller number would probably be the guys giving out the certification. Nobody has made a remotely convincing case for the number of snafus being reduced once the same guys get their certification.

If you want a government registered scheme, and companies being obliged to hire a certain proportion of certified software engineers as they are obliged to hire a certain number of certified mechanical, or civil or chemical engineers, then you will have to make a case for somebody else but the individual certified to benefit. And also to prove that it is feasible which is another matter.

My comment in the last thread was more of a general one but time and time again on this forum we see ideas discussed (such as raising barriers to entry or adopting a leasing model for shrinkwrap) as if the interests of the user and that of the developer were indentical, when often they are diametrically opposed.

Stephen Jones
Thursday, April 24, 2003

I thought preventing big snafus was a benefit to the customer? 

I thought we used those big snafus as case studies on process breakdown?


Thursday, April 24, 2003

Dear blank,
                  The big snafus have been happening for over twenty years, and all the studying in the world hasn't stopped the same problems happening over and over again.

Stephen Jones
Thursday, April 24, 2003

I would say that that's because not ALL of the people have been studying them.

You've got your cowboy coders that don't care.

You've got your good coders that don't have authority with management (the "you start coding, I'll see what they want" syndrome).

Looks like licensing might take care of both of them?

Cowboy coders could lose their license, the good coders would say "hold on, we can't do it like that, I'll lose my license".

blank
Thursday, April 24, 2003

Sorry, but I just don't believe it will work. The good coders won't lose their license because they will have done everything according to best practises. The really big snafus happen because of design problems, not incompetent coding.

Look at the proportion of software projects that either fail totally, are handed in way after schedule or over budget, or are just plain defective, and then look at the percentage of professionals that are struck off in other fields and you'll realize why your schema won't happen.

Stephen Jones
Thursday, April 24, 2003

I think it'd work.

A design problem is a symptom of process breakdown, not a seperate problem in itself.  Inadequate requirements gathering usually. 

If the good coders (from architect, project manager, software engineer, tester,  on down...) followed best practices, there wouldn't be a snafu, so yes, they could keep their license.

I've never seen a project fail that followed commonly recognized best practices.

I don't understand your second paragraph.

blank
Thursday, April 24, 2003

Don't mind Stephen.

He's one of those types that have no solutions themselves, but rather choose to just snipe at anyone who has an idea.

I'm not in favor of mandatory licensing, but this was an interesting thread to read. It's a shame that Stephen came in and started tossing around accusations that people only want this for pride and money. He then goes on to say why none of this will ever work. We're all doomed I guess.

I think that offering licensing is a great way for professionals to distinguish themselves above the riff-raff.  I don't think making it mandatory helps anyone, but heck, if someone wants to get a license that shows they at least made more of an effort than the average Joe, then what the hell is the problem with that?

To me, for States to recognize software engineering is just a sign that the industry is slowly maturing. Hopefully, over time we will see things slowly change for the better. There will always be people like Stephen who will resist any changes.

Coder X
Friday, April 25, 2003


..and one more thing..

Software development is about the only professional technical field where someone can literally walk into it without any formal education or certification and still make damn good money. Off the top of my head, I just can't think of any other career that offers so much for so little.

If I wanted to work as a chemical engineer or physicist, I'd have to have at least a BS degree. But with software, many people landed a good paying job with very little knowledge and virtually no experience.

For that reason, it's not surprising that many in the industry resist any attempt at changing it or raising the bar of what constitutes a professional programmer. Our industry is full of uneducated half wits who know enough VB to impress their boss and when they continually churn out crap code, they can always say "Hey, that's the software business." and their bosses just shrug and say "Yeah. I guess. All those developers say that."

Yeah, I probably pissed off half the board with that last comment, but I'm just sick and tired of running into these "one trick ponies" who refuse to learn anything new, who refuse to accept the fact that the reason their code sucks is because they haven't a clue how to engineer it properly. It's much easier to blame management or the industry in general than it is to say "Gee. I don't know what the hell I'm doing."

Coder X
Friday, April 25, 2003

>>It's a shame that Stephen came in and started tossing around accusations that people only want this for pride and money.

And why else would programmers (ahem, "software engineers") care about licensing? The only arguments I've heard are "to show that someone put in the extra mile" (pride) or for more employment stability (money).

choppy
Friday, April 25, 2003

"The only arguments I've heard are "to show that someone put in the extra mile" (pride) or for more employment stability (money). "

Then you haven't been paying attention.

It's been said a number of times in this thread, but hell, here it goes again for the umpteenth time.

One advantage of having a State recognize it as engineering, is that it lends more credibility to software development as engineering, and not a craft that some anti-social geeks do between playing EQ and slugging Jolt Cola.

Will it happen? Who knows, but offering licensing is a step in the right direction.

Or, are you one of those uneducated half wits making 90K a year who are quite happy with the status quo?

Coder X
Friday, April 25, 2003

lending credibility is "pride." yes, i'm one of those uneducated half wits making 90K a year, pretty much happy with the status quo. are you one of those engineering grads who can't find a 45K a year job?

choppy
Friday, April 25, 2003

Dear Coder X,
                      From generation X perhaps? Certainly showing most of the symptoms :)

                      I may have "tossed in" the question of pride, but your certainly stirring it around and seasoning it well.

---" One advantage of having a State recognize it as engineering, is that it lends more credibility to software development as engineering, and not a craft that some anti-social geeks do between playing EQ and slugging Jolt Cola."----

                        If you need the government's placet to give your work credibility you are indeed in a sad state.

                       
---"He's one of those types that have no solutions themselves, but rather choose to just snipe at anyone who has an idea. "----

                        Before you talk about solutions how about setting out what the problem is? What is the problem?

                      a) People can get into "software engineering" who haven't a clue about the theory of programming? ---- Not true any more except for a few who slide in because they have the domain knowledge and other talents, and you need those anyway.

                      b) There are plenty of people in "software engineering" who are one trick ponies and their code sucks. --- Possibly true, but the proposed solution will do nothing since compulsory certification won't affect those already employed.

                      c) 90% Software normally ships buggy, late, way over cost, and often is quite unsuitable to what the end user wants. --- Yea, and if best practises in the industry produce that how is having them incorporated into law going to change things. Over a century ago doctors in Vienna found that more women who went to hospital to have babies died than those who couldn't afford hospitals and had the babies at home. Their solution was to find the cause and then disinfect the hospitals, kick-starting modern medicine. Your solution would have been to make it more difficult to become a doctor or a nurse.

                    d) "Nobody appreciates me and my mummy wants me to have a proper job like my lawyer kid sister" ---- Hey man, what's wrong with a Teddy Bear?

                The truth is that this thread shows one of the main problems with "software engineering". The tendency to jump in with an implemenation ("Hey, I've got this great idea!") and then look for things that it can solve a posteriori, instead of making a clear and effective analysis of the problem at hand and then seeing if there is an appropriate solution.

Stephen Jones
Friday, April 25, 2003

*  Recent Topics

*  Fog Creek Home