Re: next the good jobs will go

Glenn wrote:
On Tue, 05 Aug 2008 11:46:26 -0700, Islander wrote:

Glenn wrote:
On Tue, 05 Aug 2008 09:09:51 -0700, Islander wrote:

Glenn wrote:
On Mon, 04 Aug 2008 19:05:15 -0700, Islander wrote:


It depends. The Japanese perfected the flexible response to market
demand. They are constantly experimenting in the marketplace, even
putting competing products out at the same time. When the market
changes, they are able to turn on a dime and produce something new.

This is a lesson that we have not yet learned in this country. We
have long development cycles based on products that our marketing
departments think the market will want two years from now. This is
guaranteed to put beautifully engineered products out there that the
customers no longer want.

This is the arrogance of American corporations. And, the Asians are
cleaning our clock!

The global software development scheme that I described is directly
aimed at this issue. They can turn around a software update in a
fraction of the time that a strictly domestic development effort can
accomplish. It is all about beating the competition to the market,
again and again and again.
DEC introduced this process long, long ago (late seventies as I
recall). The problem is that customer satisfaction and product quality
continues to take a back seat to schedule. Trust me, the key is
customer involvement, if the customers are in a hurry, give them a
skeleton system and phase in function. Once the customers finds that
they no longer have to break in the product, they will work with the
producers to their mutual benefit. Marketing's job isn't to tell the
customer what he will need in two years, their job is to work with the
customer base; with marketing providing options and the customers
getting together to make selections. The customers have to work with
the developers, whether it's after release and they debug the product
or before design and they get what they had in mind. If that's
arrogance, then I haven't been paying attention. I'm betting that the
Asians will go the same way as DEC -- as customers much prefer
boondoggles to downtime.


I use the analogy of a feedback control system. If the delay in the
feedback loop is too long, the system is unstable. Your enterprise
needs to be able to react quickly to the market. I agree that
marketing's job should *not* be to tell the customer what he will need
in two years. That is arrogance.

The Internet made rapid prototyping and iterative product improvement
easier to do, especially across time zones. The "around the globe"
development strategy was especially dependent on the ability to quickly
and inexpensively move data.

All this is not without it's pitfalls, however. There is a classic
case study where the Air Force implemented a management information
system with an early version of critical path analysis (a software tool
that is used to manage project flow). The contractor was on the west
coast, three time zones away. Each morning the Air Force managers
would arrive at work and review the progress of the previous day,
updated overnight on the computers of the day. By the time the
contractor showed up for work three hours later, the phone would be
ringing off the hook! They would not, of course, have seen the
overnight update yet, so a great deal of time would be wasted putting
out fires that should not have started in the first place.

Management information system specialists should be required to take a
course in feedback control systems!
Did I ever mention the prototype hmc compiler I wrote for engineering
microcoders for S/38, coded in 370 command language, that lasted for
well over five years. The change from batch to interactive did it in. In my experience, management likes prototypes, customers don't.

The programming process we used was called the waterfall model, taken
from NASA, modified, showed up in most software engineering texts, and
used feedback extensively. We never could settle on a design language
and then along came high level (fourth generation languages) so we quit
trying. The microcoders often used flow charts, not being in a hurry to
modernize.


You are revealing your age! Don't get me started on the waterfall model. IMV, it was one of the major failures of software engineering! It is
extremely difficult to know what the customer wants in sufficient detail
to design and implement software using the waterfall model. There are
classic examples of it's failure. It produced magnificent code that
usually ended up solving the wrong problem.

I was an advocate of the waterfall model when it was first introduced, but
one of the people who worked for me immediately pointed out the problem -
no one can specify the problem to be solved in sufficient detail to allow
the disciplined implementation. Attempts were made to correct it
utilizing internal feedback loops as you point out, but the problem was in
the original specification. Many of the failed monster software systems
in the federal government are a result of this misguided methodology.

It has been substantially replaced by rapid prototyping and iterative
refinement.

Oh I hope not, prototyping and iterative refinement are for application
programs not system programs where ever component is specified, otherwise
one could never produce an operation system. Even so, it's very difficult
and probably the main reason for no new OS. Sometimes it seemed as every
week had it's design review and even then we needed code and test case
reviews. If the waterfall model isn't taught, we can write off NASA's
Mars shot and any new OS development. Maybe we could force the
programmers to fly the mission.


Well, UNIX was not developed using the waterfall model and is probably the best OS out there today (at least the derivatives of UNIX are). One would think that a technology as old as OS could be completely specified, but that has proved to be only in the imagination of the software engineering past. Would you believe that there are still research programs in operating systems?

The issue of software systems like the Mar's lander is different. You are right in implying that we cannot keep shooting up missions until we get the software right. The approach used here is the application of simulators to test coupled with the ability to upload updates when bugs are discovered. The simulators are developed in a separate organization from the one developing the system code to give an independent perspective. It is kind of like the old joke about when a munitions manufacturer happened to meet an armor manufacturer at the Defense Procurement Office. "Just when I build a better projectile, somehow they come up with a more severe test..."

The inability to specify large complex software systems is one of the reasons that the Strategic Defense Initiative was and is a bad idea. A friend of mine presided over a panel of computer scientists who were tasked with determining the technical feasibility of this part of the SDI program. He made an interesting observation. Software developers tend to treat software as if it were an exercise in the design of a finely engineered watch. Every part is designed to perform a specific function and is optimized to do that function and no other. He concluded that software systems should be designed like communication systems. These are designed in the anticipation that any part may and probably will fail in unanticipated ways.
.

Relevant Pages

  • Re: next the good jobs will go
    ... departments think the market will want two years from now. ... customers no longer want. ... The Internet made rapid prototyping and iterative product improvement ... The programming process we used was called the waterfall model, ...
    (soc.retirement)
  • Re: next the good jobs will go
    ... departments think the market will want two years from now. ... involvement, if the customers are in a hurry, give them a skeleton ... I use the analogy of a feedback control system. ... The programming process we used was called the waterfall model, ...
    (soc.retirement)
  • Re: UL/ETL Choking the market
    ... As a lighting designer with a lot of experience outside the US market ... In most of the world, standards are written to require manufacturers, ... design freedom the least possible, with descriptive, performance based ... It costs construction clients enormously. ...
    (sci.engr.lighting)
  • Re: UL/ETL Choking the market
    ... As a lighting designer with a lot of experience outside the US market ... In most of the world, standards are written to require manufacturers, ... design freedom the least possible, with descriptive, performance based ... assured market is required before it is worth the cost of testing. ...
    (sci.engr.lighting)
  • Re: UL/ETL Choking the market
    ... As a lighting designer with a lot of experience outside the US market ... In most of the world, standards are written to require manufacturers, ... design freedom the least possible, with descriptive, performance based ... assured market is required before it is worth the cost of testing. ...
    (sci.engr.lighting)
Loading