Re: OFF TOPIC: Introduction

[Dale Newfield]

On Dec 5, 2019, at 8:58 PM, Zahid Rahman  wrote:
> 
> I dislike the concept of Javadoc for same reason that documents are
> generated from the code which flies in the face of best software
> development practice as I understand it.

Are well written javadoc on a Java Interface a reasonable compromise?

-Dale

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: OFF TOPIC: Introduction

[Zahid Rahman]

The code had already undergone two tests.
1. Electrical Rig tests.
2. Physical Rig Tests.
Which showed the code meets the  customer requirements.

The unit test step was the third step . Unit tests are written by
independent  developers. But not by looking at the procedure parameters and
return values from code.

But from the specification document where the algorithms  were detailed for
each procedure and each variable.

That is to say detailed documents on code. Before code.

The unit tests are to make sure the developer followed the documents.

I think the problem here on this email line is that detailed documents of
code before code is written is a challenging concept to grasp. This is also
is known as best practice.

Underlying my point that programmers want to dive into code. Then later
they get unstuck.

I dislike the concept of Javadoc for same reason that documents are
generated from the code which flies in the face of best software
development practice as I understand it.







On Thu, 5 Dec 2019, 22:00 Martin Gainty,  wrote:

> DOB correct
>
> if the dev isnt willing to verify their code works with at least one unit
> test then whats the point of development?
>
> dave did you see the case of the pacemaker's recording of heart electrical
> activity solved a homicide in Australia?
>
> https://www.smh.com.au/national/pacemakers-electrical-memory-that-foiled-a-murderers-alibi-in-court-20030120-gdg4uz.html
>
> best regards
> m.
>
> 
> From: Dave Newton 
> Sent: Tuesday, December 3, 2019 11:31 AM
> To: Struts Users Mailing List 
> Subject: Re: OFF TOPIC: Introduction
>
> On Tue, Dec 3, 2019 at 9:43 AM Zahid Rahman  wrote:
>
> > If the developer  tests his own code then there is a danger that he will
> > pass his misunderstanding of specification.
> >
>
> Correct.
>
>
> > Anyway in the safety critical environments the one who wrote the code
> does
> > not do the testing.
> >
>
> That's simply not the case across the board: there are multiple tiers of
> testing, and the onus is on the developer to do the initial testing.
>
> For example, when I was writing pacemakers--you better believe we tested
> the *crap* out of our code. Were we the *only* ones testing? Of course not;
> there were *many* levels of testing--but it *started* with us.
>
>
> > Tests are also done on hardware electrical rigs ,  simulating feed to
> > sensors.
> >
>
> Yep. And when I was writing fuel pump controllers not only did *I* have a
> set of tests, so did the hardware guys, so did the combination of HW/SW
> guys, so did the verification group, so did whoever gave us our
> certification, etc.
>
> It's not entirely clear to me what your point is, or if you're just arguing
> for the sake of arguing.
>
> Testing is, by necessity, the responsibility of everyone involved in the
> project, which includes the developer.
>
> d.
>

Re: OFF TOPIC: Introduction

[Martin Gainty]

DOB correct

if the dev isnt willing to verify their code works with at least one unit test 
then whats the point of development?

dave did you see the case of the pacemaker's recording of heart electrical 
activity solved a homicide in Australia?
https://www.smh.com.au/national/pacemakers-electrical-memory-that-foiled-a-murderers-alibi-in-court-20030120-gdg4uz.html

best regards
m.


From: Dave Newton 
Sent: Tuesday, December 3, 2019 11:31 AM
To: Struts Users Mailing List 
Subject: Re: OFF TOPIC: Introduction

On Tue, Dec 3, 2019 at 9:43 AM Zahid Rahman  wrote:

> If the developer  tests his own code then there is a danger that he will
> pass his misunderstanding of specification.
>

Correct.


> Anyway in the safety critical environments the one who wrote the code does
> not do the testing.
>

That's simply not the case across the board: there are multiple tiers of
testing, and the onus is on the developer to do the initial testing.

For example, when I was writing pacemakers--you better believe we tested
the *crap* out of our code. Were we the *only* ones testing? Of course not;
there were *many* levels of testing--but it *started* with us.


> Tests are also done on hardware electrical rigs ,  simulating feed to
> sensors.
>

Yep. And when I was writing fuel pump controllers not only did *I* have a
set of tests, so did the hardware guys, so did the combination of HW/SW
guys, so did the verification group, so did whoever gave us our
certification, etc.

