Context as the deciding factor in Technology Decisions
When we have a range of technology options available to us we have to
make a decision which meets a variety of criteria. Some of these are
clear and quantifiable, such as the costs of procurement, support,
deployment and development. Others are less tangible but receive as much
or more weight in decision-making, such as the aesthetic judgements on
programming languages, solution architecture and operating system. These
aesthetic considerations can be justified, but it's often difficult to
give an objective explanation of why we hold our professional
preferences, or indeed to check that our preferences are correct. The
answer lies in the context of the options.
The long-term value of a software system is our true measure. This
implies straightforward maintainance, extension and integration in
unforseen future scenarios. However in today's Business world, it also
means the ability to get up & running quickly - the time from idea
to interaction has to be minimised.
A fact of life in software is that the original team who design and
build the system will rarely be around when amendments are required in
years to come. The value of standard solutions is therefore paramount -
it must be possible for a new team to comprehend the system quickly in
order to take responsibility for the amendments.
There is one other constraint which has to be met by any solution - it
should be quite ordinary. For all the polish of a perfectly engineered
solution, it is the inherent simplicity of the underlying structure
which will be it's greatest asset in the long term. Clearly simplicity
in this sense usually requires a great deal of preparation in order to
provide the tools and framework which enables ordinary solutions to
perfectly meet the Business requirements.
This preparation is the context which we have to consider when selecting
the correct technology for a solution.
The context includes such high-profile subjects as Frameworks and
Operating Systems, as well as more items rarely considered when we are
in a creative, problem-solving frame of mind. What about deployment
facilities, longevity of support for the whizz-bang little component you
want to use, the ease of common things such as Database connectivity?
How many people are there who could be hired to extend your chosen
solution? If you have a highly componentised solution, how do you handle
component version requirements?
Big Contexts
Corporate Contexts
What Corporate standards exist? Vendor partnering, interaction with
distributed application management infrastructures, code availability
(rare!), platform restrictions (versions as well as identity).
Support Contexts
What support can the customer/user expect to be abke to access?
Deployment Contexts and Publication Costs
How easy is it to distribute/sell/upgrade/restrict usage of your product?
Development Contexts
There are some pretty Big Development Contexts out there - notably J2EE
and the .Net framework. These are Standardised, packaged contexts in
which a software solution can be created. They provide extensive
Standard Libraries, describe deployment infrastructure and packaging and
are specifically designed for extensibility.
Within these Big Contexts, and building upon them, we see
strongly-structured extensions and even alternatives utilising the
facilities provided by the context. In both Java and .Net we have
compilation-free integration, configurable at run-time, enabling any
tool to be 'dropped in' to the environment and used immediately.
Additionally, replacement of component versions has little or no
implications for other components as long as interfaces are maintained,
and in .Net there is core support for the co-existence of shared
libraries at various versions.
This leads to the creation of highly sophisticated components such as
the Spring framework, the Hibernate ORM framework, and the Apache
Jakarta and Commons projects. These components and projects depend for
their viability on two things - a standardised, complete development
environment and crucially - the expectation of the community that
packaging and deployment are not optional.
It is this outlook that leads to the grand-scale collaborative projects
implemented in Java. In developing 'packaged solution' expectations, we
automatically develop improved solutions components - from this are
lightweight application servers (picoContainer, Spring), ORM tools
(Hibernate), MVC frameworks (Struts), build systems (Ant, Maven) and so
on born.
In the face of this, where does C++ sit? Standardisation for C++ has
resulted in a perpendicular development of the language, to the extent
that Bjarne Stroustrup's 3 "C++ Language" books are of totally different
character. The standardisation of C++ has focussed closely on the craft
of writing code - and arguably has missed the point entirely. Can I
actually make stuff work better and sooner with ANSI C++ vs "Grey book"
C++? Does the STL actually improve my ability to solve Business
problems, and is it safe ot use in the wider envirinment where STL
Algorithms are completely obscure and esoteric to most programmers? I'd
say "no" every time.
|
