The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Programmers attitudes to Software Standards

I'm doing some research into software standards and would like to know what programmers think of them.  Particularly interested in the ISO 9000 family and the SEI Capability Maturity Model.  What's good about them and what sucks?
John O'Neil Send private email
Sunday, November 21, 2004
 
 
ISO 9000 and CMM don't impose any particular standards, they just require you to have standards.

Most programmers don't like busy work. Your standards should help the developers do their job; if they're chafing at doing something, the first question to ask is whether the task is really necessary or whether it's just a ritual.

Also, most standards tend to force development into a waterfall process. Experienced programmers I know hate waterfall. Unified or XP processes tend to fit the way developers work IMHO.
Anony Coward
Sunday, November 21, 2004
 
 
If reality is taken as the ruling context, the standards can be useful guidelines.  If the standards are taken as a contextless set of absolute rules to be applied without exception or adaptation to the situation, nothing will work.

The overwhelming majority of management I have encountered since I started working for a living (early 1960's) expect the latest thingy (a highly technical term) to be the magic bullet that solves all their past problems.  You are to implement it without resources, effort, training, authority, or testing.  If it doesn't work, its your fault.  The Pointy Haired Bosses don't understand what standards are and can do nor do they want to.  They only want them implemented in the worst way so they can't be blamed for failure.  That's generally exactly what they get.  I have been there and experience that far more than I care to talk about.

There are some good and useful ideas embedded in both standards but it takes deep understanding of the real world context to implement them so they give the results the standards pushers say they will.  Results are not automatic.  Nothing good will happen without the effective application of thought, understanding, knowledge, logic, skill and effort.
Lionell Griffith Send private email
Sunday, November 21, 2004
 
 
Crap and more crap. What is good about them is a good question.
son of parnas
Sunday, November 21, 2004
 
 
CMM would be better than ISO 9000.

Most managers are not very good at managing thinkers. As a result, the pieces of paper used to clarify what is going to be done tend to get far more importance than the result of the process. To compound that, many developers abandon the documentation about mid way in the development. Once the thought process is pretty much done, the rest is reducing the thoughts to code. Compelling the developer to keep up with the paperwork is the way one tells the developer that appearing to be productive is more important than being productive. That is when the process Methodology gets in the way of work.

If the pretty little pieces of paper were going to be used to help figure out what went wrong and therefore how to NOT do it again, then it would be worth it. Instead, errors get repeated over and over, like the scene in Monty Python and the Holy Grail about the castle they built in the swamp. How many of them fell down into the swamp? Our process isn't really dead yet, its only a flesh wound...
Peter
Sunday, November 21, 2004
 
 
They're all crap.
Mr Jack
Monday, November 22, 2004
 
 
Personally good standard can help a shop and no or bad standards will make things worse.  Having something in place for handing the peices of to go to test then production or to be integrated makes that process work the same everytime but you only want to have the programmer doing exactly what he needs to for the next guy in the line.  Make it to paper intensive and you will get alot of copy and past or the same document with only those peices changed that are absolutly needed for it to work correctly.  This would be a good hint of what you should consider changing to.
  I am also in favor of somesort of design and coding standards.  You dont want then real specific as this limits the programmer and you will usually not get the best solution to the problem.  It needs to be tailored to what you are working on.  Is you shop working on a live system where modifieng and remodifieng the same code in rapid order and going almost imediatly to production.  In these situations a good english requirements doc that is kept up to date that tells in plain english what programs are used in the process and what each is doing takes alot of guess work out of weather or not something is working correctly or a situation is accounted for without wasting the programmers time as a Business Analyst type person can read and maintain that.  Also given the complexity of the program and process somesort of design even if its a simple dataflow or higher level process flow to me gives you a better result in the end.  Your good programmers will already be doing somesort of design even if its in their heads for the processes and programs they are working on the mediocer and bad ones are probably not.  By making even a base reqirement that can be chaecked forces those that normally wouldn't to at least think ahead a little about how they are going to get from point A to the desired end result.  An example of why this is good is the process I am working on now.  It takes 1 input file producess 5 reports and 2 output files from this using several database tables for mapping and verifications.  It was written with no plan and runs all over the place often doing the same thing multiple times for no other reason than they were not sure they had done it yet in the book of code it took for them to do it, then lets talk about the 25 internal work disk files it uses.  Does it work yes.  Is it effecient or good code or design Hell no.  Guess thats why I am here on contract trying to figure out exactly what it does as there is no requirements doc here either so no one is sure exactly everyhting its supposed to be doing so I can rewrite it to hopefully be two or three times faster.  This program would never have become if a little forethought was taken to what really needed to be done and how they planned to get there.
Douglas Send private email
Monday, November 22, 2004
 
 
Douglas:

Give us a break, and put in a <CR> every so often.  I think that would be a good standard.  Otherwise, it is very hard to read your stuff.

OP: Standards are nice, if they are good.  The problem with Software Engineering these days is that we are *still* evolving our standards.  Thus, if you mandate standards too early, you can force development into non-productive work.

I think most SW developer's experience is either no standards, or standards that lead to more work with no benefit to the programmer or the product.

Note that neither CMM nor IS0-9000 have much to say about *productivity*.  The *assumption* is that good standards and good quality will lead to *higher* productivity -- but that is certainly not proven yet.

On the other hand, if you don't draw a line in the sand by setting a standard, you have no way to measure how close or far you are.  It's just necessary to have some way of moving the line, if you find you've drawn it in the wrong place.  This is the part that tends to be implemented poorly if at all -- how do you change your standard when it needs it?  Who decides?
AllanL5
Monday, November 22, 2004
 
 
I worked with ISO9000 and it is only unnecessary bureaucracy. I'm guessing CMM is the same thing.

A good software process that delivers quality products and services should not be bureacratic.
Dino
Monday, November 22, 2004
 
 
I worked with ISO9000 and it was not overly bureaucratic. It depends how you implement it.

As an aside, it's certainly true that programmers hate doing 'busy' work. For many programmers I know 'busy' work includes:

*Documenting your code
*Testing your code
*Ensuring your code is easy to read
*Ensuring your code follows coding guidelines

Many programmers, myself included, need a little persuasion to ensure that these essential items are in fact done.
David Clayworth
Monday, November 22, 2004
 
 
David,

*Documenting your code
*Testing your code
*Ensuring your code is easy to read
*Ensuring your code follows coding guidelines

Well, your last one can be handled by simple formatting tools.  The second one can be *mostly* handled by automated testing.

Your first and third ones are purely subjective as to what is "easy" or "good enough".
KC Send private email
Monday, November 22, 2004
 
 
David,

ISO9000 does not require you to

*Documenting your code
*Testing your code
*Ensuring your code is easy to read
*Ensuring your code follows coding guidelines

but to make the manufacturing process repeatable and traceable.

Software development can be made traceable, but making it repeatable is, IMO, a doubtful concept.
Dino
Monday, November 22, 2004
 
 
Standards can be great, but everywhere I have worked with standards and without tends to always reinvent the process on each project.
m
Tuesday, November 23, 2004
 
 
One of the biggest criticisms of CMM is that its focus is "repeatability." This goes back to its roots as a method for DoD to rate contractors. Repeatability = Predictability. However, it says nothing about quality, efficiency, etc. You can be CMM Level 5 if you consistently produce garbage and you are improving the consistency of your garbage.


"Software" is called that because it is "soft" and pliable. It can take many forms, which it what makes it so useful. We only need to write a piece of software once (if it works well); we duplicate software to allow as many people to use it over and over again as much as they need it. Every piece of software that is written should be different from every other piece of software, otherwise there is no value to is. So standards that try to make all software exactly the same is misplaced.

However, software is usually part of a system, so there have to be some rules to produce order out of chaos. Also, we want to be able to reuse code where we can, since writing the same code over and over is a waste of resources.

I once read someone talking about metrics and measuring programmer productivity. They said that using "Source Lines Of Code" (SLOC) is like judging a woodworkers productivity by measuring the amount of sawdust on the floor. Imagine what happens when the woodworker realizes he's paid by the pound of sawdust he produces, and not by the finished articles produced.

A common complaint among users, maintenance programmers and operations staff is that the original developers were so worried about cranking out code to a deadline, that the results are a product with astronomical costs and risks after delivery. Even during development, skimping on error handling and other techniques to help with robustness, testability and the ability to debug are a constant drain on productivity.

Together these hold the key to effective standards. (1) Know what it is you hope to improve with standards. (2) Make sure that your standard actually contributes to the objective. (3) Use standards to make the people and parts work together as necessary, not to describe the final product features and uses. (4) Develop standards that contribute to global optimizaton, and make sure that people don't take short-sighted short-cuts.

Finally, any standard should explain why it exists. If no value is given, there is no reason to follow the standard when push comes to shove. Also, you can determine when the standard should be revised or abandoned, or when an exemption should be granted. There should always be an exception process; its the nature of software to develop unique solutions.
Dave Lathrop Send private email
Wednesday, November 24, 2004
 
 
I've said this before on this forum, so apologies for sounding like a broken record :-) 

Get your hands on a copy of Crystal Clear if you can, and read the section on CMM. It's only a few pages long, but I'd still rate it as the best stuff I've read on the applicability (or otherwise) of CMM etc, especially to small teams.  As for the rest of the book, you might find that it helps to answer your questions about programmers attitudes to standards - especially about designing processes that people will actually use.

Again, at the risk of sounding like a broken record, a one page Crystal Clear intro, with links, is here: http://www.agilekiwi.com/crystal_clear.htm
John Rusk Send private email
Wednesday, November 24, 2004
 
 
Thanks to everyone for your cosidered replies.  Not being a programmer, they certainly give me a little insight into how you feel.  My own background is in Sports Management and I've seen the paper storm when we implemented ISO 9002 and also seen the ingenious steps taken to avoid the extra work it created.  Whether it improved quality is debatable but it certainly helped us fight of competitors when we went for the big contract.

Thanks again.
John O'Neil Send private email
Wednesday, November 24, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz