How To Professionalize Programming

Since ProgrammersAreNotProfessionals and we're not interested in useless whining about it, let's just figure out how to fix it.

What can be done to set up

and what kind of curriculum / test can be devised for a professional license? Note that any test should specifically exclude One Star programmers and exclude any of the "you know how to use my crappy product / language" so common in industry certifications.

What good are associations, accrediation boards and licenses? They're just going to have people doing the mainstream thing. Part of the problem with programming these days is the social squatting that goes on.

But "professional ethics". This actually starts at the root of the problem. Start there. What are the professional ethics of a software engineer? -- EricHodges

The Code of Ethics of the National Society of Professional Engineers would seem like a place to start: http://www.nspe.org/ethics/eh1-code.asp

I can see how the market would support a code like that when bugs can kill people, but I doubt most software customers will pay a premium for ethical conduct. I also have doubts about how seriously NSPE members take that code. -- EricHodges

But how often do engineers get successfully sued for equipment accidents? Say a medical device or a car has a flaw? As long as testing and reasonable precautions are taken, generally the equipment designers are not held liable. In the Pinto case Ford was faulted because documents showed they knowingly took a $5 shortcut that increased risk. The GM truck gas tank issue is probably an exception. The jury was just stupid on that in my opinion.

A code of ethics isn't an ironclad procedure that people have to follow, it's a set of guiding principles. It doesn't need to have value to a customer. It needs to include practices that help bring value to your customers. For instance, if you're obligated to advice the customer formally that his design increases the time-to-market, and you have a better design (or toolset, or practice, etc.) then you can give them more value for their money. This is part of what a professional should do. -- DaveFayram

Everything needs to have value to a customer to survive. The ethics listed at NPSE have the potential to increase cost. Therefore software developed by people who adhere to that code has to survive competition with software developed by people who don't adhere to that code. When it comes to bridges (or flight control software), the customer is willing to pay the extra cost. I figure that's how NPSE's code survives. When it comes to disposable, commodity goods/software with no human life hanging in the balance and no onerous failure modes, I doubt the market is willing to pay for these ethics. That's why we don't have such things for software as a general good/service.

A professional should get paid. That's all "professional" means. If ethics price a professional out of the market he stops being a professional and becomes unemployed.

-- EricHodges

A professional is a guy who gets paid? Then the baristas at Starbucks are "professionals". Which makes the word "professional" utterly meaningless. Maybe we need a page on WhatIsaProfessional?, but I'll venture here that a professional is a member of a profession, which to me implies things like codes of ethics, licensing, etc. This is what makes doctors, lawyers, and engineers "professionals", and Starbucks baristas... not. -- MikeSmith

When you make coffee without getting paid you're an amateur coffee maker. If you do it for a living, you're a professional coffee maker. That isn't "utterly meaningless". Professional musicians don't have codes of ethics. They get paid. That's what separates them from amateur musicians. And the world oldest profession still has no code of ethics. -- EH

Without getting too much into licensure and codes of ethics (which may be appropriate for some professions but not others), permit me to further address the "getting paid" part. Another common distinction between a "professional" and a non-professional, found in some professions, is who does the paying. A person who hangs out a shingle and is available for hire by the general public is considered a "professional"; whereas a full-time employee of some larger concern isn't necessarily so. In the accounting field, for example, you need a CPA to provide accounting services to the public (in the US, other nations may have different laws and terminology) or to serve as a "senior" accountant in a company. You don't need a CPA to do salaried work under the direction of someone who is a CPA. Indeed, one cannot qualify for a CPA without several years of work experience, which would make for an interesting ChickenAndEggProblem were a CPA required to do any work.

In such professions, the opposite of "professional" is not "amateur"--the staff accountants who lack CPA certification still get paid. At any rate, the term "professional" is overloaded; one meaning is "one who gets paid", another is "one who is certified/licensed by an appropriate organization".

The problem with much of the above discussion concerning ethics/professionalism is that it really has little to do with ethics whatsoever. Instead, much of the debate seems to be be spurred on by a desire by some to outlaw/restrict implementation technologies that they consider to be bad (but are nonetheless widespread). Yes, I'm talking about the numerous "it's a breach of professional responsibility to even think about using C++" rants which seem to abound. While I'm not here to defend C++ (or anything else) or to attack its proposed replacements--such proposals quite severly place cart before horse.

That said, I could foresee a future where use of "unsafe" languages is restricted--currently, much application code is written in the "safe" ones rather than C/C++. However, the only way that this outcome out to come about is from within the profession. Were structures put in place to allow a group of "elites" to promulgate rules against the collective wishes of the programming community (and their customers), my fear is such structures would soon be co-opted in order to push a particular vendor's product rather than BestPractice.

