"Agile software development is about iteration not oscillation"
Jim Highsmith (paraphrased), Agile 2009

"Perhaps the worst software technology of all time was the use of physical lines of code [for metrics]. Continued use of this approach, in the author’s opinion, should be considered professional malpractice."
Capers Jones, Applied Software Measurement

"Deliver frequent, tangible, working results"
Peter Coad

"Kanban is the science of not trying to do too much at once"
Stephen Palmer, 2012

"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,

"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley

"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill

"If you can't explain it simply, you don't understand it well enough."
Albert Einstein

"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin

"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain

"chaos often results when a project's complexity is greater than its managers' ability to direct meaningful progress toward a goal."
Ken Schwaber, Agile Project Management with Scrum, 2004

"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"The complexity of software is an essential property, not an accidental one. ... Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size."
Frederick P. Brooks, The Mythical Man-Month, 1995

"When people are factored in, nothing is simple. The complexity of individuals and individuals working in teams raises the noise level for all projects."
Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, 2002

"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum

"I guess that as you go along you try to fill your tool-box, so that when you face these circumstances you have more options to choose from"
Jonny Wilkinson, Tom Fordyce's Blog, 2009

"Speech is conveniently located midway between thought and action, where it often substitutes for both."
John Andrew Holmes

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"
Glenford Myers (via jJeff De Luca)

"Information Technology is 80% psychology and 20% technology "
Jeff De Luca, www.nebulon.com

Notes on waterfall-style processes.

So-called waterfall processes and structured methods first became popular in the 1970's and dominated the industry throughout 1980's. The 1990's saw waterfall processes lose their dominance to formal use-case and object-oriented analysis and design approaches epitomized by the Unified Process framework. Then, at the turn of the century a wave of self-styled agile approaches including Scrum, eXtreme Programming (XP), and Feature-Driven Development (FDD) to software development appeared and rapidly grew in popularity.

Despite this, numerous software development organizations still follow waterfall-style processes today.

Waterfall processes are characterized by well-defined phases and quality checkpoints or gateways.

Unfortunately, waterfall processes regularly exhibit a number of problems. Defining all of the requirements precisely at the start of the project often proves considerably harder than originally envisaged. Plans are adjusted and design is reported to senior management and the customer as starting late. As a result, design is often hurried to reduce the impact on the start date of coding. Nevertheless, coding is still reported as taking signifcantly later than planned. The end result is that the time planned for testing is significantly reduced to make the new promised deploy date that is already much later than originally committed to.

Waterfall Reality

The real picture is often much worse than the reported picture. Although design starts, requirements work is typically still continuing as designers immediately start to find omissions, ambiguities, and inconsistencies in the requirements documents. This problem is quite frequently compounded by requirements and designs still being reworked and refined when programmers start coding. Changes to requirements and design after coding has started cause unplanned delays and reworking of code. The end result is that coding needs to continue well into testing, further reducing the effectiveness of that testing.

Another side-effect of all this is that, once the initial requirements are finally signed off, the project has no opportunity to accommodate non-trivial changes to those requirements without jeopardizing the deployment date. The project's change management process, effectively becomes a change minimization process. In addition, the project team have little opportunity to significantly improve the way they do things because each major activity is done only once and lessons learned are either forgotten or not applicable on the next project.

The lack of effective testing, the need for hastily performed rework, and long hours put in to finish coding on time typically mean the delivered software has far more defects than it should. The lack of opportunity to make non-trivial changes to requirements often means the delivered software does not meet the actual needs of the customer.

While all types of software development can fall foul of these problems, they seem to be more acutely felt on enterprise software systems where business requirements are typically harder to define and subject to more frequent change than the requirements for industrial or embedded software, for example.

Follow me on Twitter...