Sneak In New Technologies

Often, corporate imposed constraints in development techniques and tools do not allow you to DesignTheRightThing. Fear stagnates progress. Old legacy standard tools and processes are imposed on the developer "because they worked just fine in the past".

Fixed development processes resist change.

Management fears the unknown. New technologies presents risks to a well defined development process. This is especially true when management is not aware of, or does not understand, new techniques and tools that may aid the developer in getting the job done. Object Oriented Technology is often the subject of this fear. Others include new languages, libraries, CASE and analysis tools. They frighten the uninitiated into resisting their incorporation into the development effort.

Therefore:

Identify the constraints of your current development process and try to sneak new technologies in without breaking any rules.

These new technologies must have already been mastered by all developers who will be involved with the implementation in order for this Pattern to be successful. Introducing technologies that are new to the development team is reckless and risky.[added 30jan96 due to comments made below by RalphJohnson. --ToddCoram]

If the development process dictates that all software is to be written in the language C, and you want to develop using object oriented programming, then consider writing in an object oriented language that is interpreted by or compiled into C. For example, incrTcl is an object oriented extension to the Tcl scripting language. Tcl and incrTcl is written in C and callable by C. If you are allowed to use public domain libraries, then Tcl and incrTcl are just libraries that you link into your program. The object oriented incrTcl source is really just a data/script file.

If the develop process has tighter constraints (you are limited strictly to one particular programming language), then you can introduce new techniques. For example, if you are limited to using C, then you can introduce object oriented techniques and ideas. Encapsulation, polymorphism, dynamic binding and other ideas can be implemented to some degree in C.

Don't forget, X Windows, the NetworkExtensibleWindowSystem and other framework/toolkits were developed to work within the constraints of limited development facilities (C and Unix). Each managed to sneak in new technologies.

Finally, you must be careful not to antogonize Management. It is important that this Pattern doesn't sabotage project management. If a new technology is introduced [to the organisation], you must eventually convince management that it was a good idea. [ProofInPudding is the most straightforward in many ways]

-~ ToddCoram

--- I agree with Todd. Developers must remember though that sometimes management's fear of technology comes from developers' lack of communicating business advantage. Management is also very wary of devs that are looking to implement technology for technologies sake. There is a good case for getting developers some training on how to communicate business value and also management understanding how to communicate with developers. Remember... if you like something because it saves you time, they will like it because it saves them money! AndyBarratt

You state that "Management fears the unknown." While I am not trying to defend management, we need to understand that they are trying to manage risks (i.e. unexpected costs). The less they know about software development the more risks they see to changing how software is built. The developer should find ways of convincing management that the risks associated with a new technology are manageable. (Be honest. Don't pooh pooh them.) -- ShalomReich

Not only that, but new technologies are usually very disruptive. Introducing a new technology makes your efficiency go down until you master it. If one of your top performers learns Smalltalk, it will take six months to a year before he or she is back to the same efficiency level. A new technology has to be pretty good for it to be worth this pain! -- RalphJohnson

Other contributors: JoeWeaver et al.