Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: "John Jacobson" <jake@j[nospam]snewsreader.com>
- Date: Sun, 5 Feb 2006 23:27:01 -0600
David Clegg <dclegg@xxxxxxxxx> wrote in message
<xn0ei5nj01bhp7001@xxxxxxxxxxxxxxxxxxxxxx>
The system was also lacking
much of the key functionality of the Delphi version, which was
overlooked when the system was ported.
In other words, they replaced a fragile system with crap. That tends to be the
way almost all rewrites go in the real world. In the business world where most
software is produced, it is nearly inevitable that this will happen, in fact it
is very difficult perhaps even impossible for the first version of a re-write
to be as good as what it is replacing, no matter how good the programmers are,
and no matter how productive the IDE, and no matter how good the manager is.
The reason is very simple. Over time an application comes to be the sole
embodiment, the sole manifestation, of the knowledge, the business rules, that
satisfy the end user. In addition, iterative repairs and adaptation have slowly
perfected the application relative to the end users' needs, much like the
process of natural selection perfects a species relative to a given
environment. This knowledge, these business rules, almost never exist anywhere
else, except perhaps in the heads of the original programmers and project
managers who are usually thrown out in favor of the team that will rewrite the
application. Thus, even if the new team is a bunch of superstar coders on a par
with Anders Heljsberg, they are not going to know the most important pieces of
knowledge required to produce an application that is as good as they one they
are replacing (unless they slavishly reproduce the existing code's
functionality verbatim, without knowing or asking why it does what it does, in
which case they are simply acting like the modern equivalent of monks carefully
copying a sacred text).
I've been on several projects that looked from the software developers' side to
be successful. It is possible for software developers to actually produce
something useful, in an efficient manner, judging from those. However, I have
frequently seen software rewrites from the consumers' point of view, and I have
never seen the first one or two versions of a rewrite looking better to the end
users than the software it was replacing. Over and over again I have seen cases
where working software was replaced with even worse crap. Out there in the real
world the average person cringes when they are told by their boss that the
software they use for their job is going to be replaced by a new system,
because the know from past experience that this means that all the careful
honing of the prior software is now going to be lost, and they have to start
that process all over again, with a system that will almost certainly not do
what they need it to do for a while.
Now I know that Borland would like us all to believe that this problem can be
solved with proper requirements gathering tools, but I think such tools could
at best only help slightly ameliorate the problem. The source of the problem is
that the knowledge which is embedded in the design and structure of the
software and in programmers' heads is lost when the programmers or the software
are thrown out; and recreating an embodiment of that knowledge takes a lot of
time and resources, even if you don't lose the knowledge itself.
There is a very severe problem in I.T. and that is that companies aren't
usually intelligent enough to know how important it is to retain their software
developers, project managers and software over the long haul. They contract the
development of the software to consultants, off shore programming shops, or
short-term employees and then have all the knowledge and human capital
associated with the product disappear when the consultants walk out the door,
or the off shore contract is ended, or the employee takes off because of
uninspiring treatment or compensation. All they're left with is a piece of
software that nobody knows anything about, which therefore fossilizes in short
order into the scapegoat that I mentioned in another post.
Warning: if you see a software project where scads of C#, VB.NET or Java
contractors or consultants are being brought in, you are probably witnessing
the birth of a future scapegoat. Once the contractors are gone, the knowledge
will be gone with them.
--
***Free Your Mind***
Posted with JSNewsreader Preview 1.0.4.2047
.
- Follow-Ups:
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Jim Rowell
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Brion L. Webster
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: David Clegg
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Scout
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- References:
- My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Randy Magruder
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Danijel Tkalcec [RTC]
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: Randy Magruder
- Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- From: David Clegg
- My rant about the "throw out delphi and re-write it in C#" crowd.
- Prev by Date: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Next by Date: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Previous by thread: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Next by thread: Re: My rant about the "throw out delphi and re-write it in C#" crowd.
- Index(es):
Relevant Pages
|
