Showing posts with label simplicity. Show all posts
Showing posts with label simplicity. Show all posts

Friday, May 16, 2014

Agile in a Flash 42

The Seven Code Virtues The Code
Agile in a Flash by Jeff Langr and Tim Ottinger (card #42)

> Working, as opposed to incomplete
> Unique, as opposed to duplicated
> Simple, as opposed to complicated
> Clear, as opposed to puzzling
> Easy, as opposed to difficult
> Developed, as opposed to primitive
> Brief, as opposed to chatty
--

Working, as opposed to incomplete. A program that works is superior to one that might work later. TDD requires code to work early and often.
Unique, as opposed to duplicated. Many regression errors are the result of improvements to only one version of copied code. Eliminate duplication in TDD’s refactoring step.
Simple, as opposed to complicated. Simple code hides fewer bugs and tends to optimize well.
Clear, as opposed to puzzling. Code misunderstandings generate errors. Use Card 43, Really Meaningful Names, and simple structures to make such errors unlikely.
Easy, as opposed to difficult. Structure and organize code so that it is easy to use. Don’t hesitate to add convenience methods and classes.
Developed, as opposed to primitive. Prefer the clarification and encapsulation of abstract data types to built-in variable types. Primitive obsession muddles the code and can create maintenance nightmares.
Brief, as opposed to chatty. Code should be brief but never cryptic. All other virtues still observed, less code is always better than more.


"Complicated code is infinitely more difficult to maintain and debug than simple code.” 

Tuesday, May 13, 2014

Agile in a Flash 41

Build Superior Systems with Simple Design The Code
Agile in a Flash by Jeff Langr and Tim Ottinger (card #41)

> All tests must pass
> No code is duplicated
> Code is self-explanatory
> No superfluous parts exist

--

As far as a prescriptive set of design principles go, these four rules(11) of simple design, listed in order of importance, are the simplest thing that might possibly work.

> Code must work and be demonstrated by passing tests. A great paper model of a design is useless if the software doesn’t work. Use TDD so that you know the code is working at all times.
> Removing duplication is the next most important design activity, because it directly lowers the cost of system maintenance and drives you toward an appropriate level of abstraction.
> Contrary to popular belief, it’s almost always possible to create code that others can understand and maintain—particularly if your TDD-created tests clearly document intended behavior. Maintenance costs rise dramatically with unclear code.
> Finally, YAGNI (You Aren’t Going To Need It) tells us to remove all superfluous features and complexity—anything not needed at this precise moment.

11. Extreme Programming Explained, First Edition

"A simple design always takes less time to finish than a complex one."
- extremeprogramming.org

"A man should look for what is, and not for what he thinks should be."
Albert Einstein