A related fear is that programming "codes" could be used to implement some nefarious socio-political agenda. TrustedComputing? is one that comes to mind... many commercial and governmental interests would love a computing infrastructure wherein the user's ability to do what he likes with his computer would be (technically) limited, and use of BareMetal? implementation technologies (like C/C++ languages, or the use of low-level debuggers) would be outlawed (or restricted to bonded "professionals" who could be counted on not to bypass the security measures in place). While use of C/C++ for a given project is often a poor choice from an engineering perspective--having such tools available is a key element of programming freedom; one which we today take for granted.

It seems to me like the above situation is already basically in place, without the "bonding" for professionals. Most users cannot do anything with their computer except run applications which give then explicit functionality. The only company I know of that really seems to be tryign to change this is Apple with their new Automator system, which gives powerful visual scripting to users in an accessible fashion (which is scary, my mother can and has used it, and she still can't tell the difference between an email address and a web address!) -- DaveFayram

Don't confuse Grandma with the numerous technically-literate users out there. While the average user doesn't know how to muck with the internals of a computer; many others do. And many of these knowledgeable users then write applications which provide the functionality in question for the rest of us. Hollywood would love, for example, a computing infrastructure wherein it is impossible for anyone anywhere to watch a movie or listen to a song without a royalty being paid. As the current computing infrastructure provides low-level access to computers for those users who want it (as well as related things like file systems, network protocols, etc.) such a system is currently impossible to implement.

But what if instead of a computing environment where files could be treated as bit-buckets (and thus manipulated by possibly-untrusted applications), we had one where only "approved" operations could be performed on objects (and trying to do otherwise was illegal?) There might be some software-engineering advantages to such a system (and it might be appropriate in some contexts), but in the general case, the harm inflicted upon users by such a thing would greatly outweigh any supposed benefits to users.

Now, such a thing is certainly not a necessary outcome out of the professionalization of programming. Many professions manage to continue acting in the public interest, despite attempts by big bizness (and others) to hijack the machinery of professionalism for selfish ends. (And, TrustedComputing? might well be inflicted upon us without any attempt to professionalize programming). But it's something to watch out for.

As always...be careful what you wish for. You might get it.

There already is such a system, it's called StaticTyping. And it's something that programmers are stupid enough to do to themselves.

As a note to whoever comes after: the discussion below appears to be completely ignorant of good type systems and how they can be applied by the programmer in her programs to improve expressivity. Here be dragons. --bh

Of course, there is probably a wide difference in opinion on what "expressivity" is and how to objectively measure and/or score it.

Certainly. However, the idea expressed below that "compiler writers" are imposing limitations on programmers in statically typed languages is just bizarre. If you're writing a program in a statically typed language, you control your types; and they can reflect your business logic however you like. (At least, in good type systems.)

Don't confuse StaticTyping with TrustedComputing?; the two are not the same thing. A strong type system (static or dynamic) is certainly useful (if not essential) to successfully implement the latter--if a program is prevented from subverting the type system (or otherwise violating the invariants) of the underlying AbstractMachine the program runs on; such can be used to safely execute untrusted code. JavaApplets are a well-known example. However, TrustedComputing? implies far much more: namely that the user who owns the machine is blocked from carrying out certain operations he might like to carry about (including operations which might be perfectly legal), for the benefit of someone else.

Static typing is an authoritarian doctrine where the implementor of the language decides how you can and can't use it. The language implementor says ahead of time "yes, you can use that function with that structure" and "no, you can't use that function with that structure". Why? "Because I say so, because it is convenient to me."

Richard, you're starting to venture into topics you apparently know little about. Topmind's opinions on TypeTheory are more credible than this rant. Allow me to correct you:

Strong typing is a property of a programming language wherein inconsistent/nonsense operations (such as trying to take the square root of a scrollbar) are disallowed by the language implementation. In statically-typed systems, such verification is performed before the program is run, typically at CompileTime; any inconsistent operations cause failure at that point. (JavaVirtualMachines perform additional checks at class-load time). In dynamically-typed systems, verification is deferred until runtime; often at the point where the operation is to be performed. Smalltalk/Self are of course dynamically typed systems; if you type "aScrollBar squareRoot" into Smalltalk you'll get DoesNotUnderstand.

The only real difference between dynamic and static typing is when the check is performed. Smalltalk allows you to "hack" DoesNotUnderstand such that other semantics besides an exception occur on a type error; Smalltalk does not allow you to subvert its type system or its runtime.

Some languages provide type-unsafe "escapes" which allow programmers to break the type system (if they are not careful). C/C++ make it frightfully easy to do this; which is why many consider them unsuitable for many sorts of programming.

In virtually all modern type systems (including static ones), the language is quite flexible in what it allows and what it doesn't. Just because JavaLanguage, Pascal, C, and a few others have crippled type systems doesn't indict static typing. Do some research on ML and its derivatives if you want to learn more.

Now, strong typing can be used to put draconian restrictions on users; however this is seldom a programming language property. If I define a class in Smalltalk, I can make it respond to whatever messages I like; and have it return DoesNotUnderstand to anything else. This capability can obviously be used for obnoxious purposes--like anything else--but that's an issue for you to take up with the application programmer, not the language designer.

Trusted computing is an authoritarian doctrine where the implementor of the OS decides how you can and can't use it. The OS implementor says ahead of time "yes, you can use that application with that object" and "no, you can't use that application with that object". Why? "Because I say so, because it is convenient to me".

In that sense, TC can be viewed as a type system. But all TC implementations I'm aware of are dynamically typed; questionable objects are inspected for signatures (backed by crypto so they cannot be forged) before they are used. Given the sort of attacks TC systems need to defend against (swapping out of EEPROMs, modification of circuit boards), systems based on static analysis are insufficient.

Type safety has always been a blatantly stupid approach to security. First, because it is obscure and impossible to understand. Second, because it has an incredibly coarse grain. Users want to allow or deny access to individual objects or groups of objects, not types of objects. The only reason why language implementors prefer non-working fads like type safety over proven systems like capabilities, is "because it is convenient to me".

In most cases, the purpose of type safety isn't security; however it has its applications there. As stated above, StaticTyping is often insufficient because of the possibility of post-analysis tampering by an untrusted party.

You might go read AdvancedTopicsInTypesAndProgrammingLanguages.

Apparently I was unclear as to my meaning. In a statically typed system, the compiler writer decides in advance that "someObject someUndefinedMethod" won't compile. The compiler will simply refuse to compile it because it is the compiler writer's wish to not run the method. In a dynamically typed system, the compiler writer has to compile the method regardless of type and even has to try to run the method with the wrong type. Of course it will fail, but that's irrelevant. What's relevant is that it will try. What's relevant is that the system WILL succeed in running programs from the non-empty set that are correct but whose type safety can't be determined statically ahead of time. What's relevant is that despite the compiler writer being in a position of power, they don't abuse this power to place burdens upon the user but take up the burden themselves.

It depends on the language. Nothing prevents a statically-typed language from providing user-definable DoesNotUnderstand semantics (in a way similar to Smalltalk); some of them do exactly this. Java programmers can use reflection APIs to determine at runtime if a given method exists for a given object; and take whatever recovery steps they like if it doesn't. Or they can use the standard syntax, in which case the compiler will guarantee it for the programmer. However, in languages with good type systems--forcing runtime lookup in this manner is usually not necessary. Besides, the proper way to view static/dynamic typing (like many other things) is on a continuum, not as a binary decision. Some of the interesting new languages out there are taking this approach.

And don't assume I don't know what I'm talking about just because I think in a different way from you, because I have concerns that you don't.

Certainly. Of course, you'll extend the rest of us the same courtesy in return, naturally.

Now regarding TC. In the situation where the user orders a program to process an object which it can process but whose type information is wrong ...

But a strongly-typed (dynamic) system doesn't obey, it says DoesNotUnderstand. You're again confusing static typing with strong typing--what you want (to avoid TC) is the OS-level equivalent of ReinterpretCast?; the ability to tell the OS to ignore an object's type and treat the thing as a BitBucket. In other words, weak typing. PointerMetaprogramming. Which Smalltalk does not provide you.

When a message send returns DoesNotUnderstand, the state of the object being sent the message isn't modified; and no useful information is returned, other than the given method doesn't exist. All static typing really is is an examination of the program up front, and the determination that it will never say DoesNotUnderstand. In many cases, the typechecker can prove that a given program will say DoesNotUnderstand for all valid inputs. Now, I'll agree with you that languages with static typing ought to provide dynamic queries if you want them (if nothing else, to handle those problems for which typechecking is undecideable), rather than failing if type-safety cannot be statically proven; but many languages do that.

The implementation detail of when a type check is actually performed is irrelevant in this situation because it never affects the user either way. And this is because the types of applications and objects in an OS can't be changed by the user in a TC platform.

Exactly. Which is what I've been trying to tell you. Glad to see we agree. :)

MoreHeatThanLight, Richard. Your entire protest was just an elaborate way to take back your statements without admitting that you were wrong. Next time, just say, "Oh" and let the conversation move on. -- DaveFayram

I was nosing around http://www.insecure.org today, and found a link to a GNU.org document which I hadn't stumbled on before, specifically the short story at http://www.gnu.org/philosophy/right-to-read.html

It immediately made me think of this wiki page. The idea that programming should be professionalized suggests that it should be given the same weight and import as the position of a doctor or lawyer. On the surface, this sounds attractive. But the problem is, programming isn't something that just programmers should be able to do. Computers are tools, and while they may be fantastically more complex than a wrench or hammer, they are still ultimately just tools.

Once you need a license to program, then suddenly it's discouraged to program without one. In a world where DigitalRightsManagement, constant surveilance, and SoftwareIsInEverything? become serious issues, this is tantamount to a power play for control of the medium upon which the future of society will base itself. Computer are being used everywhere.

While I'm certainly not accusing Richard of taking this line of thought, I couldn't help but follow it myself. In a world where software controls everything, people who control and create software and computers are very poweful. Disturbingly powerful, even, because their craft is so arcane that they could be doing nearly anything and you'd never know it. So, by making a way to control the programmers (and only allow those you trust to become programmers), you'd be able to control them. Since this would include interaction designers, this sort of scenario would be a best-case scenario for Richard's craft. Again, I am not claiming Richard believes the above, or even that the above is necessarily correct. It just came to me that it is one possible outcome. -- DaveFayram

The era of big business controlling software is coming to an end. The era of government controlling software never left the feverish dreams of paranoid schizophrenics. Who's left to control software that has any kind of nefarious agenda? Oh yeah, end users.

So we're really talking about a power play between programmers and end users. And because for the entire history of programming, programmers have held all of the power, it isn't a surprise that programmers would perceive end users as having some kind of nefarious agenda. Not that I think you do Dave, but I have this suspicion that many programmers, of the "hacker" variety, fear end users.

(Parenthetically, I used to respect hackers. But that was back when I equated hackers with crackers. Now that I make the distinction, I despise hackers.)

Please keep in mind that interaction designers are agents for end users and that they themselves could be regulated. So it really all boils down to end users. -- RK

Which of the definitions (numbered 1 through 8) are you going by? (http://www.catb.org/~esr/jargon/html/H/hacker.html) None of the above, I'll bet. -- Doug

You know KillYourDarlings? A hacker is the antithesis of that best practice pattern. It's someone who loves to create darlings. I think Mel in The Story of Mel epitomizes hacking. -- RK

Ah. That's an interesting view of it. It seems to me possible that the best hackers are the ones who realize that and do kill their darlings. I don't see why such people can't exist. Mel has been called a CowboyCoder, which probably fits one of those 1..8 definitions as a subset. At any rate, your comments would seem to apply to a large number of coders, so that's enough to make your point.

The original point was to try to distinguish, say, very talented craftsmen (of software) from mere brute force coders, and the two groups certainly exist. Other terms like "guru", "wizard", etc, don't seem to have the same flavor. -- Doug

Richard, the battle for control of software is still going strong in America. Both business and government want a piece of the action. It's less about the actual code now (they know they can't win that battle) but more about what kinds of rights users have for that code. I know most software developers would love nothing more than to completely unfetter their software and allow it to do anything it possibly could (assuming they can still feed their families).

What's changing is the rights of end users to use software. Now, when you buy software you don't really buy it, you agree to use it under certain terms in exchange for money. This is not a programmer-created patter. It's a corporate pattern. Please don't assume that the end users get any say in the software they use. Most do not. Most simply don't have enough dollars (or TimeIsMoney minutes) to use the alternatives to their awful software suite.

If you think there is some evil coder out there churning out Word for the sheer diabolical fun of it, think again. No. Companies want to use DRM and law to control what you can do with your software and when you can do it. They also want to control your media (because speech leads to knowledge and knowledge is power). -- DaveFayram

I don't think it can be professionalized because software development is mostly a psychological problem and not a technical or mathematical one. There are myraid ways to get the right output given a set of inputs, but very little objective that tells us what is the "best" beyond performance metrics. The only possible way I see out of the psychology trap would be to create and enforce "best practices" based on somewhat arbitrary selection. In other words dictatorship. But obviously this will squelch innovation, experimentation, and critical thinking. --top

See DesignerFraud?, DisciplineEnvy, RealProfessionalsGetSued

SoftwareEngineeringCriticism

CategoryHowTo, CategoryProfessionalism

EditText of this page (last edited October 5, 2014) or FindPage with title or text search