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. :-)
Reference
Experts, Craftsman, and Ignorance by Dave Hoover
Related Post
Every 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
Brooks on Good Judgement
|
|
Good judgement comes from experience, and experience comes from bad judgement.
--Frederick P. Brooks
|
Tate on Developers
|
|
You can be a good developer by studying successful patterns and best practices, but if you want to become a great developer, you've got to know a technology's limits.
--Bruce Tate
in preface of BitterEJB, 2003
|
Monnox on Software Engineer
|
|
A software engineer understands that self-improvement and continous learning are fundemental activities for an IT professional.
--Alan Monnox
in preface of Rapid J2EE Development, 2005
|
McConnell on Code Documentation
|
|
Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer.
--Steve C McConnell
|
Fowler on Good Code
|
|
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
--Martin Fowler
|
Holub on Simplicity
|
|
Simple systems are easier to build, easier to maintain, smaller, and faster than complex ones. ... Simplicity is often not an easy goal to achieve. Programmers love complexity, so they have a strong tendency to over complicate their work. It's often easier to quickly build an overly complex system than it is to spend the time required to make the system simple.
--Allen Holub
in his recent book, Holub on Patterns, 2004
|
Ambler on Best Programmers
|
|
... best programmers think through the design of their code before they actually write it.
--Scott W. Ambler
|
Booch on Software-Eng
|
|
Solid software engineering practices never go out of style (crisp abstractions, clear separation of concerns, balanced distribution of responsibilties)
--Grady Booch
great software architect in recent post.
|
Stas Kubasek on Learning New Technologies
|
|
I don't skate where the puck is, I always skate where the puck is going to be
--Wayne Gretzky
the best hockey player.
|
How about that? That's a great quote!
On a similar note, here is my approach on learning new technologies:
|
|
I don't learn technologies that are popular today, I learn technologies that are going to be popular and widely used in the future.
--Stas Kubasek
|
What does that mean? That means I always want to stay ahead of the game. I think that's a pretty good strategy for the future. Strategy to be successful. We'll see. :-)
Booch on Software
|
|
every advance requires software that has not yet been written...
--Grady Booch
in ADT Interview
|
That's exactly right, I think. That's why I would not proclaim software industry dead. As long as there's going to be innovation, there's going to be a need for software. So maybe the software-engineer's future doesn't look so bleak after all? I think so. I think once the IT industry recovers, it will be a whole lot better. And like Grady says, "there's still a lot of exciting stuff we'll get to do in the coming years."
McConnell on Diet vs Development
|
|
If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better.
--Steve McConnell
|
Software Engineering Principles
This is a pretty good quote by Steve McConnell, one of my favorite software authors (he's an author of Code Complete, see Books I Recommend), about software engineering and its value to a developer. I could not agree more with Steve.
|
|
An investment in learning software engineering principles is a particular good investment for a software professional to make because that knowledge will last a whole career溶ot be half obsolete within three years.
As a software development professional, you need knowledge of specific technologies to do your job. But you need knowledge of software engineering principles to do your job well. A continuing pursuit of such knowledge is one mark of a true professional.
--Steve Mc Connell
in IEEE Software, March 1999
|
Kreitzberg and Shneiderman on Programming vs Cryptography
|
|
Programming can be fun, so can cryptography; however, they should not be combined.
--Kreitzberg and Shneiderman
|
Mills on Bugs
|
|
Programs do not acquire bugs as people acquire germs, by hanging around other buggy programs. Programmers must insert them.
--Harlan Mills
|
Fairley on Tragedy of Software Eng
|
|
The tragedy of software engineering is not that we don't know how to plan and conduct software projects, but that we know how and just don't do it.
--Richard E. Fairley
|