It's not entirely clear to me what your point is, or if you're just arguing
for the sake of arguing.

Testing is, by necessity, the responsibility of everyone involved in the
project, which includes the developer.

d.

Re: OFF TOPIC: Introduction

[Dave Newton]

On Tue, Dec 3, 2019 at 1:43 PM Zahid Rahman  wrote:

> What more can I say  (:
>

Nothing--I think most everybody already knows that sometimes people do dumb
things.

d..

Re: OFF TOPIC: Introduction

[Zahid Rahman]

"Phil the contractor" was the first of many in IT industry. I have a long
list.

This guy refers to multimillion real life blunders which I describe in
detail as [lots of words].

What more can I say  (:





On Tue, 3 Dec 2019, 18:33 Dave Newton,  wrote:

> On Tue, Dec 3, 2019 at 1:14 PM Zahid Rahman  wrote:
>
> > What developers do isn't testing.
> >
> > [Bottom up programmer].
> >
>
> This is demonstrably incorrect (trivially). It doesn't even make sense.
>
> AFAIC the burden of proof is on you, because developers do valid testing
> all the time.
>
> (And yes, some developers do some invalid testing some of the time.)
>
> I would challenge the supposition that we didn't test the pacemaker (or the
> fuel pump, although it wasn't as extreme, I'd say) within inches of its
> life, or the payment processing code (ACH stuff pretty much has to work),
> or any number of other projects. You appear to confuse different layers of
> testing, all of which are required (to varying degrees), with "testing",
> which is not a single thing. You're making a lot of assumptions based on
> your specific experience--which is fine, but it might be a good idea to
> take a small step back and recognize that your experience is not everyone's
> experience, what you're calling "testing" is in fact a field unto itself,
> and that maybe some additional experience might broaden your horizons.
>
> Good luck!
>
> d.
>

Re: OFF TOPIC: Introduction

[Dave Newton]

On Tue, Dec 3, 2019 at 1:14 PM Zahid Rahman  wrote:

> What developers do isn't testing.
>
> [Bottom up programmer].
>

This is demonstrably incorrect (trivially). It doesn't even make sense.

AFAIC the burden of proof is on you, because developers do valid testing
all the time.

(And yes, some developers do some invalid testing some of the time.)

I would challenge the supposition that we didn't test the pacemaker (or the
fuel pump, although it wasn't as extreme, I'd say) within inches of its
life, or the payment processing code (ACH stuff pretty much has to work),
or any number of other projects. You appear to confuse different layers of
testing, all of which are required (to varying degrees), with "testing",
which is not a single thing. You're making a lot of assumptions based on
your specific experience--which is fine, but it might be a good idea to
take a small step back and recognize that your experience is not everyone's
experience, what you're calling "testing" is in fact a field unto itself,
and that maybe some additional experience might broaden your horizons.

Good luck!

d.

Re: OFF TOPIC: Introduction

[Zahid Rahman]

What developers do isn't testing.

[Bottom up programmer].


On Tue, 3 Dec 2019, 18:10 Dave Newton,  wrote:

> On Tue, Dec 3, 2019 at 12:57 PM Zahid Rahman  wrote:
>
> > We have a difference in opinion. You think you can't  do enough testing.
> >  I  think there are some tests which counts for nothing. It is just
> testing
> > for testing sake.
> >
>
> No, I think there are tests that count for nothing, or test the wrong
> things, or don't test enough.
>
> That doesn't mean developers can't, or shouldn't, test.
>
>
> > [lots of other words]
> >
>
> Neat.
>
> d.
>

Re: OFF TOPIC: Introduction

[Dave Newton]

On Tue, Dec 3, 2019 at 12:57 PM Zahid Rahman  wrote:

> We have a difference in opinion. You think you can't  do enough testing.
>  I  think there are some tests which counts for nothing. It is just testing
> for testing sake.
>

No, I think there are tests that count for nothing, or test the wrong
things, or don't test enough.

That doesn't mean developers can't, or shouldn't, test.


> [lots of other words]
>

Neat.

d.

Re: OFF TOPIC: Introduction

[Zahid Rahman]

We have a difference in opinion. You think you can't  do enough testing.
 I  think there are some tests which counts for nothing. It is just testing
for testing sake.

Because we have difference in opinion/ approach doesn't mean you should get
personal.

At the end of the day people like me who started their career from testing
and maintenance  have a top down approach. Not bottom up.

