ISO vs CMM

As mentioned earlier... people quoting standards does NOT imply people/companies FOLLOWING standards.

There was a company here in the Northeast US who mandated different color binders for material that confirmed to ISO standards and a different color binder for all documentation which did not follow the standards.

If an audit was scheduled, all non-conforming binders were removed from the building. If an unscheduled audit occured [or a customer visit] the binders were removed from sight. There was even an overhead page that was coded to mean "Hide the D*&mn Evidence NOW!"...


While this situation MAY have been extreme, it is VERY simular to practices at many companies.

Quote:

---

Originally Posted by TheCPUWizard

As mentioned earlier... people quoting standards does NOT imply people/companies FOLLOWING standards.
[...]

---

Nice... :)

A question: in your opinion, this is good or not for an individual programmer?
I mean, in the product development process, by skipping some "annoying tasks" required by the standard, e.g. writing some documents, a programmer can gain more time to spend writing code...

Quote:

---

A question: in your opinion, is skipping some "annoying tasks" required by the standard, e.g. writing some documents, a programmer can gain more time to spend writing code...good or not for an individual programmer?

---

A LOUD and resounding NO!!!!!!

When you are an individual programmer [or are involved in a small team] the advantage you have is that YOU get to set the standard ;)

If you want to succeed you pick a set of "rules","concentions", and "preceedures" and stick to them. And there are major benifits to doing so.

If you adopt the "fast and loose" "standard", you know that you will produce lots of code, which is likely to have bugs, not be overly re-usable, etc. Onb the other hand, you will produce it fast.

If you follow a stronger set of "standards" or "guidlines" CONSISTANTLY, you will really get to know what to expect from your code. This allows you to plan much more effectively, and will improve experiences with your customers.

When in many corporate environments, the biggest problem I see the the Dilbert "Pointy Hired Boss" effect. A manager making decisions about which standards to follow [or break, or ignore] without having a true understanding of their impact on the development process.


The two places that not having a set of standards cause problems are:

1) You do not establish consistancy and good habits. This can cause problems if you are a solo programmer and end up working with larger teams in the future. The "does not play well with others" syndrome.

2) You do not know what to expect from the code your are producing. Say you typically follow a set of moderate procedures. You have learned that a given task will typially take 3 weeks to design, 1 week to code, and 2 weeks to test [these are some good ballpark ratios [IMHO]. You decide to short-circuit your normal way of doing things and start coding after just one week of design. The coding tajkes two weeks and your firuge you are a week ahead of the game. Unfortunately testing revels some serious bugs and takes over a month to successfully pass!

Quote:

---

Originally Posted by TheCPUWizard

A LOUD and resounding NO!!!!!!

When you are an individual programmer [or are involved in a small team] the advantage you have is that YOU get to set the standard ;)

If you want to succeed you pick a set of "rules","concentions", and "preceedures" and stick to them. And there are major benifits to doing so.

If you adopt the "fast and loose" "standard", you know that you will produce lots of code, which is likely to have bugs, not be overly re-usable, etc. Onb the other hand, you will produce it fast.

If you follow a stronger set of "standards" or "guidlines" CONSISTANTLY, you will really get to know what to expect from your code. This allows you to plan much more effectively, and will improve experiences with your customers.

When in many corporate environments, the biggest problem I see the the Dilbert "Pointy Hired Boss" effect. A manager making decisions about which standards to follow [or break, or ignore] without having a true understanding of their impact on the development process.


The two places that not having a set of standards cause problems are:

1) You do not establish consistancy and good habits. This can cause problems if you are a solo programmer and end up working with larger teams in the future. The "does not play well with others" syndrome.

