Re: Opinions please : You can't (shouldn't) fix Stupid, remove the Stupid first and then see if you still have a problem.

Paul Comeau <[email protected]> Wed, 27 Oct 2010 21:02:28 -0500
Newsgroups gmane.comp.programming.language-of-the-year
Message-ID <[email protected]>
Lol - sounds like the last project I was on. I agree "don't fix Stupid, remove Stupid"!


Pc

Sent from my iPad

On Oct 27, 2010, at 19:42, John Carter <[email protected]> wrote:

> So I was assigned a critical issue to fix... Something was failing to meet it's real time deadline.
> 
> 
> So I, obeying the principle of "Measure First, then guess", I plugged in a bit of profiling code (hey this is in a very very tightly resource constrained embedded device)... an lo and behold the most major consumer of CPU and resources was a facility that doesn't (cannot possibly) exist within this particular model.
> 
> Ie. The presence of this facility is just plain stupid.
> 
> Is it the cause of the issue?
> 
> Dunno, don't care. My working principle is don't fix Stupid, remove Stupid and then see if you still have a problem... If you still have a problem fix that without all the Stupid clouding the picture.
> 
> Now I'm aware that this deviates from more cautious types who would say, prove first that the Stupid is causing a problem before you attack it.
> 
> My practice has always been, can't stand stupid, makes things complicated, muddies the picture, if I see stupid The Big Cutting Tools come out and Stupid goes and swims with the fishies.
> 
> Then I go back to being cautious.
> 
> 
> 
> 
> -- 
> John Carter                             Phone : (64)(3) 358 6639
> Tait Electronics                        Fax   : (64)(3) 359 4632
> PO Box 1645 Christchurch                Email : [email protected]
> New Zealand
> 
> 
> =======================================================================
> This email, including any attachments, is only for the intended
> addressee.  It is subject to copyright, is confidential and may be
> the subject of legal or other privilege, none of which is waived or
> lost by reason of this transmission.
> If the receiver is not the intended addressee, please accept our
> apologies, notify us by return, delete all copies and perform no
> other act on the email.
> Unfortunately, we cannot warrant that the email has not been
> altered or corrupted during transmission.
> =======================================================================
> 
>