Martin Fowler Quotes

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

Martin Fowler

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

Martin Fowler

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

Martin Fowler

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

Martin Fowler

#5. A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.

Martin Fowler

#6. 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.

Martin Fowler

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

Martin Fowler

#8. Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

#9. 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.

Martin Fowler

#10. A pattern is an idea that has been useful in one practical context and will probably be useful in others.

Martin Fowler

#11. I can only think of so many good ideas in a week. Having other people contribute makes my life easier.

Martin Fowler

#12. Why is composing symphonies tough? I don't know. It's just very few people in the world can do it well. And I think that's the case with upfront design. It is very hard to do well.

Martin Fowler

#13. Parallel inheritance hierarchies is really a special case of shotgun surgery. In this case, every time you make a subclass of one class, you also have to make a subclass of another.

Martin Fowler

#14. I find that writing unit tests actually increases my programming speed

Martin Fowler

#15. Comprehensiveness is the enemy of comprehensibility.

Martin Fowler

#16. 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.

Martin Fowler

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

Martin Fowler

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

Martin Fowler

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

Martin Fowler

#20. 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

Martin Fowler

#21. 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.

Martin Fowler

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

Martin Fowler

#23. If you're a technical lead, you need to be coding.

Martin Fowler

#24. One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is avoid duplication. "Once and only once" is the Extreme Programming phrase.

Martin Fowler

#25. 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.

Martin Fowler

#26. 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.

Martin Fowler

#27. The biggest issue on software teams is making sure everyone understands what everyone else is doing.

Martin Fowler

#28. ... parts of classic MVC don't really make sense for rich clients these days.

Martin Fowler