[AccessD] Software Quality

Oohh, a topic that approaches TDD. Fascinating. I'm curious to hear everyones opinion on this, because its an issue that typically divides developers and often in ways that show that its not entirely clear to some developers (albeit, not understanding the fundamental concepts and tenants of...) what the benefits are (to themselves as much as to the project).

Hans



On 2012-08-08, at 1:55 AM, Salakhetdinov Shamil wrote:

> Hi Ken --
> 
> <<< * All of us have level 5 code -- we just don't know about it yet! However,
> if we find a bug, but can't fix it at the moment, we should at least
> document it and turn it into level 4.>>>
> 
> Yes, 5D is usually acceptable. 
> There is no *practically achievable* ways to turn any software at level 4C I suppose.
> I mean any released software we have done(/seen working somehow at customers' computers) have parts at levels 1-5, and 6-7, and even/often 8.
> The quality of released software will be the higher the less will be the probability to get issues at levels 5-7.
> 
> The following quote is from "Code Simplicity" (http://www.codesimplicity.com/)
> "Law: The Law of Testing: The degree to which you know how your software behaves
> is the degree to which you have accurately tested it.
> Rule: Unless you’ve tried it, you don’t know that it works."
> 
> Thank you.
> -- Shamil 
> Tue, 7 Aug 2012 20:58:17 -0500 от Kenneth Ismert <kismert at gmail.com>:
> 
> 
> 
> Here are some thoughts on software quality. What do you think?
> 
> 
> Code Quality: 1=Best, 9=Worst
> ------------------------------
> 1) Works, formal tests
> 2) Works, informal tests
> 3) Works, vetted but no tests
> 4) Fails in known, documented ways
> 5) Fails in unknown or undocumented circumstances
> 6) Fails by changing global state in a way that causes downstream failure
> of level 7 and 8 code
> 7) Fails by making assumptions about global state that are violated by code
> in level 6
> 8) Indeterminate, too complex, disorganized, or entangled to do any real
> vetting or testing
> 9) Unknown, first revision, untested
> 
> 
> Behavior on Error: A=Best, F=Worst
> -----------------------------------
> A) Fails immediately and unambiguously, and logs error
> B) Fails immediately and unambiguously
> C) Fails ambiguously
> D) Silently fails -- program terminates
> E) Silently fails and continues
> F) Silently fails and continues, causing downstream error
> 
> 
> Comments
> -------------
>  * Obviously, we should all strive for 1A code, but few mortals produce
> exclusively at that level.
>  * In the real world, writing code even down to level 4C can be acceptable.
>  * All of us have level 5 code -- we just don't know about it yet! However,
> if we find a bug, but can't fix it at the moment, we should at least
> document it and turn it into level 4.
> 
> And now, the bad levels:
>  * 6, 7 and 8 all require code refactoring to fix
>  * Note that 7 is worse than 6. If you must sin, sin boldly, but don't be
> naive about the state of your program
>  * 8 is by far the most work, both to produce and fix
>  * All code starts at 9, but a quick step-through and some critical
> re-reading can take it to level 3 -- at least until we find out it is a 5!
> 
> And the bad error behavior:
>  * C can often be fixed by adding more specific error information, or
> adding error handling code to routines that lack them
>  * D, E and F are all serious, and should be addressed when encountered
>  * People who write code at level 8 tend to rely on error levels E and F to
> try to hide their wrongdoing
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com