"What's the simplest thing that could possibly work?" -- Ward Cunningham
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation, object-oriented or otherwise." -- Ward Cunningham
"Over and over, people try to design systems that make tomorrow's work easy. But when tomorrow comes it turns out they didn't quite understand tomorrow's work, and they actually made it harder." -- Ward Cunningham
"Each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem." -- Ward Cunningham
"The shortest path to exceeding expectations doesn't generally pass through meeting expectations. -- Ward Cunningham
"When you get in situations where you cannot afford to make a mistake, it's very hard to do the right thing. So if you're trying to do the right thing, the right thing might be to eliminate the cost of making a mistake rather than try to guess what's right." -- Ward Cunningham
"I can't tell you how much time is spent worrying about decisions that don't matter. To just be able to make a decision and see what happens is tremendously empowering, but that means you have to set up the situation such that when something does go wrong, you can fix it." -- Ward Cunningham
"I don't claim to be a methodologist, but I act like one only because I do methodology to protect myself from crazy methodologists." -- Ward Cunningham
When a manager asks for hard data, that's usually just his way of saying no." -- Ward Cunningham
"There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped." -- Ward Cunningham
"I'm not a great programmer; I'm just a good programmer with great habits." -- Kent Beck
"Make it work. Make it right. Make it fast." -- Kent Beck
"If testing costs more than non-testing, then don't test." -- Kent Beck
How good the design is doesn't matter near as much as whether the design is getting better or worse. If it is getting better, day by day, I can live with it forever. If it is getting worse, I will die." --Kent Beck
"Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, How would I develop if it were my money? I'm amazed how many theoretical arguments evaporate when faced with this question." -- Kent Beck
"I tell people to start implementing when they are pretty sure there aren't more important stories out there. An iteration's worth of data is worth months of speculation." -- Kent Beck"
"Learning research tells us that the time lag from experiment to feedback is critical." -- Kent Beck
"The system metaphor is a story that everyone--customers, programmers, and managers--can tell about how the system works." -- Kent Beck
"Responsible Development shares many practices with XP but the roots are different. Responsible Development's values are honesty, transparency, accountability and responsibility. These lead me to pairing, test-first, incremental design, continuous integration and so on because they support the values." -- Kent Beck
"Simple, not easy. There's a difference."
"Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK?" -- Ron Jeffries
"It seems to me to be important to distinguish a good idea from poor implementations of it." -- Ron Jeffries
"The lesson is: Even if you know exactly what is going on in you system, measure performance, don't speculate. You'll learn something, and nine times out of ten, it won't be that you were right!!" -- Ron Jeffries
"One of the great skills in using any language is knowing what not to use, what not to say. There's that simplicity thing again."
"When we use a language, we should commit ourselves to knowing it, being able to read it, and writing it idiomatically." -- Ron Jeffries
"Any fool can write software that computers understand. Good programmers write code that humans can understand." -- Martin Fowler
"If you're a technical lead, you need to be coding."
"The biggest issue on software teams is making sure everyone understands what everyone else is doing." -- Martin Fowler
"When to use iterative development? You should use iterative development only on projects that you want to succeed." -- Martin Fowler
"Comrehensiveness is the enemy of the comprehensibility." - Martin Fowler
"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
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." -- Martin Fowler
"A pattern is an idea that has been useful in one practical context and will probably be useful in others." -- Martin Fowler
"I find that writing unit tests actually increases my programming speed." -- Martin Fowler
"So I hope I’ve made clear that imposing agile methods is a very red flag." -- Martin Fowler
"One of the big dangers is to pretend that you can follow a predictable process when you can't." -- Martin Fowler
"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
"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
"Comparing to another activity is useful if it helps you formulate questions, it's dangerous when you use it to justify answers." -- Martin Fowler
"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
"The hardest single part of building a software system is deciding precisely what to build." -- Fred Brooks
"The most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they have almost never thought of the problem in the detail that must be specified." -- Fred Brooks
"How does a project get to be a year behind schedule? One day at a time." -- Fred Brooks
"Software work is the most complex that humanity has ever undertaken." -- Fred Brooks
"The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification." -- Fred Brooks
"The bearing of a child takes nine months, no matter how many women are assigned." -- Fred Brooks
"Improving your process won't move you from good to great design. It'll move you from bad to average." -- Fred Brooks
"Successful software always gets changed." -- Fred Brooks
"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned." -- Fred Brooks
"I am more convinced than ever. Conceptual integrity is central to product quality." -- Fred Brooks
"Conceptual integrity is the most important consideration in system design." -- Fred Brooks
"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks
"Well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you - if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers - the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think." -- Fred Brooks"Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them."
"The critical thing about the design process is to identify your scarcest resource. Despite what you may think, that very often is not money. For example, in a NASA moon shot, money is abundant but lightness is scarce; every ounce of weight requires tons of material below. On the design of a beach vacation home, the limitation may be your ocean-front footage. You have to make sure your whole team understands what scarce resource you're optimizing." -- Fred Brooks
"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence." -- Fred Brooks
"There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity." -- Fred Brooks
"Mediocre design provably wastes the world's resources, corrupts the environment, affects international competitiveness. Design is important." -- Fred Brooks
"The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. Hence plan to throw one away; you will, anyhow." -- Fred Brooks
"It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers" -- Fred Brooks
"Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program." -- Fred Brooks
"The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built." -- Fred Brooks
"The Waterfall Model is wrong and harmful; we must outgrow it." -- Fred Brooks
"Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude." -- Fred Brooks
"Plan to throw one (implementation) away; you will, anyhow." -- Fred Brooks
"Continuous improvement is better than delayed perfection" -- Mark Twain
"Scrum is supposed to be fast, easy, and fun. If it's slow, hard, and painful, you're doing it wrong."-- Jeff Sutherland
"Any Scrum without working product at the end of a sprint is a failed Scrum." -- Jeff Sutherland
"Greatness can’t be imposed; it has to come from within. But it does live within all of us." -- Jeff Sutherland
"The fact is, when you look at the best teams—like the ones that existed at Toyota or 3M when Takeuchi or Nonaka wrote their paper, or the ones at Google or Salesforce.com or Amazon today—there isn’t this separation of roles." -- Jeff Sutherland
"The primary driver of project success is time to make a decision. ... This difference is bigger than any difference between any methodology whether waterfall or agile." -- Jeff Sutherland
"The primary driver of project success is time to make a decision. If the average time is an hour or less, project success is 68% in the Standish database. If decision time averages five hours or more, success rate drops to 18%. This difference is bigger than any difference between any methodology whether waterfall or agile. Scrum drives most decisions down to self-organizing automous teams where it takes 10 mintes or less to make a typical decision. It creates strong Product Owners that own priorities who work closely with teams so that decisions can be turned around in less than an hour if they involve priorities. A properly implemented Scrum@Scale has an Exective Action Team with a Scrum daily meeting that can turn corporate decisions around in a few hours." -- Jeff Sutherland
"Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse." -- Michael Feathers
"Programming is the art of doing one thing at a time" -- Michael Feathers
"To me, legacy code is simply code without tests." -- Michael Feathers
"Encapsulation is important, but the reason why it is important is more important. Encapsulation helps us reason about our code." -- Michael Feathers
"As the amount of code in a project grows, it gradually surpasses understanding. The amount of time it takes to figure out what to change just keeps increasing." -- Michael Feathers
"The most subtle bugs that we can inject are bugs related to inheritance." -- Michael Feathers
"The brutal truth is that architecture is too important to be left exclusively to a few people. It’s fine to have an architect, but the key way to keep an architecture intact is to make sure that everyone on the team knows what it is and has a stake in it." -- Michael Feathers
"The best TDD can do, is assure that code does what the programmer thinks it should do. That is pretty good BTW." -- James Grenning