Bottom up approach  programmers migrate from 4GL to 4GL without seeing the
stupidity of it.

Programming 2 tier thin clients without seeing the stupidity that fat
clients are deployed on user machines so when it comes to thin clients how
can you replace the functionality on the server side when there is only  a
database.

I have no doubt those project were thoroughly tested and all tests passed.
So what went wrong?

That's to say Oracle sold it and bottom up programmers program it without
first looking at specifications and features.

I am proud of the fact I did not write one line of code  in a 4GL to 4GL
migration or 2 tier thin client.

Re: OFF TOPIC: Introduction

[Dave Newton]

On Tue, Dec 3, 2019 at 9:43 AM Zahid Rahman  wrote:

> If the developer  tests his own code then there is a danger that he will
> pass his misunderstanding of specification.
>

Correct.


> Anyway in the safety critical environments the one who wrote the code does
> not do the testing.
>

That's simply not the case across the board: there are multiple tiers of
testing, and the onus is on the developer to do the initial testing.

For example, when I was writing pacemakers--you better believe we tested
the *crap* out of our code. Were we the *only* ones testing? Of course not;
there were *many* levels of testing--but it *started* with us.


> Tests are also done on hardware electrical rigs ,  simulating feed to
> sensors.
>

Yep. And when I was writing fuel pump controllers not only did *I* have a
set of tests, so did the hardware guys, so did the combination of HW/SW
guys, so did the verification group, so did whoever gave us our
certification, etc.

It's not entirely clear to me what your point is, or if you're just arguing
for the sake of arguing.

Testing is, by necessity, the responsibility of everyone involved in the
project, which includes the developer.

d.

Re: OFF TOPIC: Introduction

[Zahid Rahman]

If the developer  tests his own code then there is a danger that he will
pass his misunderstanding of specification.

Anyway in the safety critical environments the one who wrote the code does
not do the testing.

Testing is done by developers.Of course.

On that point I will agree to disagree because the Tech Lead on the project
I worked on would never do the testing.

Phil the contractor was doing unit tests from the code  not from
specification, all he was doing was testing the compiler or the VMS
emulator ( dumb  terminal client server). He was never seen  again.

The safety critical people take testing very seriously. I waited for "phil
the contractor" the next day to give me the specification. The manager said
don't worry about him he won't be coming.
I went from testing to maintenance, ladder up the project lifecycle.

Tests are also done on hardware electrical rigs ,  simulating feed to
sensors.

The fuel management  system was setup up inside fuel tanker and driven
across the city, simulating the movement of an aircraft. Up and down hills
etc.

Apart from live testing which would be fourth type of testing.

Coding in that environment  is merely 10%-15 % of project resources. Should
be part on any project.

I have come across baffoons who want to dive into coding without even going
through the team analysis and design stage. The ones who don't want to
learn anything new are the worst like the  "phil the visual Basic
programmer." The tech lead  who abandoned the project when I told him
everything  is going server side.

 That was not the only buffoonary he displayed because he could not wait to
dive into coding.





















On Tue, 3 Dec 2019, 12:33 Dave Newton,  wrote:

> On Tue, Dec 3, 2019 at 07:04 Zahid Rahman  wrote:
>
> > test from specification not from code and testing MUST not
> > to be done by the person who wrote the code as suggested in a book I read
> > recently.
>
>
> Testing is multi-tiered just like the rest of large applications.
> Developers are in a unique position to do more in-depth testing than pure
> black-box testing would allow, including testing interop layers invisible
> to, say, QA at the front-end.
>
> There's a reason there are different names for different types of testing,
> and ideally, there are multiple layers of testing, performed across dev
> groups.
>
> Dave
>
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: OFF TOPIC: Introduction

[Dave Newton]

On Tue, Dec 3, 2019 at 07:04 Zahid Rahman  wrote:

> test from specification not from code and testing MUST not
> to be done by the person who wrote the code as suggested in a book I read
> recently.


Testing is multi-tiered just like the rest of large applications.
Developers are in a unique position to do more in-depth testing than pure
black-box testing would allow, including testing interop layers invisible
to, say, QA at the front-end.

There's a reason there are different names for different types of testing,
and ideally, there are multiple layers of testing, performed across dev
groups.

Dave

-- 
em: davelnew...@gmail.com
mo: 908-380-8699
tw: @dave_newton 
li: dave-newton 
gh: davelnewton 
so: Dave Newton 
bl[0]: Bucky Bits 
bl[1]: Maker's End Blog 
sk: davelnewton_skype