SEARCH 

About this Entry

This page contains a single entry by Adam Cusson published on March 25, 2008 7:20 PM.

Be a BSM Superhero, step 3.5 was the previous entry in this blog.

BSM...Innovation? Luxury? Must Have? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Syndicate




 

Thinking outside the box, staying within the standards

| Comments (1)
It is important for development organizations to stay informed on industry standards and to continually review them (new and old) for applicability to technology selection and problem resolution. Staying knowledgeable of standards is critical for selection of internal software components as well as providing outward interfaces and other benefits for both customers and engineers.

Recently I was reviewing some of the latest Java standards published over the last year to see if any standard resolutions had evolved to a development challenge on which my team was currently working. No dice. As it turns out, many other vendors had met and solved this very same challenge however no approach had been standardized. As a result, I’m now weighting the pros and cons of implementing a solution of our own that I’ve been noodling in my head.

But it got me to thinking even if a standard approach had been adopted, it does not mean that the standard solution would be the best development decision. Why? Because while standards generally do provide many benefits, they can also pose new problems which are what I classify as standards freeze.

If a standard is not open and flexible, it can stunt innovation and provide a speed-bump rather than an expressway to productivity. For example, standards freeze happens when an engineer or product manager finds he or she cannot add a new feature or function without breaking the adopted standard. It leaves the development team in the difficult position of either skipping the new feature or breaking the standard – both of which can have political consequences.

Thinking outside of the box does not always go hand in glove with standards adoption. Developing competitive differentiators many times means thinking outside of the box, and thus outside of the standards. It is crucial to take the time to research and ensure that the standards selected by a development organization or product allow for flexibility within the standards so that the product and/or organization can continue to grow without an expensive and time consuming overhaul.

The next time you feel yourself itching to download that open source project and use it because it will save you a few days, make sure you’re also thinking through the standards it was developed on and ensure that you can think outside of the box while staying within the standards.

-- Adam

0 TrackBacks

Listed below are links to blogs that reference this entry: Thinking outside the box, staying within the standards.

TrackBack URL for this entry: http://www.wearebsm.com/mt-tb.cgi/18

Visitor Comments

All good points, I would add that standards are only as good as the community adopts them -- and that community must include users/customers. Take for example the "standard" UL listed North American wall plug. It works only because both the consumer and the producer adopted it. On the other hand, there are a plethora of devices that use more amperage, or more voltage. These then require different plugs which, over time, were standardized but only after initials developers created "something".

So it is with software. When in early development/early adoption mode, regardless of the standards that may be suggested or that are languishing in some working group, it is my contention that innovation must be given first place. A standard after all, is really only a standard after it is adopted by a majority. Before that, it is just a suggestion.

--D.T.McKee

Leave a comment