[OT] I got a JOB!!! - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: [OT] I got a JOB!!!
On 17/05/17 00:32, Tim Wescott wrote:
Quoted text here. Click to load it

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!

Re: [OT] I got a JOB!!!
says...
.......
Quoted text here. Click to load it

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.

--  
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: [OT] I got a JOB!!!
On 17/05/17 10:10, Paul wrote:
Quoted text here. Click to load it

Yup.

None of this is difficult, but it does seem
to escape some people :(


Re: [OT] I got a JOB!!!
says...
Quoted text here. Click to load it

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          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: [OT] I got a JOB!!!
On 17/05/17 15:59, Paul wrote:
Quoted text here. Click to load it

:)

Of course there's a good argument that much (most?)
"integration testing" is really just "unit testing"
with larger units.

People can get too stuck on the specific definition
(of unit) they have been taught.

Re: [OT] I got a JOB!!!
On 17/05/17 00:32, Tim Wescott wrote:
Quoted text here. Click to load it

Another stumbling block can be to get people to consider
the definition of "unit" in a unit test. Too frequently
they equate it with "unit" = class/method.

Sometimes they have difficulty thinking that unit can be
a subsystem - they think that /can't/ be unit testing
because it is "integration testing".

If they argue, get them to define what they mean by
a "unit test", and then point out that actually their
"unit test" isn't testing a unit. It is testing the
integration of their code and library code (and
compiler and runtime).

The corollary is that TDD mentality and technology
can - and often should - be applied to integration
testing. All you have to do is increase the granularity
of the UUT.

Re: [OT] I got a JOB!!!
On 5/16/2017 3:51 PM, Tom Gardner wrote:
Quoted text here. Click to load it

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.

It's like having a law go before a judge and the
judge having only the text of the law on which to base
his ruling -- he needs context as to the *intent*
to more correctly understand it.

I've taken to moving towards "prose" descriptions instead
of "legalese specsmanship" in defining how systems "should"
work.  Describe particular examples and how the "ought to's"
apply instead of just listing a set of SHALLs and SHALL NOTs.

Ditto with regression tests ("WHY is this test here?")

The kinds of gross perversions that a particular piece of
software is expected to not just *tolerate* but expeditiously
*accommodate* are unheard of in most other disciplines.

Like taking a 10W wall wart and deciding it should now support
a wider range of input voltages, an additional output and
three times the power rating -- without changing the size
of the package or its selling price.

Or, adding another floor to a preexisting building.  Etc.

Quoted text here. Click to load it


Re: [OT] I got a JOB!!!
On 17/05/17 01:56, Don Y wrote:
Quoted text here. Click to load it

Of course. Nonetheless, it happens - and zealots
sometimes refuse to admit it.


Re: [OT] I got a JOB!!!
AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:

Quoted text here. Click to load 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.

--  
Reinhardt

Re: [OT] I got a JOB!!!
On 17/05/17 09:57, Reinhardt Behm wrote:
Quoted text here. Click to load it

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.


Re: [OT] I got a JOB!!!
AT Wednesday 17 May 2017 17:32, Tom Gardner wrote:

Quoted text here. Click to load it

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


Re: [OT] I got a JOB!!!
On 5/17/2017 3:12 AM, Reinhardt Behm wrote:
Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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)

Re: [OT] I got a JOB!!!
AT Wednesday 17 May 2017 18:54, Don Y wrote:

Quoted text here. Click to load it

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


Re: [OT] I got a JOB!!!
On 5/17/2017 6:57 AM, Reinhardt Behm wrote:
Quoted text here. Click to load it

Being conversational/narrative instead of declarative *seems* to be easier
for folks (e.g., clients) to relate to the content.  Listing a set of
"dry" requirements, free of context, seems to strain most folks' imaginations
("How does this pertain to <whatever>?").

