By designing it to be of high quality, and by using methodologies
that maintain that through the coding?
Look up CICS and Z.
Regards,
Nick Maclaren.
We throw a lot of code away, and rewrite it constantly when hardware
specification changes. That's life in the R&D. When you are re-
inventing the wheel it's easy to make fancy design documents and such,
because you already know what the f**k you are doing in the first
place.
Not so when you are doing something new. If you could write the design
document it's based on something that you know already.. so where's
the research part in the R&D?
I work in a field where the design is customer driven. They make
roadmaps. We make our roadmaps to align with theirs. We look at what
we have in our inventory, what new stuff the research has come up
with. Then we plan. We come up with number of proposals.. they are
introduced to the customers, shot down or looked into further. There
are many different outcomes from this.. two common ones are the one
where we agree what the product specification should be, more or less,
and sign a contract to do the development. The other approach is that
we design products on our own, come up with a platform or discrete
product we want to license.
During this process there is a team of software engineers who work
with the hardware engineers, who constantly update the spefication
based on customer _and_ software requirements. It's ideal when they
are similar so that compromise does not need to be done.. if you can
put something in silicon that saves CPU time to setup stuff, that's
great.. but it might consumer more power and exceed the power budget
for the part.
And so the software is changed, revised, rewritten. It's alive entity.
The KEY is to have a framework that is easy to modify and adapt to
changes in the environment the software has to live in. These include
different processor architectures, operating systems, system
components, memory bus type, latencies of various things, timings,
availability of mmu and so on and on.
If a guy comes and says with a straight face that he has a nice solid
good design document for the next generation product, I can show you a
pretty awesome liar.
At some point the design does come together, so to speak, after
various models have been benchmarked and tested and stressed out. This
is the time to draft a design document and let the technical writer(s)
to do their magic. The goal of the document isn't as much to keep the
design and software teams in sync or aware what they are doing; they
know that already from 100's of meetings all the time. It is for the
end-user of the part, so that they can integrate it into their
products and doing it while they actually UNDERSTAND the design
philisophy and all that goes with that. It's not just inputs and
outputs, but it's a great deal if it were that simple. =)
Of course, if you can do the design ahead of time, that's awesome.
Sometimes you can do that. But when you can't, see above for example,
it's not fair to claim that any other way is wrong.
I'd vaguely hoped the Grid mob was slightly more clued up 
