Do your projects follow Wright’s Law?
Everyone in a technical field is familiar with Moore’s Law, which is the empirical observation that semiconductor technology doubles every 18 months with corresponding decreases in cost and increases in functionality and performance. Most engineers and product managers wish that their industries and technology projects, including their software projects, followed a similar rule. In fact, there is a similar rule for other industries and projects, called Wright’s Law.
Wright’s Law, also called the Rule of Experience, was discovered by Theodore P. Wright and described in the paper, “Factors affecting the cost of airplanes” in the 1936 Journal of Aeronautical Sciences. The simple form of the law is “we learn by doing” and the cost of each unit produced decreases as a function of the cumulative number of units produced. Moore’s Law for the semiconductor industry is really just a special case of Wright’s Law. The semiconductor industry’s phenomenal efficiency improvements are therefore due, in part, to the explosive growth in the use of semiconductor technologies in all areas of modern life.
Recent analysis of technology advancement in 62 industries by the Santa Fe Institute discovered that Wright’s Law is a good predictor of improvements in multiple industries, including aircraft production, beer manufacturing, energy production, specialty chemical manufacturing, metal production, and refined sugar production. In fact the “experience curve,” the graph of unit cost versus cumulative units produced, seems to apply to any technology where you can learn and improve with increased production. Any plant with a process improvement, six-sigma, or lean manufacturing program is probably following Wright’s Law.
It is reasonable to ask if Wright’s Law also applies to the software industry and software projects. In software the units produced should be the units developed, not the units sold. Software duplication and distribution costs are minuscule compared to the development costs, so the important criteria for software-intensive projects are the efficiency and experience of the development team.
Wright’s law demonstrates that building a second unit, which is the same as the first, provides an experience benefit. But very few software projects are exactly the same as a previous project. The only situation where this normally occurs is in a software factory, where a company basically delivers the same software, with minor customization, to multiple customers. In these situations a software factory can achieve high efficiency and low cost, as often happens in outsourced business application development. But, if you ask the software factory to develop something custom, you should not expect the same high productivity.
Most manufacturing software projects are not executed in a software factory environment. Our software projects are usually one of a kind, with only a limited ability to completely reuse a previous project’s specifications, requirements, designs, and code. However, not is all lost; there is a way to use the experience curve to your advantage if you organize your teams and projects to take advantage of experience in specialized areas. The experience curve can apply to specific individuals when they repetitively use the same tools and methodologies on different projects. Most engineers and programs will learn by doing; as they become more familiar with languages, such as C++, Java, structured text, ladder logic, or sequential function charts, they become more productive. Eventually these productivity gains will decrease as they achieve mastery of the subject. The same gains in productivity should occur with additional experience in vendor product lines and development methodologies. However, these gains will happen only if you allow your project team to become masters of the tools and methods. Formal software effort estimating methods, such as the COCMO models, have a heavy weighting factor based on experience in the same problem area, technology, or methodology. Any team member who is continually dealing with new languages and technologies will become, as the saying goes, “a jack of all trades, and master of none.” The simple rule is to not expect that experience in one technology or problem space will help in other areas. The less directly applicable experience you have, the lower your productivity will be. The best approach is to learn from mistakes and success in specific technologies and methodologies, and apply those in novel projects to gain the advantage of the experience curve.
You will have to balance the productivity gains from the experience curve against what I would call the “motivation curve.” The simple form of the motivation curve is that “we are motivated by improvements” and that our motivation to do a good job will decrease as the job becomes repetitive and boring with no opportunity for improvements. The management form of this law is “don’t pigeonhole someone because he can do one job very well.” Good management techniques and personal development plans will balance the experience curve and the motivation curve for each individual, so that we gain the advantage of experience in our tools and methodologies while also maintaining motivation to do a good job.
Wright’s law, with its proven mathematical formula, gives us an unimpeachable reason to try to maximize reuse of technologies and methodologies in software projects, and to organize to build technology expertise. The motivation curve also warns against pigeonholing individuals into specific areas with no chance for improvements. Balancing these two competing forces will allow your software projects to follow Wright’s Law and also maintain a motivated workforce.
 Wright TP, (1936). “Factors affecting the costs of airplanes.” Journal of Aeronautical Sciences 10: 302-328.
 Nagy B, Farmer JD, Bui QM, Trancik JE (2012). “Statistical Basis for Predicting Technology Progress,” Santa Fe Institute working paper
– Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at firstname.lastname@example.org. Edited by Mark T. Hoske, content manager CFE Media, Control Engineering.