[Semi-OT] Painting in the Dark

Gentle People,

I am on an embedded firmware project that is (gasp) on a short schedule.
The manager has decided to put testing on the back burner and simply get
_something_ running as fast as possible without doing any testing
further than simple checks in the debugger.

This bugs me (pun intended). I wasn't sure why; after all, the manager
knows this is a bad idea and is clearly willing to take the risk.

I examined myself a little deeper, and I found that I don't just want to
write/modify code, but I want to create something that is useful and
aesthetically pleasing.

An analogy that came to my mind was that this is like "painting in the
dark."

Can anyone else relate?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On Wed, 12 Mar 2014 12:38:50 -0400
Randy Yates <yates@digitalsignallabs.com> wrote:

> Gentle People,
> 
> I am on an embedded firmware project that is (gasp) on a short schedule.
> The manager has decided to put testing on the back burner and simply get
> _something_ running as fast as possible without doing any testing
> further than simple checks in the debugger.
> 
> This bugs me (pun intended). I wasn't sure why; after all, the manager
> knows this is a bad idea and is clearly willing to take the risk.
> 
> I examined myself a little deeper, and I found that I don't just want to
> write/modify code, but I want to create something that is useful and
> aesthetically pleasing.
> 
> An analogy that came to my mind was that this is like "painting in the
> dark."
> 
> Can anyone else relate?
> -- 
> Randy Yates
> Digital Signal Labs
> http://www.digitalsignallabs.com

Elegant is usually the word I use, but yeah I know exactly what you
mean. You want to finish the project up and say, "This is elegant. This
not only works, but is well documented and maintainable.  If I had to
step in on this project with no prior knowledge, I would find it a
pleasure." Not, "Well, it looks good from the front."


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Rob Gaddi <rgaddi@technologyhighland.invalid> writes:

> On Wed, 12 Mar 2014 12:38:50 -0400
> Randy Yates <yates@digitalsignallabs.com> wrote:
>
>> Gentle People,
>> 
>> I am on an embedded firmware project that is (gasp) on a short schedule.
>> The manager has decided to put testing on the back burner and simply get
>> _something_ running as fast as possible without doing any testing
>> further than simple checks in the debugger.
>> 
>> This bugs me (pun intended). I wasn't sure why; after all, the manager
>> knows this is a bad idea and is clearly willing to take the risk.
>> 
>> I examined myself a little deeper, and I found that I don't just want to
>> write/modify code, but I want to create something that is useful and
>> aesthetically pleasing.
>> 
>> An analogy that came to my mind was that this is like "painting in the
>> dark."
>> 
>> Can anyone else relate?
>> -- 
>> Randy Yates
>> Digital Signal Labs
>> http://www.digitalsignallabs.com
>
> Elegant is usually the word I use, but yeah I know exactly what you
> mean. You want to finish the project up and say, "This is elegant. This
> not only works, but is well documented and maintainable.  If I had to
> step in on this project with no prior knowledge, I would find it a
> pleasure." 

Rob,

Yes, those are all things I would _hope_ someone would think of my work. 
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Randy Yates wrote:
> Gentle People,
>
> I am on an embedded firmware project that is (gasp) on a short schedule.
> The manager has decided to put testing on the back burner and simply get
> _something_ running as fast as possible without doing any testing
> further than simple checks in the debugger.
>
> This bugs me (pun intended). I wasn't sure why; after all, the manager
> knows this is a bad idea and is clearly willing to take the risk.
>

Because that is what they do. At least when I get one of those, it's 
usually for actual business reasons.

"Simple checks in the debugger" however won't cut it - at least borrow
the reasonable parts of test first. Depending on how things can be 
decomposed and how you can get test vectors and test results in and out 
of the product, my experience is that if you don't tell people you're 
doing it,they don't notice.

I can't really separate coding and basic testing much any more.

> I examined myself a little deeper, and I found that I don't just want to
> write/modify code, but I want to create something that is useful and
> aesthetically pleasing.
>

He may have realized that defects will be more measurable than testing,
and he'll get money for defects that he can't get up front.

It's the "think I'll code myself a minivan" theory of
project management.

> An analogy that came to my mind was that this is like "painting in the
> dark."
>
> Can anyone else relate?
>

To an extent.

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> [...]
> Randy Yates wrote:
>> I examined myself a little deeper, and I found that I don't just want to
>> write/modify code, but I want to create something that is useful and
>> aesthetically pleasing.
>>
> He may have realized that defects will be more measurable than testing,
> and he'll get money for defects that he can't get up front.

Les,

I didn't think of that as a possible reason. Good point.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 3/12/14 7:10 PM, Les Cargill wrote:
> Randy Yates wrote:
>> Gentle People,
>>
>> I am on an embedded firmware project that is (gasp) on a short schedule.
>> The manager has decided to put testing on the back burner and simply get
>> _something_ running as fast as possible without doing any testing
>> further than simple checks in the debugger.
>>
>> This bugs me (pun intended). I wasn't sure why; after all, the manager
>> knows this is a bad idea and is clearly willing to take the risk.
>>
>
> Because that is what they do. At least when I get one of those, it's
> usually for actual business reasons.
>
> "Simple checks in the debugger" however won't cut it - at least borrow
> the reasonable parts of test first. Depending on how things can be
> decomposed and how you can get test vectors and test results in and out
> of the product, my experience is that if you don't tell people you're
> doing it,they don't notice.
>
> I can't really separate coding and basic testing much any more.
>
>> I examined myself a little deeper, and I found that I don't just want to
>> write/modify code, but I want to create something that is useful and
>> aesthetically pleasing.
>>
>
> He may have realized that defects will be more measurable than testing,
> and he'll get money for defects that he can't get up front.
>
> It's the "think I'll code myself a minivan" theory of
> project management.
>
>> An analogy that came to my mind was that this is like "painting in the
>> dark."
>>
>> Can anyone else relate?

