Friday, November 19, 2004

Working towards Standards

I keep experiencing these differences of standards, I come to a job, I want to either work with the already existing standards, or to help work to come up with a new one.

It's a political/technical battle all rolled up into one.

There are those workers, who are so busy that don't have time to discuss or work on standards, those who want standards but not sure what kind, those who have a specific standard set they are used to.

I am not a proponent of a specific standard, as long as it's mutually easy to use/remember and helps prevent mistakes being made as a team or individual.

That's goal isn't it, we learn from the mistakes of the past, so like the Boy/Girl Scouts we prepare, prepare and prepare to make sure those mistakes never repeat.

All of this is about the mistake making, learning process.

From Project Mgmt to Coding Standards.

I keep remembering Hal Helm's article on Methodology in CFDJ. On one hand it is important to have a documented and easy to understand standard/methodology, but he is distasteful of there being different ones out there, that aren't a popular/commonly used standard/methodology.

Maybe that's why I get so caught up in the Fusebox/Blackbox/Mach-II arguments. Not that they don't have vital things to be used or learned from, but I have no interest in pushing a certain methodology.

I think we need a fresh new approach to standards and methodologies, that instead of labeling a standard/methodology, but lists each element of good standards/methodologies, and let's everyone pick from the menu on the list, in their own unique priority.

That's the key, we're not all in the same coding environments, so we need to have an open standards approach, of including all ideas, and then each of us can freely pick what things are most important in our own situation.

What kind of key things are important to you, if you had a list of elements for an Open Standards System?

1 comment: