[OT] I got a JOB!!!

AT Wednesday 17 May 2017 17:32, Tom Gardner wrote:

> On 17/05/17 09:57, Reinhardt Behm wrote:
>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>
>>> On 17/05/17 01:56, Don Y wrote:
>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>> The other dysfunctional aspect of unit tests is that,
>>>>> while they are very useful when making incremental
>>>>> improvements during design, they can be a real
>>>>> impediment in a few months/years time. The problem is
>>>>> that over time people forget which tests demonstrate
>>>>> required properties, and which are merely ensuring
>>>>> behaviour of implementation artifacts. At that point
>>>>> people are afraid to make changes that break tests,
>>>>> even if the tests are unimportant. At that point the
>>>>> codebase has become ossified.
>>>>
>>>> But that's true any time you (attempt to) nail down
>>>> an aspect of a design.  Moreso if you don't provide a
>>>> rationale for WHY the requirement (whether it be from a
>>>> spec or a test) was imposed.
>>>
>>> Of course. Nonetheless, it happens - and zealots
>>> sometimes refuse to admit it.
>>
>> Therefor any good development process demands that requirements
>> (high-level, or low-level) must be traceable to system requirements or
>> must be marked as design decisions. Then you have the WHY.
>> A test can not be the source of a requirement. A test should also be
>> traceable to sys-reqs.
>> And hopefully the sys-reqs are good.
> 
> We are in violent agreement.
> 
> But my point is about the XP/Agile/TDD/Unit Test
> zealots that overstate the benefits of those
> techniques and ignore their dysfunctional aspects.

No disagreement here.

When I hear those people, the method seems to be: 
We don't know where we are going, but let's just start walking and every day 
we do a sprint. 
For me that is the best recipe for disaster. 
But I must confess I sometimes do something like this: When the customer 
does not really know what he wants or I myself need to get a feeling how a 
useful user interface should be. Then I do prototyping this way. Later the 
sys-reqs are derived from these prototypes and the software is developed 
again according to these reqs. The prototyping-code goes into a CVS-branch 
called "playground".

-- 
Reinhardt

On 5/17/2017 1:57 AM, Reinhardt Behm wrote:
> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>
>> On 17/05/17 01:56, Don Y wrote:
>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>> The other dysfunctional aspect of unit tests is that,
>>>> while they are very useful when making incremental
>>>> improvements during design, they can be a real
>>>> impediment in a few months/years time. The problem is
>>>> that over time people forget which tests demonstrate
>>>> required properties, and which are merely ensuring
>>>> behaviour of implementation artifacts. At that point
>>>> people are afraid to make changes that break tests,
>>>> even if the tests are unimportant. At that point the
>>>> codebase has become ossified.
>>>
>>> But that's true any time you (attempt to) nail down
>>> an aspect of a design.  Moreso if you don't provide a
>>> rationale for WHY the requirement (whether it be from a
>>> spec or a test) was imposed.
>>
>> Of course. Nonetheless, it happens - and zealots
>> sometimes refuse to admit it.
>
> Therefor any good development process demands that requirements (high-level,
> or low-level) must be traceable to system requirements or must be marked as
> design decisions. Then you have the WHY.

But if all of this is written in "legalese", you can easily end up with
a document(s) that is ambiguous -- even to the original author(s), some
time after it's been written!

[Lawyers spend a lot of time trying to write precise contracts; then
spend the rest of their time trying to pick holes/ambiguities in the
contracts written by others!]

1. A game shall consist of 3, 4 or 5 balls, adjustable by the operator.
2. At the end of the last ball, the game shall be over.
3. A free ball shall be awarded for each 10,000 points.
4. The maximum ball count shall not exceed 6.

Seems like a straight forward, terse specification.
But, it doesn't explicitly indicate that the OPERATOR is a different
entity from the PLAYER (nor does it even mention how a game is PLAYED).

Nor does it clearly indicate the sequencing of these requirements.

If configured for 5 balls and, during the play of the first ball,
the player attains a score of 22000, is he awarded *2* free balls,
one for each 10,000 point attainment?  Or, just one (because he's
already been allocated *5*)?

If you've chosen to implement a "balls remaining" counter, then
does that counter indicate "4" while the player is playing his
first ball?  So, can it be incremented to 6 by the two "free balls"
and still remain in compliance with requirement #4?

