Fog Creek Software
Discussion Board




Software Certifications.

Our's is an Indian Software company.Recently my company has started taking efforts for SCI-CMM certification. I would like to know whether the good software companies in US and other places like Ireland/Israel are also equally eager for such certifications. The problem with too much process orientation is that it leaves the developers very unhappy.  They don't see much of benefit in it. It kills their creativity. The senior developers are spending more time in adhering to processes, documentation and meetings and less in developing/learning  new technologies. Is this a global trend or is there something terribly wrong here ?

curious
Friday, August 02, 2002

I think that Certification can result in Cargo cults:

http://www.computer.org/software/so2000/pdf/s2011.pdf

Process can be a good thing, but certification can just measure the outputs, rather than the processes effectiveness or appropriateness.

Ged Byrne
Friday, August 02, 2002

CMM measures process, not outputs.

the cluetrain
Friday, August 02, 2002


Yup. But's still a pain in the ass.

Leonardo Herrera
Friday, August 02, 2002

I don't know about SCI-CMM, but I have been involved with ISO-9000, which was required to deal with the local TEC (Training Enterprice Council).

The ISO required that specific processes be followed, and outputs from the processes (mainly forms) would be audited by the TEC.

The rather dysfunctional company I worked for gained and kept their certification by doing things the way they always had, and then going back and generating the necessary paperwork to satify the audit.

When we knew an audit was due, an internal audit would be carried out and then everybody would run around like headless chicken creating the required paper trails.

Ged Byrne
Friday, August 02, 2002

Software must be engineered, not created. A process is more than a necessity. When seriously taken and well adapted to the size and goals of the companies, it can just benefits the company.

However, some company only get certified to get certified. The lack of serousness can generate some overhead and not good results.

There is a good job of education to do. Developers must learn and experience the benefits of having a well defined process.

Fred
Friday, August 02, 2002

Talented developers intuitively use software engineering principles.  For some developers, no amount of imposed process will improve ther work.

ISO9000 companies can follow processes to the letter, document to the nth degree and still produce crap.

And other companies, seeing the ISO9000 certification will buy it.

Dan Sickles
Friday, August 02, 2002


ISO 9000, at best, brings you to CMM level 2.

