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.