If a player achieves 10,000 points on *each* ball played, does this
mean he can essentially "play forever" -- a free ball awarded to replace
the ball he is currently playing?

Now, imagine someone tweeks the specification to incorporate a "bonus"
feature that allows points to be "banked" during play -- perhaps
spanning the play of several balls.  If the "last ball" is in play
and the current score is 9000 with an accumulated bonus of 3000,
does that ball leaving the playfield (end of play for that ball)
terminate the game before or after the bonus is awarded?  As the
score rolls past 10,000 when the bonus is awarded, is new life
breathed into the player as he is awarded a free ball *by* that
bonus award?  Or, has "play" been considered terminated BEFORE
the bonus is awarded (he gets the points but not the additional
feature of the free ball)

As systems get more complex (this was a trivial one!), it is easy
for someone tweeking a specification to lose track of the many
interdependencies/relationships between clauses.  So, the consequences
of a new requirement can be insidious.

Furthermore, the requirements can effectively *suggest* an
implementation without actually *mandating* it.  E.g., "ball count"
is easily interpreted as "ball countER", despite being different
semantic entities.

A well written spec will formally define all of these terms
AND each instance of such a term.  So, "BALL COUNT" will *not*
be assumed when reading "The display will indicate the ball count".
But, it is really hard to catch all of these details when writing
*or* (proof)reading such a document.

A more prosaic description (incl examples) can convey intent in
a conversational (instead of declarative) tone.

> A test can not be the source of a requirement. A test should also be
> traceable to sys-reqs.

Yes.

> And hopefully the sys-reqs are good.

On 5/17/2017 3:12 AM, Reinhardt Behm wrote:
> AT Wednesday 17 May 2017 17:32, Tom Gardner wrote:
>
>> On 17/05/17 09:57, Reinhardt Behm wrote:
>>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>>
>>>> On 17/05/17 01:56, Don Y wrote:
>>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>>> The other dysfunctional aspect of unit tests is that,
>>>>>> while they are very useful when making incremental
>>>>>> improvements during design, they can be a real
>>>>>> impediment in a few months/years time. The problem is
>>>>>> that over time people forget which tests demonstrate
>>>>>> required properties, and which are merely ensuring
>>>>>> behaviour of implementation artifacts. At that point
>>>>>> people are afraid to make changes that break tests,
>>>>>> even if the tests are unimportant. At that point the
>>>>>> codebase has become ossified.
>>>>>
>>>>> But that's true any time you (attempt to) nail down
>>>>> an aspect of a design.  Moreso if you don't provide a
>>>>> rationale for WHY the requirement (whether it be from a
>>>>> spec or a test) was imposed.
>>>>
>>>> Of course. Nonetheless, it happens - and zealots
>>>> sometimes refuse to admit it.
>>>
>>> Therefor any good development process demands that requirements
>>> (high-level, or low-level) must be traceable to system requirements or
>>> must be marked as design decisions. Then you have the WHY.
>>> A test can not be the source of a requirement. A test should also be
>>> traceable to sys-reqs.
>>> And hopefully the sys-reqs are good.
>>
>> We are in violent agreement.
>>
>> But my point is about the XP/Agile/TDD/Unit Test
>> zealots that overstate the benefits of those
>> techniques and ignore their dysfunctional aspects.
>
> No disagreement here.
>
> When I hear those people, the method seems to be:
> We don't know where we are going, but let's just start walking and every day
> we do a sprint.

Yes.  It's the same sort of misplaced attitude that leads to folks sitting down
on Day One and writing code -- cuz they know they won't have enough time to get
it done, so best get started ASAP (despite not knowing WHAT they are writing)

> For me that is the best recipe for disaster.
> But I must confess I sometimes do something like this: When the customer
> does not really know what he wants or I myself need to get a feeling how a
> useful user interface should be. Then I do prototyping this way. Later the
> sys-reqs are derived from these prototypes and the software is developed
> again according to these reqs. The prototyping-code goes into a CVS-branch
> called "playground".

I write user manuals, now, instead of specifications.  They have to address
all of the same information that is presented in a specification -- cuz the
user needs to know why/when this "error" will be thrown, or that constraint
imposed, etc.

It's also a great way to anticipate unnecessary complexity forced on the
user.  Or, a brittle interface (Why does he need to tell me his name
BEFORE he tells me his age?  Why do I need to KNOW those facts in that
order??).