I like CMM, but be careful.  You might want to read what PeopleWare, 2nd Edition, has to say about it.  Essentially, as you trudge to the higher levels of the CMM, you become risk-averse and tend to get into doing similar projects in the same niche.  (I think this typicaly happens when you're trying to get from 3 to 4, or 4 to 5.)  As a result, your company might trade a bit of innovation and outside-the-box thinking for a process that ain't that great.

But overall, if it gets people to think and improve, I like it, and CMM sure does that.

Matt H.
Friday, August 02, 2002

-------------------------------------------------------------------------
However, some company only get certified to get certified. The lack of serousness can generate some overhead and not good results.
------------------------------------------------------------------ Fred

Thanks Fred, thats exactly what I was trying to stay.

If processes are implemented right, they actually save developers a lot of time.  I think this is a more important goal than gain certification for its own sake.

Ged Byrne
Friday, August 02, 2002

Sounds a bit like the way I've seen a lot lo managers try to use UML. If you integrate UML into your development process from the ground up, it speeds up the process, and improves the quality of documentation and code.

However, in most places I've seen it used, it's been bolted on as an afterthought in an attempt to produce extra paper so show the project is well designed and implemented. It ends up just creating extra work, and doesn't contribute anything to quality.

I think this is why for many people UML ends up as "shelfware".

James

James Shields
Friday, August 02, 2002

Most places I've worked in that use UML do so because the developers want to because its seen as 'good to have on the resume', yup, we all know UML so we are eminately more hireable. The thing is that every developer had a different interpretationof say, how a object sequence diagram should be done, so in a design review we'd end up with developers trying to pust their interpretation of UML rather than talking about the actual design, its on my resume, but I hope to never use it again.

Alberto
Friday, August 02, 2002

whoops 'pust' - I mean 'push'

Alberto
Friday, August 02, 2002

Indian software companies are keen to get formal certifications because that's the sort of thing that impresses clueless management in other countries. Marketing 101.

As to the value of certifications, I've seen it used to protect complete garbage.

Hugh Wells
Saturday, August 03, 2002

There is some strong desire on the part of many people to have things "under control", and for those people a formal process program... ISO, CMM, whatever certification is just the ticket.  In this way, control implies restriction.

I'm not an anti-process person.  I recognize that some process is good - such as a standardized compile/build install process is goodness.  For those mindless tasks, automation is preferred and it frees me to concentrate on the parts of the problem/project that really needs it.

What I am opposed to, is the concept that analysis and design can be done by a completely mindless and checklist driven process.  That anyone would actually believe that something of quality, or something wonderful has been "engineered" (instead of created) based on the weight of the paperwork generated by the "process" is far beyond my understanding.

That sort of process is good when you are creating the same system over and over, and it has been created many times previous to the current attempt at recreating it.  That sort of process works extremely well in factories, where the same widget needs to be mass produced.

But... I think it was Tom DeMarco that posed a question, something along the lines of... "why would you create the same application over and over instead of creating a single generic and easily externally customized application that does the same thing?"

Why indeed.

It's like that old joke... helping someone find a lost contact lens under a streetlamp.  After some time searching without success, the guy asked the loser about where he lost it and the reply is "across the street".  Then why are you searching for it here?  "Because the light is better".

Certifying your rut condition does impress the unintelligent.

Joe AA
Saturday, August 03, 2002

Architects work in a very process oriented, yet creative profession.  Someone must have forgotten to tell them that that's not possible.

the cluetrain
Saturday, August 03, 2002

Oh yeah, they (archs) have to be certified too.

the cluetrain
Saturday, August 03, 2002

Cluetrain, architecture of buildings is less complex than software development. Also, it's a stable, old discipline.

Perhaps like Joe AA, I have seen multi-million dollar projects where incompetent design and development would be defended on the grounds the company was x-certified and x-executive was x-certified and who was I to question such stalwarts of industry. And do you know what, cluetrain, the products of that company were massive flops and the company is now out of business.

Dumb people will always look for crutches to defend their positions instead of discussing problems and solutions.

Hugh Wells
Saturday, August 03, 2002

"architecture of buildings is less complex than software development"

You have anything to back that statement up?

the cluetrain
Saturday, August 03, 2002

Yep.

Hugh Wells
Sunday, August 04, 2002

The yellow brick road will always lead to Oz.  If you want Kansas Dorothy, then you have to do something else...

I think Hugh is correct on all of his points.

cluetrain... have you ever considered the possibility that the real reson for the "very process oriented" building industry... that restricts the architect's creativity through what is know as local building codes, is to prevent the introduction of any radical change that might affect the job security of those in the industry?

ISO and CMM are also concerned with their job security and the more companies they "certify" the better theirs is, even when that company goes out of business.

Joe AA
Sunday, August 04, 2002

Joe -

I don't care as to the reason architecture is very process oriented.  I only brought it up as another example of a profession that is very process oriented, yet creative.  Much like software engineering.

I don't care if you agree with Hugh's points - they are wrong and he has nothing to back up his statements. 

You're not Hugh too are you?

the cluetrain
Sunday, August 04, 2002

Cluetrain... you are clueless.

Hugh has his experience and I have mine.  I can't speak for him, but I do speak for myself.  Which means I don't need an authority to back up what I know is true.

Unlike yourself... who only parrots what the majority poll takers approve.

Joe AA
Sunday, August 04, 2002

There are building architects and building architects, just as there are software architects and umm software architects.

There are standard plans and templates, and on those jobs the architect is more about having someone responsible and making sure the small specific details are taken care of.

But there are a deal of one off architectural projects which are highly technical, involve the use and combination of materials in a novel way, solve problems either to site or environment which are political as well as technical.

The argument that software architecture is more complicated than physical architecture is to make the assumption that most software is novel.

It isn't.

Certification doesn't make good architects, of whatever discipline its a minima definition.  We have no real equivalent in software because the fundamentals can be learned properly in around 18 weeks, the rest is experience.

Simon Lucy
Monday, August 05, 2002

["have you ever considered the possibility that the real reson for the "very process oriented" building industry... that restricts the architect's creativity through what is know as local building codes, is to prevent the introduction of any radical change that might affect the job security of those in the industry?"]

So Cesar Pelli's Petronas Twin Towers in Malaysia are not unique? They did not introduce any radical change? What about Frank Llyod Wright's Fallingwater? Or Frank O. Gehry's Guggenheim Bilbao? Not radical/creative enough for you?



["architecture of buildings is less complex than software development"]

Hahaha. Facts? Where are the facts?

Ian Stallings
Monday, August 05, 2002

["architecture of buildings is less complex than software development"]

My EXPERIENCES tell me otherwise. It may be less stressful, but the hours are similar, and the pay is less. Unfortunately, the sense of satisfaction can never be compared, and personally, it is the most rewarding part of any project.

I have experience with both Architecture (my college time, and my hobby), and S/W Engineering (how I make money, as there is none as an Architect), and they are very similar indeed. Note that there is only one type of Architect, the ancient tradition handed down to us from the pre-Babylonian and Egyptian masons to the current day Architects. All the others are just variants of 'Engineer' (a later, Roman tradition), no matter how they fancy themselves.

Codes (the International Building Code, required for compliance in the U.S., this year for the first time and replacing BOCA) work in the construction industy - they are there to save lives.  Standardization (eg, all wall studs are nominally 2x4, but 1.5x3.5 dimensionally) on the other hand, which you confuse with code, serves only to promote reuse in the manufacturing of typical "parts", to provide quality assurance in those manufacturing processes, and to simplify the structural engineering required for buildings (eg, I know that a 8-foot #2 pine 2x4 unbraced latterally can support approx. 1600 lbs, but i still have to spec them @ 16" on center whatever my load calc's come out to).

But the processes and education are completely different. Sure, you can draw similarities, but you can do that with any 2 things, it's simply a matter of perception. An architect is required, at minumum to graduate with a 5 year B.Arch from an NCARB accredited school (or with any BA/BS and a 3 year M.Arch), followed by 3 years of internship, then they are allowed to take the Architectural Registration Exam - a 5 day hell. What's on that test? Design anything and everything from a city, to an airport, school, playground, wheel chair ramp (ADA compliance is a must), Hospital, Car Factory, Single and Multi-family residences, etc, etc, etc.

The range and diversity of buildings and their intended use FORCE acrhitects to be engineers, planners, designers, and lawyers (blueprints are legal documents, if you aren't aware, as with their accompanying spec's). They must master all types of human requirements, and embrace the human experience. Most software engineers are capable 1 type of s/w design - SWIFT/Banking, RTOS, Distributed/Web Apps, etc. And they only do the equivilent of the construction documents. Whether it's their choice, or the role they've been put to, I do not know.

The architect is the "master painter" of a 4-dimensional experience. Do a google on DaVinci's 'SFUMATO' to see what I'm talking about, engineer. I've never seen software go beyond 1-d (fundamentally binary, but quantum gates approach). It's here, fundamentally where the processes differ. Software is in your face, you experience and interact with it most of the time. A building is sublime, and you interact with it also. If you know you're interacting with it (ie, where's the light switch? or the door?) then the architect has failed, excluding folies, parks, or carnival fun house.

And speaking of failure, we all know what happens when a building crashes? What about your software? 5-9's of all software projects are not life-support or guidance systems. 10-9's of all buildings have occupants at one time or another.

As for the specific proceeses, some Architects like bubble diagrams (very similar to Use Case diagrams), others prefer use and development of the 'program' (complete with massive amounts of overhead like ISO/CMM) before specific requirements gathering. There are hybrids, but those are the 2 main schools of thought (re. process) in architecture. Both arch and s/w make the greatest leaps with the venerable and preferred 'napkin' approach, as far as I can tell.

Here are some of my translations from Architecture to Software:

Int'l BC ~= Library, Component, Framework (you don't re-implement TCP/IP, or even an entire OS in each of your programs, do you?)

STANDARDIZATION ~= Methodology (XP, parts of RUP)

PROGRAM ~= CMM/ISO

BLUEPRINT ~= UML

BSOD/SIGFAULT ~= Grow Ivy

BUG -> Feature ~= DEAD SPACE

["Facts? Where are the facts?"]
Yes, good question.

-j
Monday, August 05, 2002

*  Recent Topics

*  Fog Creek Home