Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26537 > unrolled thread

[OT] I got a JOB!!!

Back to article view | Back to comp.arch.embedded

Contents

  [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 13:49 -0500
    Re: [OT] I got a JOB!!! Steve Wilson <no@spam.com> - 2017-05-16 19:04 +0000
    Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 12:14 -0700
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-16 14:41 -0500
        Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 14:01 -0700
          Re: [OT] I got a JOB!!! mike <ham789@netzero.net> - 2017-05-16 14:42 -0700
          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 17:09 -0500
            Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 16:42 -0700
          Re: [OT] I got a JOB!!! Clifford Heath <clifford.heath@gmail.com> - 2017-05-17 09:00 +1000
    Re: [OT] I got a JOB!!! eric.jacobsen@ieee.org - 2017-05-16 20:17 +0000
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-16 15:24 -0500
        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-16 22:05 +0100
          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 17:11 -0500
            Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-16 23:51 +0100
              Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 18:32 -0500
                Re: [OT] I got a JOB!!! Clifford Heath <clifford.heath@gmail.com> - 2017-05-17 09:41 +1000
                  Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 09:35 +0100
                    Re: [OT] I got a JOB!!! Clifford Heath <no.spam@please.net> - 2017-05-17 19:03 +1000
                      Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 10:31 +0100
                        Re: [OT] I got a JOB!!! Clifford Heath <no.spam@please.net> - 2017-05-17 23:07 +1000
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 09:41 +0100
                  Re: [OT] I got a JOB!!! Paul <paul@pcserviceselectronics.co.uk> - 2017-05-17 10:10 +0100
                    Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 10:34 +0100
                      Re: [OT] I got a JOB!!! Paul <paul@pcserviceselectronics.co.uk> - 2017-05-17 15:59 +0100
                        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:04 +0100
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:02 +0100
              Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 17:56 -0700
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 09:42 +0100
                  Re: [OT] I got a JOB!!! Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 16:57 +0800
                    Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 10:32 +0100
                      Re: [OT] I got a JOB!!! Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 18:12 +0800
                        Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 03:54 -0700
                          Re: [OT] I got a JOB!!! Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 21:57 +0800
                            Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 09:36 -0700
                          Re: [OT] I got a JOB!!! Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-05-17 18:07 +0300
                            Re: [OT] I got a JOB!!! Robert Wessel <robertwessel2@yahoo.com> - 2017-05-17 10:44 -0500
                            Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 09:47 -0700
                              Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 10:18 -0700
                              Re: [OT] I got a JOB!!! Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-05-17 20:25 +0300
                                Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 12:01 -0700
                      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-17 10:25 -0500
                        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:22 +0100
                          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 12:36 -0500
                            Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:45 +0100
                    Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 03:42 -0700
    Re: [OT] I got a JOB!!! "billbowden" <bperryb@bowdenshobbycircuits.info> - 2017-05-16 15:04 -0700
      Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 15:30 -0700
    Re: [OT] I got a JOB!!! Martin Riddle <martin_ridd@verizon.net> - 2017-05-16 20:02 -0400
    Re: [OT] I got a JOB!!! krw@notreal.com - 2017-05-16 20:40 -0400
    Re: [OT] I got a JOB!!! Randy Yates <randyy@garnerundergroundinc.com> - 2017-05-17 09:12 -0400
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-17 10:02 -0500
        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:11 +0100
          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 12:21 -0500
            Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:36 +0100
              Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 12:43 -0500
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:55 +0100
                  Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:57 +0100
                  Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 13:28 -0500
                    Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 20:08 +0100
    Re: [OT] I got a JOB!!! boB K7IQ <boB@everett.wa> - 2017-05-17 21:30 -0700
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-18 00:03 -0500
      Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-18 08:18 +0100
        Re: [OT] I got a JOB!!! boB K7IQ <boB@everett.wa> - 2017-05-18 22:56 -0700
          Re: [OT] I got a JOB!!! Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 14:31 +0300
            Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-19 10:39 -0500
              Re: [OT] I got a JOB!!! Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 23:02 +0300
                Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-19 13:12 -0700
                  Re: [OT] I got a JOB!!! dplatt@coop.radagast.org (Dave Platt) - 2017-05-19 15:00 -0700
                    Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-19 16:05 -0700
                Re: [OT] I got a JOB!!! boB K7IQ <boB@everett.wa> - 2017-05-21 01:46 -0700
                  Re: [OT] I got a JOB!!! Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-21 17:31 +0300
                    Re: [OT] I got a JOB!!! John S <Sophi.2@invalid.org> - 2017-05-21 13:31 -0500
                    Re: [OT] I got a JOB!!! krw@notreal.com - 2017-05-21 16:47 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#26562

On 17/05/17 00:32, Tim Wescott wrote:
> On Tue, 16 May 2017 23:51:26 +0100, Tom Gardner wrote:
>
>> On 16/05/17 23:11, Tim Wescott wrote:
>>> On Tue, 16 May 2017 22:05:49 +0100, Tom Gardner wrote:
>>>
>>>> On 16/05/17 21:24, Tim Wescott wrote:
>>>>> On Tue, 16 May 2017 20:17:17 +0000, eric.jacobsen wrote:
>>>>>
>>>>>> On Tue, 16 May 2017 13:49:28 -0500, Tim Wescott
>>>>>> <seemywebsite@myfooter.really> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Software Designer 5?   Sounds a little like being in Sector 7-G?
>>>>>
>>>>> "Really Senior Embedded Guy".
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Time Division Duplex?
>>>>>
>>>>> Test Driven Design.
>>>>
>>>> Be prepared to meet some people that believe X works /because/ all the
>>>> unit tests for X are passed and the console shows a green light.
>>>
>>> Well, yes.  The two main good things about TDD for me is that it makes
>>> me think early about how something really should work, and there are
>>> finer- grained tests to make sure that if I did something really
>>> dumbass it gets caught.
>>>
>>> Even with TDD, I still find errors, so I don't live under the delusion
>>> that you can test in quality.
>>>
>>>> Usually they have never been introduced to the concept that "you can't
>>>> test quality into a product".
>>>> Unit tests developed as part of TDD are highly beneficial, but are not
>>>> sufficient.
>>>>
>>>> But I'm sure you know that!
>>>
>>> Yea verily!!
>>
>> 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.
>>
>> Classic anti-patterns warning of that: unit tests on getters/setters,
>> and/or changing visibility solely to enable unit tests.
>
> That's an interesting point.  I haven't been using TDD long enough for
> that to be an issue.  Good to know!

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!

[toc] | [prev] | [next] | [standalone]

#26566

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.

-- 
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

[toc] | [prev] | [next] | [standalone]

#26570

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 :(

[toc] | [prev] | [next] | [standalone]

#26579

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

[toc] | [prev] | [next] | [standalone]

#26590

On 17/05/17 15:59, Paul wrote:
> 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

:)

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.

[toc] | [prev] | [next] | [standalone]

#26589

On 17/05/17 00:32, Tim Wescott wrote:
> On Tue, 16 May 2017 23:51:26 +0100, Tom Gardner wrote:
>
>> On 16/05/17 23:11, Tim Wescott wrote:
>>> On Tue, 16 May 2017 22:05:49 +0100, Tom Gardner wrote:
>>>
>>>> On 16/05/17 21:24, Tim Wescott wrote:
>>>>> On Tue, 16 May 2017 20:17:17 +0000, eric.jacobsen wrote:
>>>>>
>>>>>> On Tue, 16 May 2017 13:49:28 -0500, Tim Wescott
>>>>>> <seemywebsite@myfooter.really> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Software Designer 5?   Sounds a little like being in Sector 7-G?
>>>>>
>>>>> "Really Senior Embedded Guy".
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Time Division Duplex?
>>>>>
>>>>> Test Driven Design.
>>>>
>>>> Be prepared to meet some people that believe X works /because/ all the
>>>> unit tests for X are passed and the console shows a green light.
>>>
>>> Well, yes.  The two main good things about TDD for me is that it makes
>>> me think early about how something really should work, and there are
>>> finer- grained tests to make sure that if I did something really
>>> dumbass it gets caught.
>>>
>>> Even with TDD, I still find errors, so I don't live under the delusion
>>> that you can test in quality.
>>>
>>>> Usually they have never been introduced to the concept that "you can't
>>>> test quality into a product".
>>>> Unit tests developed as part of TDD are highly beneficial, but are not
>>>> sufficient.
>>>>
>>>> But I'm sure you know that!
>>>
>>> Yea verily!!
>>
>> 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.
>>
>> Classic anti-patterns warning of that: unit tests on getters/setters,
>> and/or changing visibility solely to enable unit tests.
>
> That's an interesting point.  I haven't been using TDD long enough for
> that to be an issue.  Good to know!

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.

[toc] | [prev] | [next] | [standalone]

#26558

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.

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.

> Classic anti-patterns warning of that: unit tests on
> getters/setters, and/or changing visibility solely
> to enable unit tests.

[toc] | [prev] | [next] | [standalone]

#26563

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.

[toc] | [prev] | [next] | [standalone]

#26564

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.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#26569

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.

[toc] | [prev] | [next] | [standalone]

#26571

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

[toc] | [prev] | [next] | [standalone]

#26573

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)

