Martin Fowler Quotes

If you're afraid to change something it is clearly poorly designed.

So I hope I've made clear that imposing agile methods is a very red flag.

Now I'm a pretty lazy person and am prepared to work quite hard in order to avoid work.

One of the big dangers is to pretend that you can follow a predictable process when you can't.

Comprehensiveness is the enemy of comprehensibility.

Never in the annals of software engineering was so much owed by so many to so few lines of code

I can't choose whether someone is offended by my actions. I can choose whether I care.

If someone were to come up to you in a dark alley and say, "Psst, wanna see a UML diagram?" that
diagram would probably be a class diagram.

Poorly designed code usually takes more code to do the same things, often because the code quite literally does the same thing in several places.

Other than when you are very close to a deadline, however, you should not put off refactoring because you haven't got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring.

Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.

If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose.

When to use iterative development? You should use iterative development only on projects that you want to succeed.

In almost all cases, I'm opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.

When you actually sit down to write some code, you learn things that you didn't get from thinking about them in modeling terms ... there is a feedback process there that you can only really get at from executing some things and seeing what works

I find that writing unit tests actually increases my programming speed

When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

Comparing to another activity is useful if it helps you formulate questions, it's dangerous when you use it to justify answers.

It is impossible not to notice Ruby on Rails. It has had a huge effect both in
and outside the Ruby community ... Rails has become a standard to which even
well-established tools are comparing themselves to.

I've learned to always avoid saying "always".