STANDARD, CRITERION, GAUGE, YARDSTICK, TOUCHSTONE-- A means of determining what a thing should be. Standard applies to any definite rule, principle, or measure established by authority. Criterion may apply to anything used as a test of quality whether formulated as a rule or principle or not. Gauge applies to a means of testing a particular dimension or figuratively as a particular quality or aspect. Yardstick is an informal substitute for Criterion that suggests quantity more often than quality. Touchstone suggests a simple test of the authenticity or value of something intangible.
-- Merriam Webster's College Dictionary, 10th Edition, 1993
A continuing story about life without standards...
Changing jobs is always an interesting proposition. Because people get so accustomed to the environments in which they work, change can be difficult. Now try moving from an established, process driven environment to a startup. Instead of detailed processes, you're more likely to find "shoot-from-the-hip" management styles and a "get the product out at any cost" mentality. And in that rush of building the latest, greatest technology that everyone wants and everyone needs and everyone else is trying to build "so we better get ours out there first" -- we sometimes push standards to the bottom of the priority list. In the long run, the product, and the company, will most likely suffer.
So what's the big deal about working without standards? We're not talking about anything that can seriously impede our development progress, like ethics (or personal hygiene). A lone engineer can create a product without having to follow some complicated methodology as defined by an organization with a funny name, right? A team of engineers can also probably survive. It's been done before, it can be done again. Granted, it may take longer than projects following a defined process. And there's not much chance of reuse of process or components if there is no clear documentation. But hey -- you got the product out the door, right?
From a technical standpoint, how much do any of us think about standards when we work? The fact is, we apply standards to our every day lives that we may not even consider standards. For example, you could not read this article if we didn't have a standard written language. Before you jump to the conclusion that this is a silly comparison, think about how written language came about. People spoke the language before they learned to write it. Can you get along in life without reading? Sure. But how far can you really get in life? Our ancestors were relatively smart people. But once they could write, efficiencies soared. Creativity grew by leaps and bounds. There was that slightly odd period called the Dark Ages, but otherwise things have progressed quite nicely.
Another fine example of standardization is the automobile industry. Could you image what would have happened to user acceptance if each and every auto manufacturer had decided to support their own type of liquid fuel? There would need to be different fuel stations for each brand of car on the road. Maybe you'd see some consolidation as a few major manufacturers worked together, but it still would be a mess out on the road. There would have been fewer choices for consumers, as smaller manufacturers fought to gain market share. Rural customers would have even more limited choices -- or no choice at all if the only regional manufacturer decided that it was not cost effective to build a station in that area. And here's a pleasant thought -- traveling across the Nevada desert and not being able to find a fuel station for your Yugo. Yikes.
Experiments in Project Management
So we find ourselves back at the example of the new job, trying to convince your new manager that some kind of development methodology makes sense in the long run. For a lesson in standards, we need only go as far as your team Project Manager. Depending on where you work, this job function has been known to "manage" a wide assortment of tasks. Organizations such as the Project Management Institute (PMI) and methods such as Critical Path and Kepner-Tregoe have gained wide acceptance due to the multitude of conflicting and confusing standards being implemented across companies and industries in the name of Project Management. A unified methodology allows organizations to work together on large projects by offering a common framework from which to build.
With today's immensely complex, sophisticated software and hardware, "only demanding attention to detail and insistence on routines and standards make engineering design cost effective," comments Lowell W. Steele in his book "Managing Technology: The Strategic View" (McGraw Hill, 1989).
"We are observing that phenomenon in software engineering -- namely, the development of rules, concepts, and techniques for design, procedures for quality control, and measurements for writing software. Software programmers have been operating with few constraints on their personal idiosyncrasies and sense of elegance. The result has been vast duplication of effort and the creation of programs that cannot be maintained or modified, except by their creator, without a major investment in unscrambling them."
Look at the shifts in object-oriented software development over the past decade. The streamlining of modeling techniques, most notably the blending of notations by Booch, Jacobson, and Rumbaugh into the Unified Modeling Language (UML), lends weight to the argument that people must learn how to standardize their software development practices through the use of repeatable modules and extensible packages. Tools must be rigid in their capabilities, but flexible in their application.
Because software quality has been poor in the past, several different companies have started developing their own standards to help with product development -- everything from ISO 9000 to SEI's CMM. Companies take on these initiatives without a clear understanding of how much time and effort these projects will take to fully implement, much less reap the benefits that these standards can provide. Many times these efforts fall short because there isn't a clear "captain of the ship"--without an evangelist for these standards, most of these implementations fail. Most of us have lived through this time and time again.
In more recent years software standards have fragmented into several different aspects of software development: Language, Coding, Analysis and Design, Quality Assurance, Product Life Cycle and Configuration Management are just some of the standards categories.
Language standards such as ANSI C have proliferated as code became more readily portable across compilers that followed the standard. This has not always been the case with Language standards. For example, ANSI C++ took too long to standardize and several compiler vendors extended and fragmented the language. As a result, C++ has been a language with its share of portability problems. (http://www.research.att.com/~bs/iso_release.html)
Each language has an inherent coding standard, defined through its unique grammar. Languages, by and large, allow for programmers to make decisions on names of elements of the language. For this reason, coding standards are typically created for a development team so that the team can easily read each engineers code. There are several well-documented coding standards out on the web that are tailored for memory management, performance, readability, or portability. (http://www.macadamian.com/column/column_coding.html)
As languages progressed and evolved inside the Analysis and Design world, some structured and object-oriented standards developed. In the late 1990s, the object-oriented community adopted the UML as a standard object-oriented Analysis and Design language. (http://www.omg.org/uml) Other standards have been developed to increase the quality and reliability of software. These standards include quality assurance, risk management, project management, configuration management, product lifecycle management, and several others. Some of the most prolific standards bodies have been ANSI, SEI, and ISO. Each standards body has focused on different aspects of software development, with some overlap. There are literally hundreds of standards that have been created over the years.
So how do you know what is best for your organization? You need to find the standard that fits your domain and the culture of your development team. For example, if your product is mission critical and has real-time constraints, you probably would look at the ISO standards for real-time systems. For other projects, standards are necessary due to industry constraints. For example, if you are creating a medical device with embedded software, you must follow the FDA Software Development standards. You need to make sure that the standards are followed for all of the countries into which your product will be sold. With all of that said, don't over do it. Make sure you pick the standards to follow that increase productivity of your organization ( and don't choose a standard just to have a standard.
The Dawn of Configuration Management
Configuration Management is in a unique position because these systems are typically the glue between Engineering and the rest of the product development organization. The product cannot move unless the CM team coordinates with the Build and Release team and manufacturing. Since most groups depend on the CM team for information and guidance, they are the natural leaders to help enforce process across the teams. In fact, most configuration management tools have some kind of mechanism that allows for automation of software development processes. In ClearCase, these mechanisms are called Triggers. Within most organizations, it is common that configuration management teams are handling the defect and enhancement tools, as well. These tools are designed for customized workflow and process management.
Most configuration management systems allow for the use of meta data with source code control. The meta data concept is an important tool that configuration managers can use to help enforce process and standards. With each version of the file, additional information can be attached to the version. This provides an opportunity to attach several different types of data to the file including the name of the person that changed the file, a reference to a test case, defect, requirement, and so forth. The possibilities are endless. Not only is meta data available within these configuration management systems, but most defect tracking systems allow for additional information per record in the database. Both systems are easily tied together using these techniques.
Meta data allows for the collection of additional information that a standard may require, however most standards have some kind of process requirements. The process must be followed and documented. This is where event driven add-ins or triggers can come in handy. Let's say that you want all source code to adhere to a coding standard. There are programs out there, such as Lint, that can check your source code for certain standards. You can register a "trigger" to run Lint before it allows a check-in. Other triggers can send notification to a group of code reviewers when code has been checked-in so they can review the code before allowing it to be included in a build. The event driven add-in technique can be found in most defect tracking tools, as well.
There are some unwritten rules that you need to be aware of. Whenever possible, DO NOT get in the way of development. If your "triggers" are slow and cumbersome, software developers will complain, and, as is their nature, most will do everything they can to subvert your unwieldy process. Ensure that your process improvement efforts focus on what is most important, and make sure performance is at the top of your list. The faster the better.
One technique to making "triggers" faster is to evaluate the purpose of the trigger. If the trigger is used to disallow an operation from occurring, it should be in the pre-trigger category (it will be run before the operation is executed). These triggers need to be fast. Nothing drives a developer crazier than waiting to check-in or check-out code from a version control system. Another technique is to run all other triggers in the post-operation mode, and in the background whenever possible. This will allow the engineers to get back to work again much quicker than sitting and waiting for all of the triggers to finish.
One of the biggest mistakes with "trigger" development is the interactive trigger. If you need to get information from an engineer, work with the source code management system and allow for environment variables or other mechanisms that can be used to apply the same information to all files for a given operation. Nothing makes a developer more insane than having to answer the same question again and again for the hundred or so files that they just checked into the source code management system.
A managers' dream is to start on a project at the beginning of the lifecycle, rolling out process and procedure at the inception phase of development. However, this is rarely the case. Whether you're a consultant hired to resurrect a twice "frozen" and now "critical" project that had been shelved and re-shelved due to the fluctuations of funding priorities across your organization, or you are the victim of a rapid development initiative that hopes to break the time-to-market "sound barrier" of the software development cycle ( Configuration Management can become a powerful asset to increasing communication, productivity, and quality through process automation and integration of the tools that most engineering groups use today. At any stage, implementing some kind of CM solution will organize your development efforts, and by helping your team prioritize and manage the development lifecycle -- you are more apt to meet your customer's needs.
Changing jobs or starting on a new project is tough enough--working without tools and directives that guide you through the development process is not something you need to add to your troubles. While a narrow focus on process and standards can stifle creativity and add to bureaucracy, a lack of focus and development without guiding principles can also derail a project. A happy medium must be found. A wise man once said, "Standards are rules to live by, not rules to die by." Interpretation -- flexibility is the key. Configuration Management can add structure and direction to your development efforts while allowing flexibility for change.
Darren Pulsipher is a Configuration Management Architect with Cadence Design Systems (http://www.cadence.com) in San Jose, California. With writing partner Christian Buckley, Darren recently published his first book, Secrets of the Change Agent. He can be reached at darrenp@cadence.com.
Christian Buckley is a Principal of Red Hill Partners, a technology consortium and content provider. He is also co-founder of the East Bay I.T. Group, the San Francisco East Bay's premier technology forum. Christian writes on numerous business and technology topics, and has been writing for Rational since 1998. With writing partner Darren Pulsipher, Christian recently published his first book, Secrets of the Change Agent. He can be reached at buckley@redhillpartners.com.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
