Posted by Robert Merrill on November 22, 2008 under Uncategorized | 
The “Software Factory” metaphor has been around for a long time–at least 20 years. Now I see it’s become associated with an award-winning book and a Microsoft methodology. It’s no wonder that the Software Factory metaphor is attractive to buyers of software. It calls to mind predictability and low cost.
But what if it’s wrong?
Metaphors create clarity–that longed-for A-HA! Bad metaphors create the illusion of clarity, and cause people, especially managers and executives, to charge ahead, heedless of warning signs, until there’s undeniable trouble. The author of the metaphor may understand the limitations and subtleties, but those get lost, especially when the metaphor is really attractive.
The Software Factory produces software. This metaphor leads to an inward, process-and-cost focus.
Now, predictability-and-low-cost is the Holy Grail of software development, and ever since Fred Brooks, people have been on a quest for the Holy Grail with a gun full of Silver Bullets. People have always longed for the Software Factory, and maybe it’s finally arrived in the book by Greenfield, Short, Kent, and Crupi. (I admit, I haven’t read the book yet.)
Or maybe the predictability and low cost associated with software are really here, already, and we’re just not appreciating them. It’s only natural that we think of the fruit of our own labors, especially if it’s tangible, as The Product. We make software, so software must be the product. But is it?
Drill Bit–or Hole Factory?
Consider drill bits. The last time I bought a drill bit, I didn’t really need a drill bit. What I needed was a hole of a certain size that my hole factory–my trusty Black and Decker–could not produce. So I retooled my factory–literally–and then I could make 9/16 inch holes with abandon, at low unit cost and with a lot more precision than with a mallet and a chisel.
The Software-As-Factory produces a user experience. This metaphor leads to an outward, experience-and-value focus.
Now consider software. People buy this product, but they don’t put it on the wall to admire it. They don’t eat or otherwise consume it. They use it to accomplish or experience something. They use it over and over, as they use tools of other kinds, or as a company uses a factory. Garbage goes in, and altered garbage comes out, but quickly and (usually) predictably. Sometimes it lets them do things they already could, only faster and with fewer errors. And it lets people do things that weren’t even possible before, or that were prohibitively expensive and time-consuming without computers. We’re surrounded by low-cost, predictable information access and experiences. Low-cost, predictable things come from factories–in this case, from computers controlled by software.
What if the Software IS the Factory?
A Tale of Two Metaphors
Consider where these two metaphors lead us.
The Software Factory produces software. This metaphor leads to an inward, process-and-cost focus.
The Software-As-Factory produces a user experience. This metaphor leads to an outward, experience-and-value focus.
Now, it isn’t that the Software Factory can’t produce high-value software that creates great user experiences. It’s just that it tends to lump those concerns in with factory-floor concerns about getting the product–the software–out the door, at minimum cost. Usability and value become second-order attributes of the product.
The Software-As-Factory metaphor separates concerns more cleanly. We want to produce a valuable and delightful user experience–the end product–reliably and at low cost, and for that, we need a factory. Maybe we can retool an existing factory, or maybe we will need to build a new one. Will there be just one factory–a hosted application–or will there be many locally-operated factories–a shrink-wrap application? Does the factory produce a single product, or a variety? If a variety, the factory itself might be complex to operate and require special skill and training.
Notice that the Software-As-Factory metaphor encourages us to see past the increasingly artificial business-technology divide. There are people who use the products of factories–the user experiences–as is. Some of them learn to retool the factory to produce a short run of a customized experience for the use of a smaller number of end customers. Think of the office Excel whiz. Finally, there are the people who design and build factories–professional, full-time software developers. Maybe they are the Industrial Engineers of the information-technology world.
Product Manufacturing versus Product Development
Under the Software-As-Factory metaphor, software development is more like product development than product manufacturing. This is not my idea. Mary Poppendieck quotes Kosaku Yamada, Chief Engineer of Toyota’s Lexus line, “The real difference between Toyota and other vehicle manufacturers is not the Toyota Production System, it is the Toyota Product Development System.” In other words, the Toyota advantage isn’t that they run great factories (though they do). It’s that they conceive of great products, and implement the factories to make them, better than anyone else. Mary Poppendieck also cites 3M (where she spent a good portion of her career) as another example of product development excellence.
Now I’m fired up to go learn more about the Toyota Product Development System and how that relates to the Software-As-Factory metaphor. I also need to read Software Factories because it is well reviewed and I’m sure I will learn a lot from it.
But the idea of a software productivity breakthrough, as opposed to a welcome yet still incremental improvement, through software development tools? Not if the software is the factory and not the product. Call me skeptical.
Posted by Robert Merrill on under Uncategorized |
(I wrote this in March 2008, but since I went all WordPress, all the time, I had to recreate it as a blog post).
Here we go again. The high-flyers are belly-flopping, and the rest of us get soaked. It’s recession time.
Whether out of necessity or knee-jerk reaction, a lot of software-intensive businesses are going to be letting software contractors and employees go in an effort to cut costs.
Cost-Cutting
The direct effect, obvious to everyone, will be downward pressure on hourly rates and salaries for software professionals. If the tech crash of the early “oughties” is any indication, larger consumers of software resources are going to use the opportunity to lock in lower rates with their vendors and hold firm on raises for their employees. They’ll benefit from the savings due to reduced headcount, plus slightly lower unit costs. They’ll reduce capacity, put a few more projects on hold, and work everyone else a little harder. Belt-tightening and cost-cutting—that’s the obvious response of the software-intensive business to the recession.
“The quiet opportunity of the recession will be on the productivity side of the equation…”
The indirect effect, however, will be a richer talent pool. It’s just my perception, but unlike the 90’s boom, salaries haven’t skyrocketed in the 00’s, and software professionals have tended to stay put rather than trading up.Out of panic or necessity, some companies will break up some truly fine software teams. Some of those people will now be on the market. Hence, the opportunity.
Good People
Good people tend to attract good people and form good teams, and good teams are more productive. Software productivity is harder to measure than cost, but it’s also a lot more variable. The difference in productivity between a weak team and a strong one is at least two to one especially on small to medium projects. And productivity—the cost to produce an “ounce” of software—is only half the story. More effective software organizations also produce more useful software per ounce—fewer features that never get used, and more features that really help the business—through the better governance, better user involvement, and better processes that tend to follow good people.
If your software-intensive firm has the means, a recession is a great time to strengthen your software-development capability through thoughtful recruiting.
I’ve heard it said that out of chaos comes opportunity. For the software-intensive business, the quiet opportunity of the recession will be on the productivity side of the equation, not the cost side.
Posted by Robert Merrill on under Estimation |
In Recession: A Quiet Opportunity for your Software-Intensive Business, I suggested that the productivity gains from improving your team far outweigh the cost savings possible in a buyer’s market for talent.
Just how variable is programmer productivity, anyhow?
Person-to-person and same-person variability
If you give a group of people the same programming project, how long does it take them? How much does an individual’s productivity vary from task to task?
As Sherwood (2006) says clearly, “I have found it surprisingly hard to find good academic literature that measures productivity.” She quotes the following ranges:
- 28:1 best to worst (Sherwood 2006a, citing Sackman et al. 1968)
- 22:1 to 8:1 best to worst for two problems, depending on how you treat the outliers (Sherwood 2006a, citing Curtis 1981)
- 3:1 to 2:1 best to median for two problems (Sherwood 2006a, based on Curtis 1981 data)
- 4:1 to 2:1 best to median (Sherwood 2007, citing DeMarco and Lister 1985. The latter also found that productivity was correlated with the organization that programmers came from, even though they worked independently during the study).
- 2:1 best to worst (Sherwood 2006b, citing Ko et al. 1996)
Spolsky (2006) quotes another range:
10:1 to 5:1 best to worst (Spolsky 2000, based on several years of student project data from a computer science professor at Yale)
Project to project variability
My own project metrics over a period of about five years show:
- 20:1 best to worst project productivity (largely the same people, in different teams, using different technologies to implement various web application projects. Some were all-custom, and others were customization of commercial or open source software).
- 3:1 difference between productivity on two projects completed by the same developer using the same technology
The COCOMO II estimation model (Chulani et al. 1997) has adjustment factors for total project effort based on personnel attributes by role:
- 2.25:1 best to worst analyst
- 1.85:1 best to worst programmer
- 1.5:1 most to least familiarity with the application domain
- 1.5:1 most to least familiarity with the technology in use
Interpretation
There is a lot of variability. No wonder estimation is difficult. Here are some principles about productivity from the above.
- Productivity probably varies within a given organization by at least 2:1
- Individual productivity varies from task to task, probably by an equal amount of 2:1
- A team is more than the sum of its parts. Analysts have the highest leverage; analyst capability swings productivity by over a factor of two, even though they directly contribute maybe one-fourth the effort (my rule of thumb).
- Project productivity, based on individual capability, team capability, familiarity with the domain and the technology, and the technology in use, easily varies by 10:1.
References
Chulani, S., B. Clark, and B. Boehm 1997: Calibration results of COCOMO II.1997. 22nd Annual Software Engineering Workshop, NASA Goddard Space Flight Center.
Curtis, B 1981: Substantiating programmer variability. Proceedings of the IEEE, 69, 846. ISSN 0018-9219.
DeMarco, Tom and Tim Lister 1985: Programmer performance and the effects of the workplace. International Conference on Software Engineering, 268-272. ISBN 0-8186-0620-7.
Ko, A., Myers, B. A, Coblenz, M. J. and H. H Aung 2006: An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks. IEEE Transactions on Software Engineering, 32, 971-987.
McConnell, Steve 2006: Software Estimation: Demystifying the Black Art. Microsoft Press, 308 pp. ISBN 0-7356-0535-0.
Sackman, H., W. J. Erickson and E. E. Grant 1968: Exploratory experimental studies comparing online and offline programming performance. Communications of the ACM, 11, 3-11. ISSN 0001-0782.
Sherwood, Kaitlin Duck 2006a: Don’t get stuck, a review of Sackman and Curtis. http://www.webfoot.com/blog/2006/12/07/programmer-productivity/.
Sherwood, Kaitlin Duck 2006b: Review of Ko’s “An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks.” http://www.webfoot.com/blog/2006/12/15/programmer-productivity-part-2/.
Sherwood, Kaitlin Duck 2007: Review of “DeMarco and Lister’s Programmer performance and the effect of the workplace.” http://www.webfoot.com/blog/2007/02/16/demarco-and-lister/.
Spolsky, Joel 2000: Hitting the High Notes. http://www.joelonsoftware.com/articles/HighNotes.html