FUNDAMENTAL RULES
OF SOFTWARE PRODUCTIVITY
(1) In the end, the only things that matter are running tested features. [1] [2]
(2) Start by defining completion, “Begin with the end in mind.” [3]
(3) Always ensure you are working on the most important thing. [4]
(4) Finish what you start, minimize work in progress. [5] [6]
(5) Tolerate no defects; fix them as you find them. [7]
(6) Refactor only for clear reason, otherwise leave well enough alone. [8]
(7) When you do refactor, do it right so you don’t introduce errors or unnecessary complexity. Improve the code you touch. Fix, don’t patch. [9]
(8) Avoid anticipatory development. Solve the problem at hand. Make YAGNI your mantra. [10] [11]
(9) Sharpen the saw. Commit to continual learning. Master your tools. Know when to ask for
help. [12] [13]
[1] Ron Jefferies. “Running, Tested, Features.” 11/16/08. http://www.xprogramming.com/xpmag/jatRtsMetric.htm.
Ron Jeffries, one of the original signers of the Agile Manifesto and a primary industry thought leader, states the only metric that matters—and a metric difficult to game—is running, tested features:
· Running means that the features are shipped in a single integrated product.
· Tested means that the features are continuously passing tests provided by the requirements givers—the customers in XP parlance.
· Features mean real end-user features, pieces of the customer-given requirements, not artifacts or tasks like "Install the Database" or "Get Web Server Running".
[2] Bertrand Meyer. Object Oriented Software Construction. Prentice Hall.1988. ISBN 0-13-629049-3. Chaper 1 – Aspects of software quality
Bertrand Meyer gave a classic defense and justification of object-oriented programming in his 1988 book, Object Oriented Software Construction. In his very first chapter he confronts software quality, which he defines in terms of (1) Correctness; (2) The ability to function under abnormal circumstances; and (3) Extendibility, reusability, and compatibility.
Bertrand emphasizes, however, that these are all “internal” factors, hidden and unseen from users, and that the only qualities that really matter are those perceived by users and owners which include “external” factors such as reliability, ease of use, feature richness, performance, etc. In the end, Bertrand emphasizes, the only thing that matters are the external factors. We only care about internal quality to the extent it delivers external quality.
[3] Stephan Covey. The 7 Habits of Highly Effective People. Free Press Division of Simon and Schuster. 1989. ISBN 0-7432-6951-9.
Know your purpose. Know what is included in the work, and equally important, what is excluded. In what form should work product be delivered (what platform, language, style, standard, etc., etc.)? What are the due dates? Are there design constraints? What resources are available or excluded?
“To begin with the end in mind means to start with a clear understanding of your destination. It means to know where you’re going so that you better understand where you are now and so that the steps you take are always in the right direction.”
By defining the problem, you establish criteria against which all your effort can be measured. You ensure all your efforts are directed toward what the customer most values, and none of your effort is misdirected or discarded.
[4] Ibid.
Let’s face it, projects end when we run out of time or we run out of money. By always working on the most valuable thing, we ensure that when we are compelled to ship, as much of the most valuable work as possible has been completed and only work of lesser value remains.
It is about priorities. We never complete all the proposed features, but we can strive to get the most valuable done first.
[5] Mike Cohen. Agile Estimating and Planning. Prentice Hall. 2005. ISBN 0131479415.
Only completed work has value. Work in progress has none. A car with 3 tires and no engine cannot be driven, but a car with 4 tires can at least be towed.
[6] Mary Poppendieck. “Workflow is Orthogonal to Scheduling.” Presentation at Agile 2009, Chicago, IL, 08/24/09. Widely respected, Mary has a background in operations analysis and always, “Brings fresh perspectives to the world of software development.” Specifically, she has applied queuing theory to software development that gives sound mathematical support to the benefits of minimizing WIP.
[7] Steve McGuire. Debugging the Development Process. Microsoft Press. 1994. ISBN 1556156502.
Continuously shippable product. Zero defects.
[8] Martin Fowler. Refactoring; Improving the Design of Existing Code. Addison-Wesley. 1999. ISBN 0201485672.
Refactoring is a term that means different things to different people. Martin Fowler, however, offers a widely accepted and precise definition of the term:
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
Touch everything you need, but only what you need. Improve the code you touch.
[9] McGuire, Debugging the Development Process. Apply the Boy Scout rule: Leave it better than you find it.
[10] Neal Ford. The Productive Programmer; First Edition. O’Reilly. 2008. ISBN 978-0-596-51978-0; Chapter 9.
Software naturally becomes more complex with time. We don’t need to arbitrarily contribute by coding for circumstances that may never arise.
When we try to anticipate future currently unspecified needs or feature, we are trading work on features we know we need today, for future features we may never want.
[11] Will Tracz. Confessions of a Used Program Salesman; Institutionalizing Software Reuse. Addison-Wesley. 1995. ISBN 0-201-63369-8.
Truly reusable code is a chimera and very expensive and difficult to achieve. Ordinarily, well-structured and well-crafted code that permits extension is sufficient for production software.
[12] Covey, Seven Habits.
[13] Ford. The Productive Programmer.
When you choose to be a programmer, you step on an ever ascending and accelerating escalator. As a guide, devote 10% of your time (4 hours per week) to learning your craft. Master the tools in your environment. Memorize those keyboard shortcuts. Steve McGuire at Microsoft expected his developers to learn a significant new programming skill every two months.
Include life skills. Learn how to write a crisp e-mail, a concise status report, a persuasive memo. Discover how to run an efficient meeting and delight your colleagues. Join Toastmasters and become comfortable speaking in front of large groups. Practice leadership by running a user group. Master time management.
As of 09/02/08 / Agile_Programming_Fundamental_Rules_of_Software_Productivity_012.doc / Page 2 of 4