Programmer's choice
Do you consider yourself (or aspire to be) a computer scientist, a licensed Software Engineer, or a software craftsman? All these terms apply to people in the programming profession, but the approaches are very different.
Is this even a choice, or can you be two or all three, or something else entirely?
Who do you think the software industry needs for a better future - a scientific approach, state involvement and structure, or community spirit?
P.S.
My collegues at Improving Enterprises are working on a podcast on this subject, to appear soon at Improving Podcasts. Stay tuned for more info and food for thought.
Just for the reference:
Computer science is defined by Wikipedia as a "theoretical study of computation and algorithmic reasoning" where computer programming is a supporting vessel . It is an academic discipline, practiced with the goal of learning about various aspects of computing.
Software Engineer is a state-licensed profession, much like a lawyer or a medical doctor, governed by a specialized state-supported organization. A candidate must sit a qualification exam, and, if successful, is granted a license and expected to conform to the rules of the profession. Professional licensing implies legal responsibility for quality of the product and ethics rules of conduct.
Software craftmanship approaches software development as a trade, a skill learned and continuously refined in a community of like-minded geeks. While craftmanship also involves responsibility for one's work, it is less structured and more based on one's reputation in the community. There are calls for licensing and certification within the craftmanship community as well, but with no state involvement.
Jane Prusakova
Senior Consultant at Improving Enterprises
LinkedIn Info
- Jane Prusakova's blog
- Login or register to post comments
Comments
And, finally, how would you
And, finally, how would you rather your colleagues [and clients and vendors] to behave - like smart people working on hard problems, personally as well as professionally responsible for the product they're putting out, or as tradesmen aspiring to become better at their craft through collaboration with their peers?
Jane Prusakova
Senior Consultant at Improving Enterprises
LinkedIn Info
I think to forward the
I think to forward the profession, we definitely need computer scientists. The basic reason is that computer architecture continues to evolve and it is computer scientists who are forging ahead and learning how to use it.
That being said, the world needs practical programmers who can apply what the scientists have figured out.
I honestly don't see how state certification boards would help the profession except that people who were truly incompetent would lose there state license. (Does that even happen with Profesional Engineers?)
As for craft, I have found that certifications are next to worthless. While they can and do test your ability in some aspect of software, your employer does not care. Further, I think we have all known fools who could and did pass a certification exam.
If you are making a career out of software, then you really owe it to yourself to expand your knowledge, learn from others, and teach others as apropriate. Very likely, if you like software, you are doing these things anyway. If you don't like software, then you should re arrange your life to do something else.
Certifications provide value
Certifications provide value outside employment.
For instance, in a recent case at my condos, a P.E.'s inspection of a building foundation told us homeowners what to require from the foundation company. The P.E. then followed up after the job to certify completion. Had we amateurs simply called a company from a Google search, we would not have known what we needed or how to evaluate what we got, and we would not have had the professional certification to back us up in any ensuing court action for shoddy work.
On the other hand, is that civil engineer guidance and protection scenario applicable to software engineers? I could *imagine* an analogous case, but I'm paid as an instructional designer to create illustrative examples. For instance, I could see the differentiating value-add in having a P.E. license or three in a consultancy, like a master plumber's license in a shop, even though not every dispatched plumber carries that certification.
csg2 said, "...I think we have all known fools who could and did pass a certification exam." Absolutely true; for instance, the original MCSE was diluted almost to worthlessness within just a few years of its inception (mid-90's?).
"While they can and do test your ability in some aspect of software, your employer does not care." I'm not sure about this one - especially in these employer-market times, something like a Cisco cert is frequently the interview-or-discard discriminator. Also, speaking as a former Cisco cert test contributor, the fools don't survive the proctored, hands-on lab portions of Cisco certs.
JMO, YMMV, etc. (and we need an acronym for "In these economic times")
Wayne C. Vermillion
Instructional Designer/Project Manager
I should have qualified my
I should have qualified my statement to refer specifically to software positions. My employer does not care that I am a certified LabVIEW developer. This indifference is apparently true for Java employers as well.
Certainly if I were interviewing candidates for a software position, that they were certified would not matter much.
For IT proffesionals, certification is the price of entry at many employers. Nursing professionals must also have valid certifications in order to work in that field.
I am not sure how clearly defining who gets sued in the event of a failure advances the profession. I can certainly think of a case where it would be applicable. There is a story about a piece of medical equipment that used radiation to perform its function. A software bug caused it to give a high dose to patients. So a state licensing regime would clearly put the liability onto the engineering company, or perhaps the engineer. Presumably his career would be over, or his insurance fees would go up. If his insurance fees went up, he would hopefully not make that mistake again.
The other point you bring up is that a professional engineer offers guidance on the correct actions to take in a complex and potentially dangerous area. I think the problem here is that for software, this can be very subjective. If you are laying the electrical system of a house of or a factory, there is a lot of legal requirements to be followed. You hire the expert partly because they know electricity, and more because they know the law. The software industry is not regulated, and so there is a lot more room for opinion. (I am making the asumption that two PEs designing the electrical system of a building will largely agree. I can't imagine that two software engineers planning a large automation system would.)
The big difference between
The big difference between software and many other industries is that software industry has trained its customers that it carries no responsibility whatsoever for the quality of the product. Every piece of software you ever get comes with a long "User Agreement" which relieves the makers of any and all liability for errors, unexpected behavior and losses stemming from using the product.
Nevertheless, these products continue to be bought and used, and business eats up the losses.
Jane Prusakova
Senior Consultant at Improving Enterprises
LinkedIn Info
The salient example of
The salient example of business eating losses were the years and uncountable millions (aggregate billions?) wasted in the late 90's and early 00's on customized ERP implementations by JDEdwards/ PeopleSoft/ SAP/ etc. These customizations made a lot of money for a lot of programmers, as well as for their consulting companies (full disclosure: I was a PeopleSoft trainer in that era, and personally witnessed the horrendously expensive and complete failure of PeopleSoft at Chrysler.) Years-long programmer engagements were the norm, and since work was almost always performed on site, non-salary expenses were astronomical. The client companies had no idea what the programmers were doing, nor -really- what the end result would be, but the programmers were trusted and well-paid.
However, a Gartner study showed that "90% of ERP implementation projects (were) late or over budget, 40% end(ed) up with only a partial implementation, and 20% of all projects in 1999 were discarded as total failures." Additionally, "ERP did not work as expected in 65% of cases." Businesses began wising up; for instance, Waste Management sued SAP's sales executives personally for duplicity and fraud in 2005.
My point is that, IMO, the software programming crafts approach did not hold up there. Were there "tradesmen aspiring to become better at their craft through collaboration with their peers" ? Absolutely, and the individual programmers were absolutely NOT to blame for the ERP customization debacle. But absent a big picture (and I'm looking hard at client executives and management who short-sightedly enabled the vendor and partner sales jobs), there were not enough "smart people working on hard problems, personally as well as professionally responsible for the product they're putting out..."
The good news, as far as I'm concerned, is that software engineers are now more well-rounded, more in tune with true business needs, not just content to milk a years-long engagement without considering the big picture.
"Those who do not remember the past are condemned to repeat it."
Interesting discussion!
Wayne C. Vermillion
Instructional Designer/Project Manager
It strikes me that the
It strikes me that the situation described is a management problem in any industry, not just software. Military contracts routinely have massive budget and time over-runs. Contractors working on your home who are not as good as their word can easily put you in a position of being over time and budget. (If they screw up half way through, there goes your schedule. If the screw up requires money that they won't pay for, you just blew your budget even if the extra goes to a lawyer to sue the contracting firm.)
Boeing's Dreamliner is very very late.
This is true for EULA and
This is true for EULA and the average guy who buys software via Walmart or Amazon, but it is not true for other kinds of software jobs. The first company I worked for was a System Integrator. They provided complete test and measurements systems to companies that made things. (Cell phones for example.) Warranty work was part of the contract. Everyone knew that the software had a risk to be buggy and this risk was managed up front. If too much warranty work was required the integration company had to eat the difference, not the customer.
In addition, many companies have software people for internal products. They tend to do this for IP reasons or because the knowledge needed to succeed is specialized and they don't want to train a new contractor every time a new software need comes up. If you write consistantly buggy code, you will eventually lose your job.
"to forward the profession,
"to forward the profession, we definitely need computer scientists" maybe true,
but do we want to be the computer scientists? Or do we want to "just get it to work" - as quickly and cheaply as possible, because that's what the business wants?
Jane Prusakova
Senior Consultant at Improving Enterprises
LinkedIn Info
Personally I want to write
Personally I want to write code that gets used. I want that code to be well written and the user experience to be good. Obviously time and money are constraints, so making the right tradeoffs between well written, functional code and the time it takes to write it is part of the craft.
I suppose in your original spectra, this places me in the craft category.
As promised, a podcast by a
As promised, a podcast by a bunch of Improvers about the business of software development: whether it is a science, or an art; and what the difference is between Computer Science, Software Engineering, and Software Craftsmanship.
Improving Podcast Episod 30 :
http://improvingpodcasts.com/2010/09/ep-30-computer-science-software-eng...
Jane Prusakova
Senior Consultant at Improving Enterprises
LinkedIn Info