2) You do not know what to expect from the code your are producing. Say you typically follow a set of moderate procedures. You have learned that a given task will typially take 3 weeks to design, 1 week to code, and 2 weeks to test [these are some good ballpark ratios [IMHO]. You decide to short-circuit your normal way of doing things and start coding after just one week of design. The coding tajkes two weeks and your firuge you are a week ahead of the game. Unfortunately testing revels some serious bugs and takes over a month to successfully pass!

---

Of course, NOT. That is also my opinion.
However, 3 weeks to design/1 week to code (IMHO) looks a little bit exaggerated ratio.

I remember a story, not sure it's really true, but quite nice.
I a Western Europe company, the managers decided that for a sofware product they don't need anymore programmers because they have already in the company good analysts and can acquire a good design tool that automatically generates code. So that they done.
After months of work all "looked" perfect.
But two days before deadline, when they generated the code and built... they had, ready to be delivered, a little cute two-gigabyte executable... :D

Quote:

---

Originally Posted by ovidiucucu

Of course, NOT. That is also my opinion.
However, 3 weeks to design/1 week to code (IMHO) looks a little bit exaggerated ratio.

---

It very much depends on the definition of design vs coding :D

Imagine that you need to write a computer program to perform a specific task. You need to define the task with sufficient detail that you could post it in any of the programming forums here on CodeGuru, and a [competent] programmer could implement it in the language in which that forum was based. If the specification is sufficiently detailed then all of the resultant programs should have identical functionallity.

Clearly all work done during this phase is design (The programming language has not even been defined). Now lets restrict the target programming environment a bit (again a design issue) and determine that we want to use .NET [the pros/cons of this are another topic!]. Here we are still language neutral [it could be managed C++, VB, C# or a third party compiler]. More design decisions need to be made regarding the portions of the CLR that will be used, how assemblies will be organized, which collection classes will be used for managing groups of data, etc. This is STILL design work.

Only when we get down to translating these desicisons into the proper syntatical format for the target languae, are we actually coding. This is where the old definitions of "analyst" being used to mean the one who does the design, and "programmer" being used to mean the one who does the "coding" completely fall apart.

Clearly during the implementation there will be choices as trivial as deciding if a certain loop will be a while" [conditional at top of loop, with possibly 0 iexectuions of the loop] or "do" [conditional at bottom of loop, with at least 1 exeuction of the loop]. This is a design decision. The coding issues relate to the proper use of parenthesis, semicolons, braces and the like.

Quote:

---

Originally Posted by TheCPUWizard

[...]
Clearly during the implementation there will be choices as trivial as deciding if a certain loop will be a while" [conditional at top of loop, with possibly 0 iexectuions of the loop] or "do" [conditional at bottom of loop, with at least 1 exeuction of the loop]. This is a design decision.
[...]

---

Aha...
Do we need flow diagrams (as a design issue) to show programmers what loops to use for implementing functions?
Are you still programming in Cobol, Fortran...?

Quote:

---

Do we need flow diagrams (as a design issue) to show programmers what loops to use for implementing functions?

---

In general NO. Can we say that these types of diagrams are never needed? I think the answer to this is also no.

MY point however was quite different. The old shool of thought divided design and implementation into analysts and programmers. This division had many implications. Most modern shops freely combine design and implementation tasks and have them performed by a single person. The assignment of tasks to specific individuals or groups is more often related to the scope or placement in the hierarchy. This is similar to the structre of many armed forces. Division between stratigic and taactical issues.

Want I wanted to ifocus on is that if you are sitting in front of a computer and tring to decide what type of loop, container, or other technique to use, you are involved in design. When you make your choice and have to figure out what the "magic incantations" are to do this within a specific environment [language, compiler, library, etc], then you are programming.

Spend a day in front of the computer. being aware of what you are doing [so much of this is automatic to people with any serious experience]. Are you trying to decide what you want to do, or are you specifically thinking of "how to explain that to the computer". For most, it becomes quickly obvious that Programming/Coding is a very very small part of the time spent. The ramification are startling...

Assume I spend one day talking with people about what a program should do, followed by three days building the software, followed by day of testing. The thought could be:

Code:

---

Design            20%
Programming  60%
Testing          20%

---

But if we review are time at the keyboard more closely, we find that 25% of each day was actually spend on programming in the context outlined above, 50% in desgin related thoughts and actions and 25% is testing [which can take many forms both tangible and intangible) whave:

Code:

---

Design            1 + 0.50*3 = 2.5  days
Programming  0.25*3 = 0.75 days
Testing          1+0.25*3 = 1.75 days

---

The programming is a mere 15% of the total time spend on the project!!!!!

There are over three days of design work per day of programming work!

There are over two days of testing work per day of programming work!

The numbers become even more extreme when one factors in the time typically spend on a project at the very beginning of the cycle and after the "first version" is deemed to be "working".

Quote:

---

Are you still programming in Cobol, Fortran...?

---

Occasionally. There are a lot of legacy systems out there. Interestingly enough I did a Cobol.NET contract earlier this year.

Quote:

---

Originally Posted by TheCPUWizard

Occasionally. There are a lot of legacy systems out there. Interestingly enough I did a Cobol.NET contract earlier this year.

---

Cobol.NET? Quite interesting. Serious.
Just I'm courious: there is also an Assembly.NET? Should be even more interesting.

Cobol .NET is quite real [Micro Focus has a complete range of current Cobol products!]. It serves two main purposes:

1) Bringing legacy code into new environments and platforms

2) Allowing Cobol programmers to be productive without having to go through a large transition.

While I tend to have some serious issues with the second purpose, I do concede some validity [I have had direct discussions with some of the senior people at MicroFocus on this issue].

--------------------

You can program directly in MSIL [which is the "assembler" level of .NET], howver an x86 style assembler would be quite counter productive [since the output of it would have to be MSIL which is a "higher" level language].

You made me nostalgic...
Just I have remembered the good days of highschool,...learning Cobol 74... :)

Quote:

---

Originally Posted by Hokutata

You made me nostalgic...
Just I have remembered the good days of highschool,...learning Cobol 74... :)

---

Me too... :D

I think, since Y2K area has been closed, the interest for Cobol 74 is also closed. :D

Quote:

---

Originally Posted by Mick

ISO9000 + Six Sigma

---

lol, isnt six sigma a manufacturing quality control control thing?

Quote:

---

Originally Posted by Cerf

lol, isnt six sigma a manufacturing quality control control thing?

---

*lol* it's 2004. You need to catch up with the times. Try some research...Google is a good place to start.

Quote:

---

Originally Posted by Cerf

lol, isnt six sigma a manufacturing quality control control thing?

---

If I am not wrong, it first started from manufacturing. Since then it has been brought over to software. See the following link.
http://www.softwaresixsigma.com/