You can tell we might be nearing a
change point by trying to count all the frantic voices beseeching
software developers. “Write
for me. Write for my platform. Use
my tools,” they cry.
This might be amusing or annoying. If you’re a software developer, betting your company and
your future every time you make a development choice, they are more
likely to be confusing, even frightening.
The pressure goes up as the din increases.
Lately it’s been getting very noisy.
There are always lots of choices. Developers are constantly being reminded that their skill
sets have half-lives and that they need to refresh themselves by
learning new languages, new platforms, and new applications. That is what moves developers from investing more in C or C++
and moving on to learn about Java and, more recently, XML.
What is clear is that none but the
very largest software companies can afford to develop in every
environment and for every platform.
(Even if they could, they’d be even less likely to be able to
market to such a broad potential customer set.)
Resources are finite, priorities must be assigned.
These priorities are based partly on economic bets as to where
future business lies, but other issues count, including:
-
what you’re already supporting
– customers expect continuity and they expect it for almost
forever.
-
the development organization’s
skill sets – it’s hard to change them quickly and developers,
like most humans, tend to rely most on what they know best.
-
but some developers are drawn to
new technologies as a way to demonstrate their intelligence and
ability to learn new skills.
Corporations, for instance, have been amazed to discover
how many developers with unknown (and self-learned) Linux skills
they have lurking in their cubicles.
-
what your current (and future)
partners are doing. It’s
hard to be an important partner if you’re not supporting their
major strategies. That’s,
in fact, how analysts think of vendors (and customers, for that
matter). They’re in
families or tribes, based on not just who they SAY they partner
with but what they actually do.
Saying Java or Linux is easy.
Spending millions of dollars to retrain or hire developers
with the right skills and more millions to retool your software
assets is an altogether different story.
The huge number of choices isn’t
just a commercial developers’ problem.
Corporate IT has to deal with it, too.
First, they have all those existing applications and systems
which have amazingly persistent habits.
Even if you’re a purist and insist on continually upgrading
to modern systems and software, each of us can regale our colleagues
with tales of others who still run ancient applications that no one is
willing to try to redo. Why
else were COBOL programmers in such demand during the Y2K frenzy?
Our favorite examples have to do with big companies who think
VSAM is a data base.
Then Corporate IT must deal with
developing new applications, selecting new platforms, and keeping
everything somehow fastened together.
One choice is to keep using the
skills you have (whatever they may be) and employ tricks to hook
things together, whether they’re heterogeneous existing systems and
applications, new systems and existing ones, or internal systems with
web sites and partners. One
of these tricks involves wrappering existing code so that it
masquerades in modern dress. VelociGen,
Inc., for example, a software developer in San Diego, CA and an IBM
partner for WebSphere and Web Services, reports that their customers
use their Wrap it/Link it/Run it approach for all of these situations. Wrappered code appears to be (and functions like)
XML/SOAP/WSDL applications (and can be registered in UDDI registries).
Some ISVs also like this concept to
get them quickly into a Web Services market approach, while they (at
least theoretically) take a parallel, but much longer road, to
decomposing and rewriting their applications – or assembling whole
new ones, optimized for the Web.
This is convenient and fast and we
don’t want to discourage it as an approach, but we’d note that
similar ideas in the past have led both ISVs and IT managers to then
go on to other, more pressing matters and to leave their wrappered
applications behind, perhaps forever.
Some of them are probably in exactly the right place.
There’s no point in spending precious development resources
on thinly used applications or ones which are scheduled to ultimately
be replaced.
On the other hand (there’s always
another hand), if the application is going to be important, widely
using, and very durable, you might want to consider another approach.
At the very least, some thought should be given to scalability,
performance, user interface, and other considerations, all of which
may change greatly as applications move to the web.
Last week I was waiting for my
moment of fame, appearing on John Dvorak’s Silicon Spin to talk
about the Office XP announcement, and I spent an hour in a
bar-restaurant near the video studio that splices me into CNET’s
west coast studio from Philadelphia.
To my amusement the long table next to the cozy corner in the
window where I was sitting, editing a presentation was occupied by
half a dozen noisy developers. They
appeared (from my eavesdropping) to be attending a technical class in
Philadelphia – and commented to my husband and me about the downtown
scene. But mainly they
were commenting on the development environments they used.
How much they loved some of them and hated others.
And that’s the other part – how passionate people can be
about their attachment to the tools they use.
Tool vendors can win (or loose) fortunes by attracting such
passions. I wanted to ask
them more questions, but it was more fun to watch them at play, so
involved in what they do as part of whom they are that which language
they use is an intimate part of their personality.
I went off to my interview renewed.
All is right in the world as long as the craftsman cares that
much about his tools what he builds will be well built, executed with
love and care.