[toc] | [prev] | [next] | [standalone]

#26576

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

[toc] | [prev] | [next] | [standalone]

#26587

On 5/17/2017 6:57 AM, Reinhardt Behm wrote:
>> 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.

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.

> My main point is that there should be a clearly defined spec for the system.

Preaching to the choir...

> Whether this is prose or what you call legalese is not so important. The

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.

> 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.

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  :> )

[toc] | [prev] | [next] | [standalone]

#26582

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
       .      @       .

[toc] | [prev] | [next] | [standalone]

#26585

On Wed, 17 May 2017 18:07:14 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> wrote:

>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.


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.

[toc] | [prev] | [next] | [standalone]

#26588

On 5/17/2017 8:07 AM, Niklas Holsti wrote:
> 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.

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"...

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

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.

[toc] | [prev] | [next] | [standalone]

#26592

On 5/17/2017 9:47 AM, Don Y wrote:
> 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.

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!]

[toc] | [prev] | [next] | [standalone]

#26595

On 17-05-17 19:47 , Don Y wrote:
> On 5/17/2017 8:07 AM, Niklas Holsti wrote:
>> 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.
>
> 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).

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
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#26606

On 5/17/2017 10:25 AM, Niklas Holsti wrote:
>>> 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.
>>
>> 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).
>
> 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".

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web