Illustrations and a foamcore/cardboard/wood mockup (e.g., so they can see the
keys on a keypad, get an idea where the whizzbanger is located in relation to
that -- "Gee, how will left-handed folks feel using this?" -- and start
IMAGINING a real unit without requiring all the effort to fabricate the
electronics, software, etc.).

IME, any effort put into slapping together a "talking demo" (Dog 'n' Pony)
is hard to *discard*; there's always the nagging thought that you could
SALVAGE that effort and be a bit closer to "done".

But, you've probably not fully documented nor tested that stuff as it
wasn't expected to be ready for prime time.  And, you'll be biased
in your attempts to document/test it now -- opting to describe "what you
see" (or want to see) and not what it *should* have been, had you done
it AFTER knowing what your ultimate goal would be.

Quoted text here. Click to load it

Preaching to the choir...

Quoted text here. Click to load it

I understand your point, but I actually do think there is a big difference!
I used to write very detailed, "technical" specifications in "legalese"...
defining each term, formally, before use; highlighting each instance of
it in the text to draw attention to its role as a "Proper Noun" (so to speak);
etc.

I found that people found these too dry (IBM/Xerox-ish) and couldn't relate
the "requirement" to the likely implementation that would ultimately follow.
The User Manual approach is deliberately more colloquial and directly pertinent
to the final (yet to be produced) product.

I.e., when it talks about how the device will react to "incorrect user actions"
(lets not call them "user errors"), there is a narrative that puts those
actions in a context:  "Ah, OK; I can see how someone might do this out of
order..."

And, as I would ultimately end up having to create such a document, it
gives me that document "free" (at the expense of the "specification";
but, the folks that would normally see the specification see it in this
disguised -- but EQUIVALENT -- form).  I am loathe to have a single
datum (the "specification") present in two different forms -- it opens
the door for the two to disagree or for one to be updated without the
changes reflected in the other, etc.

Quoted text here. Click to load it

Yes.  But, easier for *you* to take on some "heavy lifting" than to pass
that extra effort on to others -- who may not be as disciplined!

