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

OFF TOPIC: Introduction

[Zahid Rahman]

Hi,


I wish to correct an error on my part, I feel I should have introduced
myself as soon as I logged on.

I was advised by my College Lecturer that I should look for a junior
position on a project to start my career.

I was offered two positions after two job interviews

   1.

   product Support role for a database company or
   2.

   Junior Software Engineer.

I decided to go for the junior software position as that would help me

for self development.

As Junior position one usually starts out doing testing. I was lucky enough
to work for a bespoke hardware and bespoke software company in the aircraft
industry. I would highly recommend a career start in the aerospace and
defence.

There, you will find out what best practices are, for example I was sent on
a week course to learned ADA 83. No libraries are inherited, every line of
code is written to meet specification. Software is tested in a number of
different ways.

The first project, aircraft fuel management system used state of the art
hardware. I quickly moved from testing to another project to find the cause
of software crash. That software needed to be reset via a hardware reset
and the GUI was a red light in the pilot cockpit.

This move happened because I pointed out my observation to the Tech Lead,
from my understanding of a compiler and emulator that “Phil the contractor”
was testing the emulator and he wants me to do the same.

After that I joined a single product company which used 4GL, CA Open road
and Ingress Database with  approx. 250 tables. This company was also built
on best practices with principals same as my first job. The software was
then migrated from CA OpenRoad & Ingress to Oracle forms and Oracle
database.

To complete my self development I joined a software house where I was
exposed to a number of projects at different stages.

There I identified that a 2 tier thin client architecture was an ill
conceived design. My view was confirmed when I found tomcat an application
server which was part of a 3 tier architecture. With this discovery I felt
I conquered Grady Booche's remark that “Industrial Strength software was
beyond the intellect of a developer.”

Ironically 2 tier thin client product used for developing applications,
like struts is used for building applications, was from same company which
offered me the support role. Would I have achieved my objective if I had
taken that support role and not the junior software position ?

At this stage, I do not believe in learning programming language first but
start with the architecture first. That is how I arrived at struts. There
were a number of other requirements which were met by struts also.

I hope this helps anyone looking to master Industrial Strength Software.

Keep in mind,   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.

Regards

Zahid