[Info-vax] HP wins Oracle Itanium case

[ChrisQ]

On 08/23/12 07:10, Howard S Shubs wrote:

>
> Expecting code to work the first time strikes me as a complete
> contradiction to all my experience.

Ime, a very achievable goal, depending on the development techniques used.

>
>
>> Of course you often need to debug code, but the point I was trying to
>> make was that the "debugger" should rarely be the first option. On
>> some sites, the debugger is the first thing to be fired up if a
>> program doesn't work, where 10 minutes analysing program behaviour
>> and sources is often far more productive...
>
> I think I see.  You're talking either about something I've never heard
> of, or you're talking about print statements.  I rarely see programs
> simple enough to do what you seem to be suggesting.

Ok, let's elaborate a bit. Code written here is always small modules
which encapsulate the functionality, the internal data and variables that it
uses, It's then easy to write test harness code to exercise the module with
good and bad data. Even when the project doesn't allow time for the test
harness approach, small modules make it easier to keep the functionality
clean and visually easy to debug. There is also a better chance that the
overall system will work first time, or very nearly, once all those modules
have been linked into the final image. I'm sometimes accused of being
obsessive, as there are various other issues, such as abstraction, (you
don't need C++ for that) the avoidance of global variables etc, but 
that's all
part of the overall approach to make code more robust and bug free. Have
had decades to develop all this and it does work, at least for me. Partly
lazyness as well; I really don't want to have to debug code because
I didn't think it through properly in the first place. It's not my idea
either. On one site that I worked at years ago, modules were run on a
simulator with every path through the code exercised and verified. I rarely
have time for that level of testing now, but it's possible to use a
subset of such techniques and the coding practices that go with it.

>
> You and Hoff seem to be coming from a realm of programming beyond what
> I've experienced.
>

Not uncommon, ime. It does depend on the company and individual culture as
well. It's not uncommon to see people go straight to the the editor and 
start
coding immediately to "design" the system, whereas a bit more time upfront
with paper, sharp pencil and discussing solutions to the requirements, can
save weeks of debug time. ie: Decisions made early on can have a 
significant
effect later :-)...

Regards,

Chris