(Life's not fair  :> )

Re: [OT] I got a JOB!!!
On 17-05-17 13:54 , Don Y wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: [OT] I got a JOB!!!
On Wed, 17 May 2017 18:07:14 +0300, Niklas Holsti

Quoted text here. Click to load it


FWIW, for many years (and perhaps still today), IBM did just that with
the ISA specification for S/360 and its descendents (The "Principles
of Operation" manual).  The internal version has considerably more
detail about corner cases, implementation issues, design choices, use
cases, the actual handing of architecturally undefined items, etc. But
both the internal and external versions were (are?) produced off a
common, marked-up, source document.

Re: [OT] I got a JOB!!!
On 5/17/2017 8:07 AM, Niklas Holsti wrote:
Quoted text here. Click to load it

The problem, here, is that you have the same "data" represented in two
different forms (views/documents).  So, there is the implicit concern
that the two may be -- or become -- out of sync.  Like comments in code
not agreeing with what the code is NOW doing (after some revision).

I think verifying the two are in agreement is a harder task requiring
more discipline than preparing either document individually.  It's too
tempting to just think (hope!) you've got BOTH documents so "let's move
on"...

Quoted text here. Click to load it

It's impractical to write a "manual" for something as fine-grained as a
function -- or the power conditioning circuitry (if hardware-speak) *in*
a design.

OTOH, its not a stretch to write a "manual" (or, "a descriptive text")
for a subsystem.  This allows you to present your design approach,
background information, competing approaches (that you ruled out -- along
with an explanation of "why"), establish a lexicon (that you can then
use without further clarification in your source code, etc.), etc.

E.g., in describing my gesture recognizer, I have an assortment of
largely arbitrary terms to reference various aspects of the dataset
in the algorithm:  points, beziers, curves, paths, segments, gestures,
etc.  As each has a specific use, those uses need to be clarified
so a "segment" isn't referenced when a "path" is intended, etc.

In past projects, I'd include several pages of prose in the source code
explaining what was going to happen in the module(s) that followed.
By pulling this out of the source code file(s), I can now augment it
with illustrations, animations, multimedia, etc.

Re: [OT] I got a JOB!!!
On 5/17/2017 9:47 AM, Don Y wrote:
Quoted text here. Click to load it

By way of another example, in the "tutorials" (not a "user manual")
for my speech synthesizers...

When confined to solely ASCII text, one would traditionally use
symbols like AY EY AW IY IH AA etc for "vowel sounds".  And,
without any training, READers (deliberate emphasis) would almost
always mistake the sounds being referenced.

E.g., "AY" does not represent the "long a" sound in "say" but,
rather, the "long i" sound in "ride" (!)

Abandoning ASCII (by NOT including the descriptive text in the
ASCII source code files), I can use the more correct IPA symbol
for the sound (a sort of ligatured "ai" -- which STILL suggests
a "long a" sound to a naive READer).

Further, adopting a document container that lets me include multimedia
in the presentation means I can let a READer become a LISTENer -- and
play a sound clip of the particular sound being indicated by the grapheme.

[If you've lived in different parts of the country (USA), you'd recognize
that you can't just use words as examples of sounds -- the 'a' in "mash"
is pronounced very differently in different parts of the country; the 'y'
in "my" mimics the 'i' sound in "ride" in some places but sounds like
"mah" in others!]

Re: [OT] I got a JOB!!!
On 17-05-17 19:47 , Don Y wrote:
Quoted text here. Click to load it

The _text_ of the document is unchanged in the two views, except for  
some meta-text paragraphs that explain the purpose and structure of the  
document. The "requirement specification" view only adds the formal  
machinery (requirement identifiers and requirement index) for  
tracebility with tests. The user manual and the specifications cannot go  
"out of sync".

--  
Niklas Holsti
Tidorum Ltd
We've slightly trimmed the long signature. Click to see the full one.
Re: [OT] I got a JOB!!!
On 5/17/2017 10:25 AM, Niklas Holsti wrote:
Quoted text here. Click to load it

Then your "manual" and "spec" read like the same document -- i.e.,
the same "tone" and manner of presentation.

I will explain something differently to two different (types of)
audiences.  E.g., when I know I'm talking to a mathematician
(or, someone who would have a solid grasp of mathematical concepts),
I'll employ "equations" and "relations" freely.  The same concepts
expressed to the /hoi polloi/ would tend to be conveyed in a more
verbosely descriptive manner, perhaps accompanied by anecdotes or
"real world examples".

E.g., the tutorial for my Cubic Bezier implementation includes
interactive demos -- so the "reader" can move control points
around and *see* the impact on the resulting curves (instead
of trying to describe them in terms of their "approaching
and departing" tangents, presence of loops/discontinuities,
etc.

The "mathematician" would see this as a superfluous "toy"
(as he already understands how the equations behave).  But, the
casual user -- or neophyte -- would see it as a means of empirically
exploring the problem and learning at a pace that best fits his
abilities.

The other folks "in the middle" would know the basics and
be able to explore some of the boundary conditions that my
*application* of the technology exploits.

E.g., these tuples all represent what *appears* (after rendering)
as a "straight line (segment) from (0,0) to (1,0):

{(0,0), (0,0),   (0,0),    (1,0)}
{(0,0), (0,0),   (1,0),    (1,0)}
{(0,0), (1,0),   (1,0),    (1,0)}
{(0,0), (0.5,0), (0.5,0),  (1,0)}
{(0,0), (1,0),   (0,0),    (1,0)}   !!
{(0,0), (1.2,0), (-0.2,0), (1,0)}   !!!!
etc.

But, have different computational costs and transient dynamics.

The mathematician say, "Yes, of course!".
The programmer says, "Let me check on that..."
And the /hoi polloi/ say "But, I don't SEE any difference..."

The interative nature of the tutorial lets them *approach*
the understanding of the problem/solution.

Site Timeline