Re: On Legacy Applications and Previous Work

Paul Robinson <PAUL@TDR.COM> writes:
> I wouldn't have thought much about real issues until my eyes were opened.
> I happened to purchase a copy of Edward Yourdon's "Death of the American
> Programmer." People may not agree with all of his ideas, but he made a
> couple of very important points that I do agree with. You may scoff at
> the points I am about to make, but would someone have believed someone,
> say, in 1971 saying that Japanese cars would almost kill the Auto
> Industry in 10 years? Two years later the oil crisis struck.


I agree with a lot of what Paul is saying, but there are one or two points
I'd like to make about it.


> Therefore, what we need - what is despirately needed in the real
> world - are better tools to perform maintenance on existing
> applications.


While I would never disagree with this statement, I think there is equal
fault with the management of those programmers. There are many tools
already out there that are sadly underused. I think this situation is
caused by 3 factors:


    1. Good tools are expensive. Management is loath to spend lots of dollars
          for tools unless they can be justified.


    2. Justification is hard to come by. Perhaps we (programmers) could do
          better at this, but I rather doubt it. *I* am certain my productivity
          and quality of work would improve with certain tools that I know are
          out there, but can I give concrete evidence to management? No. I
          know of no way to quantify the gains. Can I say the number of
          reported problems will decrease by x%? No. I can say I will spend
          less time on maintenance, but on what basis? My own opinion? Usually
          not good enough to justify spending tens of thousands of dollars.
          Sadly, there is little objective evidence on how any particular tool
          will improve productivity.


    3. Management is seldom interested in quality for its own sake. They are
          interested in saving money, and if improved quality will do that,
          great. But, as I have said, it is hard to quantify those savings.


> We can change this. And those who develop the tools to help todays
> programmers stay competitive can make money hand over fist.


Well, I don't know about that. There are certainly lots of software tool
vendors out there, but they aren't the most profitable software vendors,
are they? It seems that the reality, today, is that there is more money
to be made in selling end-user applications.


> To ensure that we are worth the high wages we are getting, we have
> to be much more productive. Most people who are programming are
> already overworked as it is. They do not need to work harder; what
> they need is to work smarter.


Before you can do that, you'll need to convince management that the tools
are worth it. And to do that, you'll have to be able to show them, with
objective evidence, that the tools are worth what they cost.


> - We need to increase the amount of code which is reused. From the
> programming courses on, copying from other people has been frowned
> upon; people who write programs by borrowing other code get the
> Rodney Dangerfield treatment (which is why maintenance programmers
> are held in such low esteem). Yet the best shops are able to
> reuse 80% of their code. Most shops are lucky to do 20% reuse.
> Does anyone seriously think that rewriting the COBOL overhead -
> four divisions and various statements - every single time a program
> is created makes any sense? No, and most people have a skeleton
> frame of the program to start with. Yet that practice in and of
> itself shows that having usable pre-written code to pick from
> makes people more productive.


I agree that code reuse needs to increase. But...


Reusing tiny pieces of code is usually not worth it. As Paul points out,
you usually end up changing it anyway, or if you don't, you had to spend
longer looking for it than it would take you to write it. The larger the
database, the longer the lookup time.


Reusing large pieces of code is better. But writing reusable software
that does something complicated enough to justify reuse is hard, real hard
-- and time-consuming. Suppose you go to your manager and say, "I can
have it done in 3 months, or a year if you'll let me make it reusable."
I'll give you one guess which way the manager is likely to vote.


The point is, that manager is not being totally stupid. He's trying to
make a decision that can be justified. What if it turns out that code is
never needed by his department again? He just wasted 9 months. Very many
decisions like that, and his job is history.


And in cases where the software is being developed for sale (as opposed to
being used in-house only), the case for reusable is even less easy to
make. Management will want the software released as soon as possible,
because that will bring in revenues. And revenues pay the salaries. It's
no good saying you'll have a great product, with lots of reusable
software, in 2 years if the company goes bankrupt first.


I'm not saying that's what would happen: but that's the way management
thinks. In fact, that's the way they're *paid* to think. It's not all
their fault.


I don't mean to sound all "doom and gloom", because I think there's hope.
But before we start calling for more tools, we need to develop some way of
convincing management that the ones we have are really worth their price.
Either that, or find a way to make the tools a lot cheaper.
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.