If you place yourself in the user's shoes ("I only know what I have *read*,
up to this point!") then it also helps you anticipate the
questions/uncertainties that the user will encounter while using the
product/device/system ("ah, he doesn't YET understand that there are FREE
balls in addition to the balls allocated at the start of the game!")

And, it gives you a systematic way of challenging yourself as to the
constraints that you are imposing:  "What happens if the user doesn't
comply with this?  What do I do?  How do I tell him he's deviated
from the requirements?"

You're going to EVENTUALLY have to convert your specifications into
a User Manual.  So, why not get it out of the way?  This lets other
folks "pretend" to be using this (eventual) product/device/system
long before it is actually reified.  So, they can *imagine* the
sorts of things that might go wrong, expose flaws in your document, etc.

Instead of having to actually *build*/prototype it and hope they
stumble on those same problems by "poking REAL buttons" (instead
of hypothetical buttons)

On 17/05/17 19:31, Tom Gardner wrote:
> I get the feeling your experience in this area
> is with academic problems - which are valuable
> pedagogical examples, but no more.

We had this discussion before. I don't want to do it again.

I personally wrote most of a million of lines of code which is
performing daily core management functions on over ten million
enterprise computers, including almost all the computers used
in the armed forces of three OECD nations, as well as a number
of banks, oil companies, national postal services, etc.

I'm well aware of the requirements that cannot even be
expressed, let alone tested. I'm also well aware of the
general state of ignorance about what *can* be achieved.

Any more ignorant accusations?

Tim Wescott <seemywebsite@myfooter.really> writes:

> Since this is a newsgroup, and this is news...
>
> Wescott Design Services is going into remission, while I pursue a day 
> job.  Job title is Software Designer 5 at Planar Systems -- so any 
> circuit design or control systems jones will have to be satisfied by 
> hobby work or on the side.
>
> In the near term I'll be finishing up current work with current 
> customers; in the longer term I'll probably concentrate on the 
> educational videos and maybe hobby stuff.
>
> Lots of embedded Linux work in my near future, and possibly TDD 
> proselytizing.

Congratulations Tim. We'll have to exchange trade secrets someday...

BTW, does PS use a specific unit test framework? Have you used it
yet? How do you like it?
-- 
Randy Yates, Embedded Firmware Developer
Garner Underground, Inc.
866-260-9040, x3901
http://www.garnerundergroundinc.com

AT Wednesday 17 May 2017 18:54, Don Y wrote:

> On 5/17/2017 3:12 AM, Reinhardt Behm wrote:
>> AT Wednesday 17 May 2017 17:32, Tom Gardner wrote:
>>
>>> On 17/05/17 09:57, Reinhardt Behm wrote:
>>>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>>>
>>>>> On 17/05/17 01:56, Don Y wrote:
>>>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>>>> The other dysfunctional aspect of unit tests is that,
>>>>>>> while they are very useful when making incremental
>>>>>>> improvements during design, they can be a real
>>>>>>> impediment in a few months/years time. The problem is
>>>>>>> that over time people forget which tests demonstrate
>>>>>>> required properties, and which are merely ensuring
>>>>>>> behaviour of implementation artifacts. At that point
>>>>>>> people are afraid to make changes that break tests,
>>>>>>> even if the tests are unimportant. At that point the
>>>>>>> codebase has become ossified.
>>>>>>
>>>>>> But that's true any time you (attempt to) nail down
>>>>>> an aspect of a design.  Moreso if you don't provide a
>>>>>> rationale for WHY the requirement (whether it be from a
>>>>>> spec or a test) was imposed.
>>>>>
>>>>> Of course. Nonetheless, it happens - and zealots
>>>>> sometimes refuse to admit it.
>>>>
>>>> Therefor any good development process demands that requirements
>>>> (high-level, or low-level) must be traceable to system requirements or
>>>> must be marked as design decisions. Then you have the WHY.
>>>> A test can not be the source of a requirement. A test should also be
>>>> traceable to sys-reqs.
>>>> And hopefully the sys-reqs are good.
>>>
>>> We are in violent agreement.
>>>
>>> But my point is about the XP/Agile/TDD/Unit Test
>>> zealots that overstate the benefits of those
>>> techniques and ignore their dysfunctional aspects.
>>
>> No disagreement here.
>>
>> When I hear those people, the method seems to be:
>> We don't know where we are going, but let's just start walking and every
>> day we do a sprint.
> 
> Yes.  It's the same sort of misplaced attitude that leads to folks sitting
> down on Day One and writing code -- cuz they know they won't have enough
> time to get it done, so best get started ASAP (despite not knowing WHAT
> they are writing)
> 
>> For me that is the best recipe for disaster.
>> But I must confess I sometimes do something like this: When the customer
>> does not really know what he wants or I myself need to get a feeling how
>> a useful user interface should be. Then I do prototyping this way. Later
>> the sys-reqs are derived from these prototypes and the software is
>> developed again according to these reqs. The prototyping-code goes into a
>> CVS-branch called "playground".
> 
> I write user manuals, now, instead of specifications.  They have to
> address all of the same information that is presented in a specification
> -- cuz the user needs to know why/when this "error" will be thrown, or
> that constraint imposed, etc.
> 
> It's also a great way to anticipate unnecessary complexity forced on the
> user.  Or, a brittle interface (Why does he need to tell me his name
> BEFORE he tells me his age?  Why do I need to KNOW those facts in that
> order??).
> 
> If you place yourself in the user's shoes ("I only know what I have
> *read*, up to this point!") then it also helps you anticipate the
> questions/uncertainties that the user will encounter while using the
> product/device/system ("ah, he doesn't YET understand that there are FREE
> balls in addition to the balls allocated at the start of the game!")
> 
> And, it gives you a systematic way of challenging yourself as to the
> constraints that you are imposing:  "What happens if the user doesn't
> comply with this?  What do I do?  How do I tell him he's deviated
> from the requirements?"
> 
> You're going to EVENTUALLY have to convert your specifications into
> a User Manual.  So, why not get it out of the way?  This lets other
> folks "pretend" to be using this (eventual) product/device/system
> long before it is actually reified.  So, they can *imagine* the
> sorts of things that might go wrong, expose flaws in your document, etc.
> 
> Instead of having to actually *build*/prototype it and hope they
> stumble on those same problems by "poking REAL buttons" (instead
> of hypothetical buttons)

No problem with this. The sys-reqs should just convey what the system does 
or should do. Your method of writing a "user manual" makes a some sense to 
me. As you rite it might help to find problems in the reqs. Thus help to 
create correct reqs.

My main point is that there should be a clearly defined spec for the system. 
Whether this is prose or what you call legalese is not so important. The 
spec I write are also more prose than legalese. But I need something that I 
can also easily use to develop test cases from. I am not sure how to easily 
do that and be sure to have covered everything. It could make a gap analysis 
more complicated.

-- 
Reinhardt

In article <xOUSA.16651$C56.666@fx34.am4>, spamjunk@blueyonder.co.uk 
says...
> 
> On 17/05/17 10:10, Paul wrote:
> > In article <B0USA.14491$8r1.938@fx42.am4>, spamjunk@blueyonder.co.uk
> > says...
> > .......
> >> The simple point to bear in mind is that the results of TDD
> >> are only as good as the quality of the tests. Test the
> >> wrong/unimportant thing, or don't test important behaviour,
> >> and the outcome can be "suboptimal".
> >>
> >> That's not a difficult point (to put it mildly!), but it
> >> is horrifying how it is ignored by zealots and/or not
> >> appreciated by inexperienced.
> >>
> >> The best defense is, to quote one of the two mottoes
> >> worth a damn, "Think". No change there, then!
> >
> > The Titanic sank but I bet nearly all the individual parts past their
> > unit tests.
> >
> > Or the video I saw on Dev Humor a while back of sliding door and bolt
> > to lock door fixed wrong way. Each part past its unit tests.
> 
> Yup.
> 
> None of this is difficult, but it does seem
> to escape some people :(

Some of the classic videos

http://devhumor.com/media/2-unit-tests-0-integration-tests

and

https://www.youtube.com/watch?v=0GypdsJulKE



-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/LogicCell/> Logic Gate Education
<http://www.pcserviceselectronics.co.uk/fonts/>     Timing Diagram Font
<http://www.badweb.org.uk/>    For those web sites you hate

On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:

> Tim Wescott <seemywebsite@myfooter.really> writes:
> 
>> Since this is a newsgroup, and this is news...
>>
>> Wescott Design Services is going into remission, while I pursue a day
>> job.  Job title is Software Designer 5 at Planar Systems -- so any
>> circuit design or control systems jones will have to be satisfied by
>> hobby work or on the side.
>>
>> In the near term I'll be finishing up current work with current
>> customers; in the longer term I'll probably concentrate on the
>> educational videos and maybe hobby stuff.
>>
>> Lots of embedded Linux work in my near future, and possibly TDD
>> proselytizing.
> 
> Congratulations Tim. We'll have to exchange trade secrets someday...
> 
> BTW, does PS use a specific unit test framework? Have you used it yet?
> How do you like it?

I start next week, so I don't know and no.  It's my former coworker from 
FLIR who's pushing TDD, and the manager who hired me is kind of warily 
standing on the sidelines going "what's the deal here?"

The guy pushing it is extremely smart and capable, so whatever it is it's 
probably good.

-- 
www.wescottdesign.com

On 17-05-17 13:54 , Don Y wrote:
> On 5/17/2017 3:12 AM, Reinhardt Behm wrote:
>>  [snips]
>> But I must confess I sometimes do something like this: When the customer
>> does not really know what he wants or I myself need to get a feeling
>> how a useful user interface should be. Then I do prototyping this way.
>> Later the sys-reqs are derived from these prototypes and the software
>> is developed again according to these reqs. The prototyping-code goes
>> into a CVS-branch called "playground".
>
> I write user manuals, now, instead of specifications.  They have to address
> all of the same information that is presented in a specification -- cuz the
> user needs to know why/when this "error" will be thrown, or that constraint
> imposed, etc.

For my last product, I wrote a combined user manual and requirement 
specification, using LibreOffice conditional text: set a document 
variable one way, it is a user manual; set the variable differently, and 
every meaningful paragraph gets a requirement number that can be 
referenced in tests and validation matrices.

Only drawback is that the paragraphs are rather shorter than in usual prose.

Of course this document expresses only high-level, user-level 
requirements. The same approach would not work for low-level, technical 
requirements, I think.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On Wed, 17 May 2017 10:32:59 +0100, Tom Gardner wrote:

> On 17/05/17 09:57, Reinhardt Behm wrote:
>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>
>>> On 17/05/17 01:56, Don Y wrote:
>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>> The other dysfunctional aspect of unit tests is that,
>>>>> while they are very useful when making incremental improvements
>>>>> during design, they can be a real impediment in a few months/years
>>>>> time. The problem is that over time people forget which tests
>>>>> demonstrate required properties, and which are merely ensuring
>>>>> behaviour of implementation artifacts. At that point people are
>>>>> afraid to make changes that break tests, even if the tests are
>>>>> unimportant. At that point the codebase has become ossified.
>>>>
>>>> But that's true any time you (attempt to) nail down an aspect of a
>>>> design.  Moreso if you don't provide a rationale for WHY the
>>>> requirement (whether it be from a spec or a test) was imposed.
>>>
>>> Of course. Nonetheless, it happens - and zealots sometimes refuse to
>>> admit it.
>>
>> Therefor any good development process demands that requirements
>> (high-level,
>> or low-level) must be traceable to system requirements or must be
>> marked as design decisions. Then you have the WHY.
>> A test can not be the source of a requirement. A test should also be
>> traceable to sys-reqs.
>> And hopefully the sys-reqs are good.
> 
> We are in violent agreement.
> 
> But my point is about the XP/Agile/TDD/Unit Test zealots that overstate
> the benefits of those techniques and ignore their dysfunctional aspects.

That's kind of the definition of a zealot.

Something that Reinhardt -- and I think maybe you -- are missing, is that 
part of the reason for agile is that requirements don't remain static.  
As soon as people see a something working, the requirements change -- and 
saying "no, I'm sorry person-who-signs-checks, we're going to spend the 
next year making what you asked for initially and THEN we're going to 
entertain change requests".

So you can't treat requirements as static things graved in stone.  Agile 
tries to deal with that, and as near as I can tell, only having nibbled 
at the edges of it, it does a reasonably good job of it for things that 
aren't terribly safety critical.  Agile is also new, so it's naturally 
going to attract zealots -- the trick is to see the value underneath the 
hype, and then make rational choices about what to do.

-- 
www.wescottdesign.com