The Pragmatic Craftsman :: Simplicity from complexity ::

Archive for the 'Quotes' Category

Quote: Grady Booch on Simple Architecture June 28th, 2007
Einstein on Complexity May 2nd, 2007
Dijkstra on Simplicity August 4th, 2006
A Simple Design May 3rd, 2006
Martin on Bad Design March 29th, 2006
Constant Change — Beck February 24th, 2006
Do It Right — Wooden December 1st, 2005
Larman and Fowler on Critical OO Ability November 16th, 2005
Hoover on Craftsmen November 3rd, 2005
Spolsky on Writing Specs August 18th, 2005

Quote: Grady Booch on Simple Architecture

The best software designs look simple, but it takes a lot of hard work to design a simple architecture.
–Grady Booch
in OOAD with Applications

Einstein on Complexity

Any fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.
–Albert Einstein

Dijkstra on Simplicity

Simplicity is prerequisite for reliability.
–Edsger W. Dijkstra
1930-2002, Dutch Computer Scientist

A Simple Design

Simplicity always wins, in my opinion. The following two quotes from Programming Pearls (book I’m reading now) need no further comment: they nail it.

A designer knows he has arrived at perfection not when there is no longer anything to add, but wen there is no longer anything to take away.
–Antoine de Saint-Exupery
the French writer and aircraft designer (quoted in Programming Pearls)
More programmers should judge their work by this criterion. Simple programs are usally more reliable, secure, robust and efficient than their complex cousins, and easier to build and maintain.
–Jon Bentley
in Programming Pearls

Martin on Bad Design

When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable.
–Robert C. Martin
discussing The Open-Closed Principle

Constant Change — Beck

[Programming] There is no such thing as straight and level. Even if things seem to be going perfectly, you don’t take your eyes off the road. Change is the only constant. Always be prepared to move a little this way, a little that way. Sometimes maybe you have to move in a completely different direction. That’s life as a programmer.

Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.

–Kent Beck
in Extreme Programming Explained

Do It Right — Wooden

If you don稚 have time to do it right, when will you have time to do it over?
–John Wooden
basketball coach

This is true in sports, but especially true when developing software. Ask yourself that question constantly and you’ll do a better job.

Larman and Fowler on Critical OO Ability

A critical ability in OO development is to skillfully assign responsibilities to software objects
–Craig Larman
author, Applying UML and Patterns

Can’t agree more with Larman. To be a good OO developer, to truly understand what object oriented means, you’ve got to treat classes as objects with responsibilities, and be knowledgeable on how to assign them. Larman’s book is classic in this category.

Here’s what Martin Fowler had to say on the subject.

Understanding responsibilities is key to good object-oriented design.
–Martin Fowler
quoted in Applying UML and Patterns

Hoover on Craftsmen

The critical distinction between a craftsman and an expert is what happens after a sufficient level of expertise has been achieved. The expert will do everything she can to remain wedded to a single context, narrowing the scope of her learning, her practice, and her projects. The craftsman has the courage and humility to set aside her expertise and pick up an unfamiliar technology or learn a new domain.
–Dave Hoover
in article on StickyMinds.com

This is a great definition of a software craftsman: the best I found so far. The article by Dave Hoover on StickyMinds.com is a very good one, link below. Especially if you want to find out who a craftsman really is.

What can you learn from this? Be humble. Be curious. Be eager to learn new technologies. And be lazy. :-)

ReferenceExperts, Craftsman, and Ignorance by Dave Hoover

Related PostEvery Craftsman is Dump and Lazy

Spolsky on Writing Specs

The reason you write a spec is not to solve every possible problem in advance: the reason you write a spec is to solve as many problems as you possibly can in advance so that you minimize the number of surprises that come up during development.
–Joel Spolsky
- talking about Copilot.com spec

Reference:Blog entry about The Project Aardvark Spec by Joel Spolsky

Related:The original spec (pdf) by Joel Spolsky

Random Quote

Topics

Tags

Archive

Recent Entries

Currently Reading

Shelfari: Book reviews on your book blog

:: The Pragmatic Craftsman recommends

:: The Pragmatic Craftsman book reviews

Info

© 2001-2010 Stanley Kubasek About me :: Contact me

@PragCraftsman on Twitter

SOLID principles come in handy here. Especially, "Open of Extension, Closed for Modification." One of the best principles I've learned. - 22 hours agoI actually try to follow @unclebobmartin's rule all the time. Sort of. I try not to make it worse. But to make it better? Great challenge! - 22 hours agoAlways check a module in cleaner than when you checked it out (via @unclebobmartin in 97 Things Every Progr.). I love the idea! - 22 hours agoI put Code Complete #1 over Martin's book because it has "awaken" me as a programmer. But other than that, Martin's book is the best! - 1 day ago