Friday, June 29, 2007
Which theory fits the evidence?
(This essay appears in the e-book What I've Learned From Failure: A quarter-century of experience shipping software, distilled into fixnum bittersweet essays)
There are two schools of thought about the practice of managing software development (the theory of managing software development is of little use to us because “the gap between theory and practice is narrower in theory than it is in practice”).
One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.
The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.
Theory P does not mean that software development cannot be managed in such a way that the desired outcome is nearly certain: the flight of an airplane is fully probabilistic as it encounters atmospheric conditions, yet we have a huge industry built around the idea that airplanes arrive at their destinations and land on the runway as planned.
why do theory p and theory d matter?
Understanding whether software development follows the Theory D (fully deterministic) model or the Theory P (probabilistic) model helps us set our expectation for the relationship between what we plan and what transpires.
If we believe Theory D, we believe that it is possible and practical to plan software development entirely in advance. Therefore, when things do not go as planned, our first reaction is to either blame the planners for faulty planning or to blame the implementers for failing to carry out a reasonable plan. Believing in Theory D, we believe that we ought to have a plan that can be carried out to perfection.
If we believe Theory P, we believe that it is only possible and practical to plan some part of software development in advance. Therefore, when things do not go as planned, our first reaction is to embrace the new information and update our expectations. Believing in Theory P, we believe we ought to have a process for continually updating a plan that asymptotically approaches a description of reality as the project nears its conclusion.
belief drives behaviour
Our belief about which theory is true drives the way we manage software development projects in almost every way. Here are three examples: the way we manage software design, the way we manage time estimates, and the way we manage selecting people.
Theory D adherents believe you can design software in advance. They believe it is possible to collect all of the information needed about software’s requirements and the technical elements of its construction, such that you can fully specify how to build it before you start. In short, Theory D adherents believe in Big Design Up Front.
Theory P adherents believe that software can only partially be designed in advance. They believe that requirements suffer from observation, that the act of building software causes the requirements to change. Theory P adherents also believe that technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. They believe that software design is an iterative process, starting with a best guess that is continually refined with experience.
Theory D adherents believe it is possible to estimate the amount of time required to develop software (in both the large and the small) with precision. This is partly a consequence of their belief that you can know the requirements and design in advance, and therefore you can plan the activities required without uncertainty. Theory D adherents do not plan to miss milestones. Theory D adherents do not, in fact, have a process around re-estimating tasks; instead, they have a mechanism for raising exceptions when something goes wrong.
Theory D adherents believe that the normal case for software projects is that tasks are completed within the time estimated. (If extra time is required, people on Theory D projects work nights or weekends, or they cut testing time. They do this because their belief is that if a task takes too long, the fault lies with the estimate or with the worker carrying out the task, and by working overtime they can “make up for their fault.” Theory D managers often “game” their workers by “negotiating” estimates downward in a cruel game of “guess the estimate I’m think of.”)
Critical Chain is an amazing book. The narrative form—a novella detailing a technical project team and their search for a way to manage an uncertain process—is a big win, it highlights the important ways that Critical Chain Project Management handles risks and uncertainty and makes it visible where everyone can manage it.
The section on estimating tasks alone is priceless. If you can’t afford a copy and your library doesn’t stock it, borrow mine. You must read this book if you participate in software development teams.
Theory P adherents believe that there are lies, damned lies, and software development estimates. This is partly a consequence of their lack of faith that the requirements are truly fixed and that the technology is fully understood. If you don’t know what you’re doing and how you’ll do it with precision, how can you know when it will be done? Theory P adherents build processes around re-estimating estimates, such as burndown charts and time-boxed iterations.
Theory P adherents are always fussing with an updated view of how long things will take. They talk about “velocity” or “effective vs. actual programmer-hours.” Theory P adherents believe that the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.
Theory D adherents believe that the most important element of successful software development is planning. If a plan is properly constructed for the design and development of a software project, the actual implementation is virtually guaranteed. Theory D adherents invest most of their human capital in “architects” and “managers,” leaving little for “programmers.” They often have architects, senior developers, and other “valuable resources” involved in the early stages of projects and then moved to the early stage of other projects, leaving the team to implement their “vision.” They likewise believe that you can “parachute” rescuers into a troubled project. Since the plan is perfect, it is easy to jump in and be productive.
Theory D adherents believe in “architecture by proxy,” the belief that using frameworks, components, programming languages, libraries, or other golden bullets makes it possible to employ lesser talents to perform the implementation of software, since the difficult decisions have been made by the creators of the pre-packaged software. Theory D adherents also believe in “success by proxy,” the belief that using methodologies, practices, SDLCs, or other buzzwords makes it possible to employ lesser talents to perform the management of software development, since the difficult project management decisions have been made by the “thought leaders” who coined the buzzwords.
Theory P adherents believe that the most important element of successful software development is learning. They invest their human capital more evenly between implementers and architects, often blurring the lines to create a flatter technical structure and a more egalitarian decision-making environment. This is a consequence of the belief that learning is important: if you invest heavily in a few “smart” people, you have a very small learning surface exposed: there is only so much even very bright people can learn at one time. Whereas when the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information.
They strongly prefer to have the same team work a single project from start to finish, believing that when a member moves on to another project, crucial knowledge moves on with them. They likewise abhor bringing new members onto a team late in a project, believing that the new people will need experience with the project to “get up to speed.”
Theory P adherents use frameworks (especially testing frameworks), but are skeptical of claims that the framework eliminates technical risk or the need for talented contributors. Theory P adherents, even Agilists, are skeptical of methodology claims as well. They do not believe that a deck of slides and a nicely bound book can capture the work required to learn how to develop software for a particular user community in a particular environment.
Theory D and Theory P adherents are easy to distinguish by their behaviour.
so which theory fits the evidence?
Which theory fits the evidence collected in sixty years of software development?
To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.
Theory D, on the other hand, is the overwhelming winner in the marketplace, and again it’s not even close. The vast majority of software development projects are managed according to Theory D, with large, heavyweight investments in design and planning in advance, very little tolerance for deviation from the plan, and a belief that good planning can make up for poor execution by contributors.
Does Theory D reflect reality? From the perspective of effective software development, I do not believe so. However, from the perspective of organizational culture, theory D is reality, and you ignore it at your peril.
Do not confuse Computer Science—the study of the properties of computing machines—with Software Development, the employment of humans to build computing machines. The relationship between Computer Science and Software Development parallels the relationship between Engineering, the hard science of the behaviour of constructions, and Project Management, the employment of humans to construct engineered artefacts.
(A portion of this essay originally appeared in What I’ve Learned from Sales, Part II: Wanna Bet?.
Update: D is for “D’oh! We should have gone with P!” and The Myth of Project Management, a SFW retelling of Project Management is Bollocks!.
There are two schools of thought about the practice of managing software development (the theory of managing software development is of little use to us because “the gap between theory and practice is narrower in theory than it is in practice”).
One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.
The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.
Theory P does not mean that software development cannot be managed in such a way that the desired outcome is nearly certain: the flight of an airplane is fully probabilistic as it encounters atmospheric conditions, yet we have a huge industry built around the idea that airplanes arrive at their destinations and land on the runway as planned.
why do theory p and theory d matter?
Understanding whether software development follows the Theory D (fully deterministic) model or the Theory P (probabilistic) model helps us set our expectation for the relationship between what we plan and what transpires.
If we believe Theory D, we believe that it is possible and practical to plan software development entirely in advance. Therefore, when things do not go as planned, our first reaction is to either blame the planners for faulty planning or to blame the implementers for failing to carry out a reasonable plan. Believing in Theory D, we believe that we ought to have a plan that can be carried out to perfection.
Programming is not complicated because computers are complicated—it’s complicated because your requirements are complicated (even if you don’t know it yet).
If we believe Theory P, we believe that it is only possible and practical to plan some part of software development in advance. Therefore, when things do not go as planned, our first reaction is to embrace the new information and update our expectations. Believing in Theory P, we believe we ought to have a process for continually updating a plan that asymptotically approaches a description of reality as the project nears its conclusion.
belief drives behaviour
Our belief about which theory is true drives the way we manage software development projects in almost every way. Here are three examples: the way we manage software design, the way we manage time estimates, and the way we manage selecting people.
If extra time is required, people on Theory D projects work nights or weekends, or they cut testing time. They do this because their belief is that if a task takes too long, the fault lies with the estimate or with the worker carrying out the task, and by working overtime they can “make up for their fault.”
Theory D adherents believe you can design software in advance. They believe it is possible to collect all of the information needed about software’s requirements and the technical elements of its construction, such that you can fully specify how to build it before you start. In short, Theory D adherents believe in Big Design Up Front.
Theory P adherents believe that software can only partially be designed in advance. They believe that requirements suffer from observation, that the act of building software causes the requirements to change. Theory P adherents also believe that technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. They believe that software design is an iterative process, starting with a best guess that is continually refined with experience.
Theory D adherents believe it is possible to estimate the amount of time required to develop software (in both the large and the small) with precision. This is partly a consequence of their belief that you can know the requirements and design in advance, and therefore you can plan the activities required without uncertainty. Theory D adherents do not plan to miss milestones. Theory D adherents do not, in fact, have a process around re-estimating tasks; instead, they have a mechanism for raising exceptions when something goes wrong.
Theory D adherents believe that the normal case for software projects is that tasks are completed within the time estimated. (If extra time is required, people on Theory D projects work nights or weekends, or they cut testing time. They do this because their belief is that if a task takes too long, the fault lies with the estimate or with the worker carrying out the task, and by working overtime they can “make up for their fault.” Theory D managers often “game” their workers by “negotiating” estimates downward in a cruel game of “guess the estimate I’m think of.”)
Critical Chain
is an amazing book. The narrative form—a novella detailing a technical project team and their search for a way to manage an uncertain process—is a big win, it highlights the important ways that Critical Chain Project Management handles risks and uncertainty and makes it visible where everyone can manage it.The section on estimating tasks alone is priceless. If you can’t afford a copy and your library doesn’t stock it, borrow mine. You must read this book if you participate in software development teams.
Theory P adherents are always fussing with an updated view of how long things will take. They talk about “velocity” or “effective vs. actual programmer-hours.” Theory P adherents believe that the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.
Theory D adherents believe that the most important element of successful software development is planning. If a plan is properly constructed for the design and development of a software project, the actual implementation is virtually guaranteed. Theory D adherents invest most of their human capital in “architects” and “managers,” leaving little for “programmers.” They often have architects, senior developers, and other “valuable resources” involved in the early stages of projects and then moved to the early stage of other projects, leaving the team to implement their “vision.” They likewise believe that you can “parachute” rescuers into a troubled project. Since the plan is perfect, it is easy to jump in and be productive.
Theory D adherents believe in “architecture by proxy,” the belief that using frameworks, components, programming languages, libraries, or other golden bullets makes it possible to employ lesser talents to perform the implementation of software, since the difficult decisions have been made by the creators of the pre-packaged software. Theory D adherents also believe in “success by proxy,” the belief that using methodologies, practices, SDLCs, or other buzzwords makes it possible to employ lesser talents to perform the management of software development, since the difficult project management decisions have been made by the “thought leaders” who coined the buzzwords.
Theory P adherents believe that the most important element of successful software development is learning. They invest their human capital more evenly between implementers and architects, often blurring the lines to create a flatter technical structure and a more egalitarian decision-making environment. This is a consequence of the belief that learning is important: if you invest heavily in a few “smart” people, you have a very small learning surface exposed: there is only so much even very bright people can learn at one time. Whereas when the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information.
Theory P adherents believe that there are lies, damned lies, and software development estimates.
They strongly prefer to have the same team work a single project from start to finish, believing that when a member moves on to another project, crucial knowledge moves on with them. They likewise abhor bringing new members onto a team late in a project, believing that the new people will need experience with the project to “get up to speed.”
Theory P adherents use frameworks (especially testing frameworks), but are skeptical of claims that the framework eliminates technical risk or the need for talented contributors. Theory P adherents, even Agilists, are skeptical of methodology claims as well. They do not believe that a deck of slides and a nicely bound book can capture the work required to learn how to develop software for a particular user community in a particular environment.
Theory D and Theory P adherents are easy to distinguish by their behaviour.
so which theory fits the evidence?
Which theory fits the evidence collected in sixty years of software development?
To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.
Theory D, on the other hand, is the overwhelming winner in the marketplace, and again it’s not even close. The vast majority of software development projects are managed according to Theory D, with large, heavyweight investments in design and planning in advance, very little tolerance for deviation from the plan, and a belief that good planning can make up for poor execution by contributors.
Does Theory D reflect reality? From the perspective of effective software development, I do not believe so. However, from the perspective of organizational culture, theory D is reality, and you ignore it at your peril.
Do not confuse Computer Science—the study of the properties of computing machines—with Software Development, the employment of humans to build computing machines. The relationship between Computer Science and Software Development parallels the relationship between Engineering, the hard science of the behaviour of constructions, and Project Management, the employment of humans to construct engineered artefacts.
(A portion of this essay originally appeared in What I’ve Learned from Sales, Part II: Wanna Bet?.
Update: D is for “D’oh! We should have gone with P!” and The Myth of Project Management, a SFW retelling of Project Management is Bollocks!.
Comments on “Which theory fits the evidence?”:
<< Home
“the gap between theory and practice is larger in theory than it is in practice”
Shouldn't this be "larger in practice than it is in theory"?
Shouldn't this be "larger in practice than it is in theory"?
“the gap between theory and practice is larger in theory than it is in practice”
Shouldn't this be "larger in practice than it is in theory"?
No, see my fix :-)
Seriously, THANKS!
Shouldn't this be "larger in practice than it is in theory"?
No, see my fix :-)
Seriously, THANKS!
Why does theory D seem so extreme and theory P seem so benevolent?
It seems quite the fashion that you have an extremist variant of theory P who outright reject all up-front design more complex than a bar napkin and a thirty minute conversation over pints could cover.
You know - the kind who say, "Well, because waterfall has been shown to be an absolute failure, it is just stupid to do -any- kind of initial design," and who then proceed to excoriate anybody who trots out something smelling like a design or requirements doc, or heaven forbid, a budget.
Where do they fall in this spectrum?
It seems quite the fashion that you have an extremist variant of theory P who outright reject all up-front design more complex than a bar napkin and a thirty minute conversation over pints could cover.
You know - the kind who say, "Well, because waterfall has been shown to be an absolute failure, it is just stupid to do -any- kind of initial design," and who then proceed to excoriate anybody who trots out something smelling like a design or requirements doc, or heaven forbid, a budget.
Where do they fall in this spectrum?
Paul:
Theory P is more benevolent than Theory D. Humans are subject to stress when their perception of reality is out of sync with the plan and the team/organization's perception of reality. Theory P is lower in stress.
However, there are managers who believe in Theory P but practice Theory D. There are various reasons for it. One is that they believe that people perform better under pressure, so they believe that setting hard goals with consequences produces a better outcome. They know that the plan doesn't represent reality, but they pragmatically believe that falling short of an aggressive plan is superior to hitting a plan that is constantly adjusted for real-world results.
Finally, nothing in this essay suggests that Theory P people do not plan. Some use Theory P as an excuse not to plan, but a true Theory P adherent believes in planning, she just doesn't believe it is a substitute for management, discovery, and thinking during development.
The extremist you describe does not appreciate that "Planning is essential, but plans are inconsequential." Joel said it better than I could, he suggests that a huge benefit of trying to give an extremely accurate (to the hour!) estimate for a task is that you are forced to think the task through in detail, breaking it down into pieces. Should the resulting estimate be held as gospel? Both theorists can appreciate the benefit of the exercise, the difference is that the Theory P adherent says "let's see how it goes, we may make changes," while the Theory D adherent carves the result in stone.
The cocktail napkin adherent? I would say they are keenly sensitive to the flaws of Theory D but have thrown the baby out with the bath water.
Thanks for a great question.
Theory P is more benevolent than Theory D. Humans are subject to stress when their perception of reality is out of sync with the plan and the team/organization's perception of reality. Theory P is lower in stress.
However, there are managers who believe in Theory P but practice Theory D. There are various reasons for it. One is that they believe that people perform better under pressure, so they believe that setting hard goals with consequences produces a better outcome. They know that the plan doesn't represent reality, but they pragmatically believe that falling short of an aggressive plan is superior to hitting a plan that is constantly adjusted for real-world results.
Finally, nothing in this essay suggests that Theory P people do not plan. Some use Theory P as an excuse not to plan, but a true Theory P adherent believes in planning, she just doesn't believe it is a substitute for management, discovery, and thinking during development.
The extremist you describe does not appreciate that "Planning is essential, but plans are inconsequential." Joel said it better than I could, he suggests that a huge benefit of trying to give an extremely accurate (to the hour!) estimate for a task is that you are forced to think the task through in detail, breaking it down into pieces. Should the resulting estimate be held as gospel? Both theorists can appreciate the benefit of the exercise, the difference is that the Theory P adherent says "let's see how it goes, we may make changes," while the Theory D adherent carves the result in stone.
The cocktail napkin adherent? I would say they are keenly sensitive to the flaws of Theory D but have thrown the baby out with the bath water.
Thanks for a great question.
I think that the type of the project has relevance. The more "interesting" a project is (i.e the more it involves things that haven't already been done a million times) the less amenable it is to theory D type management.
But theory P still deserves more thought, in terms of how to approach it. Suppose you have an "interesting" project, and understand that this puts you into theory P territory -- is there anything you can do to manage the project well?
I propose that interesting projects are best managed with a scheme that attempts to "sketch" in enough of the system as early as possible, in order to allow investigation of the interesting things, i.e. the "question-marks". For example, maybe you need just a minimal UI and some crude middle-end, in order to allow you to investigate scalability of your DB queries, for datasets of the size you anticipate.
Of course, this is an art, rather than a science. You need enough vision (and luck) to anticipate where the real question-marks are, and some logistical skill in orchestrating the stages of development (and/or isolated investigative experiments) to allow them to be chased in succession and/or parallel, as circumstances and the issues permit.
And there's personal style to consider. Some people don't like interesting projects. Question-marks frighten them. These folks will be tempted to try to convince everyone that the project is not really that interesting, or that the interesting parts should be avoided. Bad scene. Better is to protect the team in their artful pursuit of an interesting project, while slyly convincing management that nothing interesting is happening.
Jeff
But theory P still deserves more thought, in terms of how to approach it. Suppose you have an "interesting" project, and understand that this puts you into theory P territory -- is there anything you can do to manage the project well?
I propose that interesting projects are best managed with a scheme that attempts to "sketch" in enough of the system as early as possible, in order to allow investigation of the interesting things, i.e. the "question-marks". For example, maybe you need just a minimal UI and some crude middle-end, in order to allow you to investigate scalability of your DB queries, for datasets of the size you anticipate.
Of course, this is an art, rather than a science. You need enough vision (and luck) to anticipate where the real question-marks are, and some logistical skill in orchestrating the stages of development (and/or isolated investigative experiments) to allow them to be chased in succession and/or parallel, as circumstances and the issues permit.
And there's personal style to consider. Some people don't like interesting projects. Question-marks frighten them. These folks will be tempted to try to convince everyone that the project is not really that interesting, or that the interesting parts should be avoided. Bad scene. Better is to protect the team in their artful pursuit of an interesting project, while slyly convincing management that nothing interesting is happening.
Jeff
# posted by 
: 9:24 PM
: 9:24 PM
Hi Reg,
Very insightful post. And a great site overall; I really enjoy reading your essays.
But there's a passage in this post that I'm not very sure if I understand it correctly: "This is a consequence of the belief that learning is important: if you invest heavily in a few “smart” people, you have a very small learning surface exposed: there is only so much even very bright people can learn at one time. Whereas when the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information."
Do you mean that a team which has a few smart people is not as conducive to learning as team of people who are not as smart but who "meet a certain standard for competence"?
What method would you use to determine this "standard of competence" in a particular case? And would the presence of some "philosopher kings" be more beneficial than a truly (read naively) democratic assemblage of just "good enough" people? (I'm thinking of some well know OSS projects with BDFL's in them.)
I know that you put "smart" in quotes. But let's consider a particular case where you have to manage a team of varying intellectual capacities, and you don't have much power to really change this circumstance (because of the corporate structure or the current conditions of the labour market or zillions other reasons). In this not so rare (in fact quite popular) case, would it be beneficial to appoint some "architects" (who you know are certainly smarter than the rest) to ensure conceptual integrity?
Nhu-Tung
Very insightful post. And a great site overall; I really enjoy reading your essays.
But there's a passage in this post that I'm not very sure if I understand it correctly: "This is a consequence of the belief that learning is important: if you invest heavily in a few “smart” people, you have a very small learning surface exposed: there is only so much even very bright people can learn at one time. Whereas when the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information."
Do you mean that a team which has a few smart people is not as conducive to learning as team of people who are not as smart but who "meet a certain standard for competence"?
What method would you use to determine this "standard of competence" in a particular case? And would the presence of some "philosopher kings" be more beneficial than a truly (read naively) democratic assemblage of just "good enough" people? (I'm thinking of some well know OSS projects with BDFL's in them.)
I know that you put "smart" in quotes. But let's consider a particular case where you have to manage a team of varying intellectual capacities, and you don't have much power to really change this circumstance (because of the corporate structure or the current conditions of the labour market or zillions other reasons). In this not so rare (in fact quite popular) case, would it be beneficial to appoint some "architects" (who you know are certainly smarter than the rest) to ensure conceptual integrity?
Nhu-Tung
# posted by : 4:10 AM
: 4:10 AM
Great post. The end leaves a major question hanging. This is a clear contradiction. Why is it that theory D is so successful (at replicating itself if nothing else) while theory P languishes (at replicating)? Perhaps D offers clear benefits to its adherents within large organizations -- status, power, large reporting trees... and thus P can't gain a foothold despite offering clear organization-level benefits.
-- more here
-- more here
John:
Why is it that theory D is so successful (at replicating itself if nothing else) while theory P languishes (at replicating)? Perhaps D offers clear benefits to its adherents within large organizations -- status, power, large reporting trees... and thus P can't gain a foothold despite offering clear organization-level benefits.
Observing large organizations it is rarely clear that what is best for the organization "wins." I doubt very much this is restricted to software development.
Thanks very much for your follow-up. Part of my take on Theory D's popularity is tucked into this lament :-)
Why is it that theory D is so successful (at replicating itself if nothing else) while theory P languishes (at replicating)? Perhaps D offers clear benefits to its adherents within large organizations -- status, power, large reporting trees... and thus P can't gain a foothold despite offering clear organization-level benefits.
Observing large organizations it is rarely clear that what is best for the organization "wins." I doubt very much this is restricted to software development.
Thanks very much for your follow-up. Part of my take on Theory D's popularity is tucked into this lament :-)
Someone else has their own definition of Theory P:
Programmers fancy themselves as free-spirited individuals who resist discipline like a mustang resists the bit for the first time. But it must be done. A little discipline, organization and accountability can go a long way.
Programmers fancy themselves as free-spirited individuals who resist discipline like a mustang resists the bit for the first time. But it must be done. A little discipline, organization and accountability can go a long way.
Jaaron:
Thanks, that was priceless.
Actually, he sounds a lot like a Theory D person. Witness his description of what a programmer does: translating human-understandable specifications into machine understandable instructions.
Likewise, in the comments, he emphasizes an approach to planning that is typical of Theory D: Under our approach, I would review the specs with the programmer, let him make an estimate of the amount of time necessary to complete the task, then calculate the schedule..
I would say Mr. Bryce's choice of Theory P predates mine, so if anyone should change, it should be me, but very clearly we are not talking about the same thing.
Thanks, that was priceless.
Actually, he sounds a lot like a Theory D person. Witness his description of what a programmer does: translating human-understandable specifications into machine understandable instructions.
Likewise, in the comments, he emphasizes an approach to planning that is typical of Theory D: Under our approach, I would review the specs with the programmer, let him make an estimate of the amount of time necessary to complete the task, then calculate the schedule..
I would say Mr. Bryce's choice of Theory P predates mine, so if anyone should change, it should be me, but very clearly we are not talking about the same thing.
Isn't there also a theory N (non-deterministic) that is quite similar to theory P, except that it does not depend on the duration of tasks having a more or less predictable probability distribution.
In practice, we do not have to assume that tasks have a probability distribution for us to break tasks down as small as possible, bound our work with time boxes, and manage the resulting progress empirically.
In practice, we do not have to assume that tasks have a probability distribution for us to break tasks down as small as possible, bound our work with time boxes, and manage the resulting progress empirically.
Steven:
Does Theory "N" assume known requirements?
There is an argument that the activity of implementing hard specifications has low variance from estimates, but that there is a lot of uncertainty around requirements, leading to an overall "Theory P" behaviour, even though the technology/implementation risk is low.
You might get something like this on a project to build a static web site for someone. The actual work is almost completely deterministic, but the client keeps changing their mind about what they want!
Does Theory "N" assume known requirements?
There is an argument that the activity of implementing hard specifications has low variance from estimates, but that there is a lot of uncertainty around requirements, leading to an overall "Theory P" behaviour, even though the technology/implementation risk is low.
You might get something like this on a project to build a static web site for someone. The actual work is almost completely deterministic, but the client keeps changing their mind about what they want!
I think D "wins" historically because of simple survivor bias. D companies, I'd imagine, are "D all the way down." When anyone gets too crazy, the beancounters, financial forecasters, and strategic planners show up to end the party. The result might be failed products, but also companies that tend overall to survive. Furthermore, most failed D products are not company-killers. Ford survived the Edsel; Apple survived the Newton (and will survive the iPhone, I bet). Gigli didn't sink the studio; they just went and made another movie, fast.
Meanwhile, the P startup blazes up and flares out, since its rock 'n' roll dev attitude is often paired with a rock 'n' roll financial attitude, assuming it's thought about this at all. No one really notices, so no one takes this mountain of failure into consideration.
Meanwhile, the P startup blazes up and flares out, since its rock 'n' roll dev attitude is often paired with a rock 'n' roll financial attitude, assuming it's thought about this at all. No one really notices, so no one takes this mountain of failure into consideration.
TDW:
I don't think we are talking about the same things at all.
There is nothing about Theory P that suggests "Rock and Roll." I suggest you spend some time looking at the level of intellectual rigour behind Eliyahu Goldratt's work on project management.
Or perhaps have a look at what people are doing with Monte Carlo simulations and Risk Management. For example, Intaver makes software products for managing projects with risks and uncertainties.
I think, in the end, that there are people who jump into projects with little discipline and experience. Some of those people are Theory P people, but some are also Theory D people: they concoct worthless plans in advance and insist that everyone follow them whether they succeed or not.
You can tell the "Rock and Roll Theory D" people: they're the ones saying that all they need is a "surge" and to "stay the course."
So... in summary... yes of course there are Rock and Rollers. But they come in both Theory D and Theory P flavours.
And there are the disciplined project managers. And again, they come in both Theory D and Theory P flavours.
I don't think we are talking about the same things at all.
There is nothing about Theory P that suggests "Rock and Roll." I suggest you spend some time looking at the level of intellectual rigour behind Eliyahu Goldratt's work on project management.
Or perhaps have a look at what people are doing with Monte Carlo simulations and Risk Management. For example, Intaver makes software products for managing projects with risks and uncertainties.
I think, in the end, that there are people who jump into projects with little discipline and experience. Some of those people are Theory P people, but some are also Theory D people: they concoct worthless plans in advance and insist that everyone follow them whether they succeed or not.
You can tell the "Rock and Roll Theory D" people: they're the ones saying that all they need is a "surge" and to "stay the course."
So... in summary... yes of course there are Rock and Rollers. But they come in both Theory D and Theory P flavours.
And there are the disciplined project managers. And again, they come in both Theory D and Theory P flavours.
I think there's a simpler explanation for the pre-eminence of Theory D in most organisations - it's the model that best fits the customer's expectations.
Most software development is carried out for some customer who brings their (half-formed) requirements, pays for the effort and wants working software out the other end. Their natural expectations are that before committing to a piece of expenditure they want to know a) how much it will cost; b) how long will it take; and c) can I hold you to that? In fact, corporate governance typical demands these things.
So, as much as a project manager might have a vague inkling that his day job doesn't feel exactly deterministic, he feels pressured by his customer to present the process as being deterministic because that's the only way he knows of to arrive at the right answers to these three questions.
The alternative is to educate the customer on the real nature of software development, but typically this is not a battle that an individual project manager feels like fighting.
Most software development is carried out for some customer who brings their (half-formed) requirements, pays for the effort and wants working software out the other end. Their natural expectations are that before committing to a piece of expenditure they want to know a) how much it will cost; b) how long will it take; and c) can I hold you to that? In fact, corporate governance typical demands these things.
So, as much as a project manager might have a vague inkling that his day job doesn't feel exactly deterministic, he feels pressured by his customer to present the process as being deterministic because that's the only way he knows of to arrive at the right answers to these three questions.
The alternative is to educate the customer on the real nature of software development, but typically this is not a battle that an individual project manager feels like fighting.
"Theory P is more benevolent than Theory D. Humans are subject to stress when their perception of reality is out of sync with the plan and the team/organization's perception of reality. Theory P is lower in stress."
Of course Theory P is lower in stress, for the programmer, since it imposes on him far less responsibility than Theory D. But Theory P is far MORE stressful for stakeholders, since the responsibility of dealing with the shifting timetables that result from Theory P have been shifted onto them.
Of course, then, Theory P is the more desirable theory from the perspective of the programmer. But that doesn't mean that it is the right theory. The needs of ALL of the parties to the project must be taken into account, and thus, elements of Theory D (i.e. some amount of upfront planning and, yes, some overtime if the plan is not being met) are required in the real world.
Of course Theory P is lower in stress, for the programmer, since it imposes on him far less responsibility than Theory D. But Theory P is far MORE stressful for stakeholders, since the responsibility of dealing with the shifting timetables that result from Theory P have been shifted onto them.
Of course, then, Theory P is the more desirable theory from the perspective of the programmer. But that doesn't mean that it is the right theory. The needs of ALL of the parties to the project must be taken into account, and thus, elements of Theory D (i.e. some amount of upfront planning and, yes, some overtime if the plan is not being met) are required in the real world.
David:
I am a stateholder in my current role. I find Theory D very stressful because I know that a plan out of touch with reality means I am not getting the information I need to make decisions.
You have also made two small errors in your assumptions. Nothing about Theory P precludes some or even a lot of upfront planning. It merely suggests that as information is gathered, the plan is kept in sync with what the team discovers about reality. The other small error is assuming that the team is composed solely of programmers. Stakeholders are also part of the team.
I am a stateholder in my current role. I find Theory D very stressful because I know that a plan out of touch with reality means I am not getting the information I need to make decisions.
You have also made two small errors in your assumptions. Nothing about Theory P precludes some or even a lot of upfront planning. It merely suggests that as information is gathered, the plan is kept in sync with what the team discovers about reality. The other small error is assuming that the team is composed solely of programmers. Stakeholders are also part of the team.
"Joel said it better than I could, he suggests that a huge benefit of trying to give an extremely accurate (to the hour!) estimate for a task is that you are forced to think the task through in detail, breaking it down into pieces."
Exactly. There are certain actions (such as writing comments in advance of writing the code; i.e. comment-driven development) that, by their nature, make you think differently (or, in some cases, simply think). It's sort of a trick; you strive for certain artifacts (comments, estimations, whatever) but they're not quite the real goal.
The immediate results may be expendable, but the meta-results (so to speak) are what have the longer value.
Exactly. There are certain actions (such as writing comments in advance of writing the code; i.e. comment-driven development) that, by their nature, make you think differently (or, in some cases, simply think). It's sort of a trick; you strive for certain artifacts (comments, estimations, whatever) but they're not quite the real goal.
The immediate results may be expendable, but the meta-results (so to speak) are what have the longer value.
you strive for certain artifacts (comments, estimations, whatever) but they're not quite the real goal.
Of course! And the Theory P person embraces this. But the Theory D person believes they are the real goal.
Do not be fooled into thinking that Theory D people plan and Theory P people do not plan, that Theory D people estimate and Theory P people do not estimate.
If anything, Theory P folks do more planning and more estimating, because they believe in constantly refining their plans and estimates as new evidence is collected. Whereas Theory D folks believe you can do it all up front and put it in a glass case :-)
Of course! And the Theory P person embraces this. But the Theory D person believes they are the real goal.
Do not be fooled into thinking that Theory D people plan and Theory P people do not plan, that Theory D people estimate and Theory P people do not estimate.
If anything, Theory P folks do more planning and more estimating, because they believe in constantly refining their plans and estimates as new evidence is collected. Whereas Theory D folks believe you can do it all up front and put it in a glass case :-)
There's one obvious reason why Theory D works best in the market and Theory P best in the community:
Theory D has a hidden message of accepting full responsibility. The guy/team/company that practices D says to all stakeholders they are in charge. If things get ugly they'll obviously be the one to blame so they actually function as risk magnets.
Theory P has a hidden message of sharing responsibility. Since software is undeterministic in many ways it requires team work and shared responsibility to overcome unexpected issues. Sharing knowledge, coaching, motivation all play key roles. For the people on the project it's a more attractive proposition. However, the same team is unlikely to accept full responsibility in case things go wrong. They believe they and the customer are on the same ship.
P is obviously problematic in the market since it requires customers to look into the practices of teams to assure they're being as efficient as they can be. This obviously posses a problem since this kind of oversight would put at least part of the responsibility for optimal efficiency of the software development team with the customer. If they don't do oversight customers basically have to trust the team to make the best out of it.
P says to customers: it's your software, you are the one that takes the risk, we will take some of the risk but in case things go wrong and we go over time and budget we will leave it up to you to figure it out.
Agile blabla tries to address the economic problems with P but I doubt many people fully understand that the real purpose of agile blabla is to make P look more attractive.
Theory D has a hidden message of accepting full responsibility. The guy/team/company that practices D says to all stakeholders they are in charge. If things get ugly they'll obviously be the one to blame so they actually function as risk magnets.
Theory P has a hidden message of sharing responsibility. Since software is undeterministic in many ways it requires team work and shared responsibility to overcome unexpected issues. Sharing knowledge, coaching, motivation all play key roles. For the people on the project it's a more attractive proposition. However, the same team is unlikely to accept full responsibility in case things go wrong. They believe they and the customer are on the same ship.
P is obviously problematic in the market since it requires customers to look into the practices of teams to assure they're being as efficient as they can be. This obviously posses a problem since this kind of oversight would put at least part of the responsibility for optimal efficiency of the software development team with the customer. If they don't do oversight customers basically have to trust the team to make the best out of it.
P says to customers: it's your software, you are the one that takes the risk, we will take some of the risk but in case things go wrong and we go over time and budget we will leave it up to you to figure it out.
Agile blabla tries to address the economic problems with P but I doubt many people fully understand that the real purpose of agile blabla is to make P look more attractive.
# posted by : 11:24 AM
: 11:24 AM
Here we go again.
I hired someone to do the major construction on a pond. For a deal like this, there is very little uncertainty, it is appropriate to fix requirements, date, and cost in advance if I don't want the right to make changes during the project.
While digging the pond, he discovered a concrete slab buried under my garden. Seriously (it was from a garage that had been torn down decades ago).
So what was supposed to happen? Do I say, "Hey!! Theory D!!! Stick to the schedule!!!"
We can argue about what the law says about the negotiated price, but human laws and agreements cannot override the laws of Space and Time: it was not physically possible to complete the project on the original schedule once we had to deal with the extra labour, the renting of the appropriate equipment, and the scheduling of bins to carry away the concrete debris.
So please, Theory D sounds great for customers, it sounds like we move risk onto the development team. But that is all blah-blah-blah when we run into something unforeseen, because the team does not have the power to alter the laws of space and time.
Maker up your mind: either projects can be planned with precision or they can't. If they can't, pretending that they can and pushing risk around is simply playing games.
I hired someone to do the major construction on a pond. For a deal like this, there is very little uncertainty, it is appropriate to fix requirements, date, and cost in advance if I don't want the right to make changes during the project.
While digging the pond, he discovered a concrete slab buried under my garden. Seriously (it was from a garage that had been torn down decades ago).
So what was supposed to happen? Do I say, "Hey!! Theory D!!! Stick to the schedule!!!"
We can argue about what the law says about the negotiated price, but human laws and agreements cannot override the laws of Space and Time: it was not physically possible to complete the project on the original schedule once we had to deal with the extra labour, the renting of the appropriate equipment, and the scheduling of bins to carry away the concrete debris.
So please, Theory D sounds great for customers, it sounds like we move risk onto the development team. But that is all blah-blah-blah when we run into something unforeseen, because the team does not have the power to alter the laws of space and time.
Maker up your mind: either projects can be planned with precision or they can't. If they can't, pretending that they can and pushing risk around is simply playing games.
This whole "Theory D vs. Theory P" thing reminds me of the old "creationism vs. evolution" debate: Theory D, as you've described it, is like creationism, in the sense that it's *non-falsifiable*. You said it yourself: if a software project managed under Theory D fails, it is because the big, up-front plan was imperfect. Moreover, such a failure *in no way* reflects upon Theory D as a mental model for how software development works.
I submit that given this, Theory D is not, in fact, a theory of software development at all (by way of Kuhn's notion of a scientific theory as something which is potentially falsifiable). Logically, then, there really is no dichotomy between Theory D and Theory P, since Theory D is not a valid theory. Emotionally, however, since Theory D promises a sense of security, managers and customers may tend to latch onto it, rather like how creationism appeals to religious folks who care not to examine the evidence contained in the world around them.
(My apologies for bringing up creationism vs. evolution, but it simply is the best analogy I could think of to illustrate the point I wanted to make.)
I submit that given this, Theory D is not, in fact, a theory of software development at all (by way of Kuhn's notion of a scientific theory as something which is potentially falsifiable). Logically, then, there really is no dichotomy between Theory D and Theory P, since Theory D is not a valid theory. Emotionally, however, since Theory D promises a sense of security, managers and customers may tend to latch onto it, rather like how creationism appeals to religious folks who care not to examine the evidence contained in the world around them.
(My apologies for bringing up creationism vs. evolution, but it simply is the best analogy I could think of to illustrate the point I wanted to make.)
How did you measure who the winner in the marketplace is? I wonder if theory D looks as good when your yardstick is the ratio of total money made by all projects to total money spent on all projects.
Sure, there are more theory D projects, and they make more money overall. But there are also more failures, and more total money spent on them.
Sure, there are more theory D projects, and they make more money overall. But there are also more failures, and more total money spent on them.
<< Home