Randy, they could be setting you up.  if it works without "basic 
testing" (whatever it is you think they should do), the manager was 
brilliant pushing this along without that unnecessary crap.  if it fails 
at something or 'nother, and consequently delays the schedule more than 
planned, who will be held to account?

and about elegance of code and design, these guys are just fucking 
clueless.  they do not understand how they hurt the project by cutting 
corners around "unnecessary refactoring" of the code.  if it's not 
short-term, it doesn't matter.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Wed, 12 Mar 2014 10:06:45 -0700, Rob Gaddi wrote:

> If I had to
> step in on this project with no prior knowledge, I would find it a
> pleasure." Not, "Well, it looks good from the front."

I like that turn of phrase.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

robert bristow-johnson wrote:
> On 3/12/14 7:10 PM, Les Cargill wrote:
>> Randy Yates wrote:
>>> Gentle People,
>>>
>>> I am on an embedded firmware project that is (gasp) on a short schedule.
>>> The manager has decided to put testing on the back burner and simply get
>>> _something_ running as fast as possible without doing any testing
>>> further than simple checks in the debugger.
>>>
>>> This bugs me (pun intended). I wasn't sure why; after all, the manager
>>> knows this is a bad idea and is clearly willing to take the risk.
>>>
>>
>> Because that is what they do. At least when I get one of those, it's
>> usually for actual business reasons.
>>
>> "Simple checks in the debugger" however won't cut it - at least borrow
>> the reasonable parts of test first. Depending on how things can be
>> decomposed and how you can get test vectors and test results in and out
>> of the product, my experience is that if you don't tell people you're
>> doing it,they don't notice.
>>
>> I can't really separate coding and basic testing much any more.
>>
>>> I examined myself a little deeper, and I found that I don't just want to
>>> write/modify code, but I want to create something that is useful and
>>> aesthetically pleasing.
>>>
>>
>> He may have realized that defects will be more measurable than testing,
>> and he'll get money for defects that he can't get up front.
>>
>> It's the "think I'll code myself a minivan" theory of
>> project management.
>>
>>> An analogy that came to my mind was that this is like "painting in the
>>> dark."
>>>
>>> Can anyone else relate?
>
> Randy, they could be setting you up.  if it works without "basic
> testing" (whatever it is you think they should do), the manager was
> brilliant pushing this along without that unnecessary crap.  if it fails
> at something or 'nother, and consequently delays the schedule more than
> planned, who will be held to account?
>

Yeah, there's that. At some point, though, all that bad will breaks down 
the social fabric of the team and ... well, it's not good.

Without trust, it all gets a little "The Good, The Bad and the Ugly."
Schumpeter awaits. You can't replace trust with formalism.

> and about elegance of code and design, these guys are just fucking
> clueless.

But clueless by design.

 > they do not understand how they hurt the project by cutting
> corners around "unnecessary refactoring" of the code.  if it's not
> short-term, it doesn't matter.
>

-- 
Les Cargill

Randy Yates wrote:

> Gentle People,
>
> I am on an embedded firmware project that is (gasp) on a short schedule.
> The manager has decided to put testing on the back burner and simply get
> _something_ running as fast as possible without doing any testing
> further than simple checks in the debugger.
>
> This bugs me (pun intended). I wasn't sure why; after all, the manager
> knows this is a bad idea and is clearly willing to take the risk.
>
> I examined myself a little deeper, and I found that I don't just want to
> write/modify code, but I want to create something that is useful and
> aesthetically pleasing.
>
> An analogy that came to my mind was that this is like "painting in the
> dark."
>
> Can anyone else relate?

Sure can.

He is the manager that gets upset when everything doesn't work?

He has a ambiguous requirement list?

"If he has so much time to do it over how come he doesn't have time to do it
right?"

w..

On Wed, 12 Mar 2014 12:38:50 -0400, Randy Yates wrote:

> Gentle People,
> 
> I am on an embedded firmware project that is (gasp) on a short schedule.
> The manager has decided to put testing on the back burner and simply get
> _something_ running as fast as possible without doing any testing
> further than simple checks in the debugger.
> 
> This bugs me (pun intended). I wasn't sure why; after all, the manager
> knows this is a bad idea and is clearly willing to take the risk.
> 
> I examined myself a little deeper, and I found that I don't just want to
> write/modify code, but I want to create something that is useful and
> aesthetically pleasing.
> 
> An analogy that came to my mind was that this is like "painting in the
> dark."
> 
> Can anyone else relate?

I can relate.

Unless the application is very small indeed, the "risk" becomes a 
certainty, and the only thing you do by "saving" time on debugging is to 
bog your whole project down.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com