Finding the remote
Category process
In a recent dicussion with a client, we stumbled upon an analogy for resource allocation in software development. We had been musing about the role that technology plays in the delicate balance between laziness and efficiency, and the conversation drifted to the concept of the remote control. I mentioned the oft-discussed irony of a willingness to spend several minutes locating a misplaced remote rather than simply walking to the device (TV, DVD, etc.) and pressing the button. "But," he responded, "once I've found the remote, I've solved the problem; if I keep getting up to push the button, I'm just treating the symptom over and over."
That took us directly to a discussion of requirements management, and the tendency for many organizations to focus on symptoms rather than root cause. It's typically quicker to fix the result of a software bug than to fix the bug itself. More specifically, when an entire application, framework, or platform fails to adequately meet the needs of its users, it can often be difficult to convince the stakeholders to invest the time, effort, and/or money to overhaul or even replace it with something that will. Instead, they choose to live with - and, in many cases, constantly patch - the inefficient tool that they already have despite the time, effort, and money that is wasted by the shortcomings of the tool. They keep "getting up to push a button" (for example, manually fixing incorrect data) instead of "finding the remote" (dedicating a resource for a few days to determine what's causing the data to be incorrect). Put another way, they keep taking the car into the shop long after it would have been cheaper to just buy a new car.
I'm reminded again of my philosophy concering a distinction between "good lazy" and "bad lazy". More to the point, it strikes me as a distinction between short-term priorities and long-term investment. "A stitch in time saves nine", so to speak.
How do you sell stakeholders on this distinction? One of the luxuries of my current position is that I rarely have to: by the time I'm involved in the process, I'm typically interacting with folks already open to suggestion on how best to obtain value from the services we provide. That helps to facilitate discussions on which changes to an application would best improve performance; which template/element inheritance hierarchy would best improve maintainability; which additional Lotus software offerings would most empower their user community. While our recommendations may not always be accepted, the nature of being the "outside help" is that someone has already decided that an investment now may pay off later. But I'm curious: for those of you who have to make this case "from the inside", what arguments have you found to be most effective?
(cross-posted at BleedYellow)
In a recent dicussion with a client, we stumbled upon an analogy for resource allocation in software development. We had been musing about the role that technology plays in the delicate balance between laziness and efficiency, and the conversation drifted to the concept of the remote control. I mentioned the oft-discussed irony of a willingness to spend several minutes locating a misplaced remote rather than simply walking to the device (TV, DVD, etc.) and pressing the button. "But," he responded, "once I've found the remote, I've solved the problem; if I keep getting up to push the button, I'm just treating the symptom over and over."
That took us directly to a discussion of requirements management, and the tendency for many organizations to focus on symptoms rather than root cause. It's typically quicker to fix the result of a software bug than to fix the bug itself. More specifically, when an entire application, framework, or platform fails to adequately meet the needs of its users, it can often be difficult to convince the stakeholders to invest the time, effort, and/or money to overhaul or even replace it with something that will. Instead, they choose to live with - and, in many cases, constantly patch - the inefficient tool that they already have despite the time, effort, and money that is wasted by the shortcomings of the tool. They keep "getting up to push a button" (for example, manually fixing incorrect data) instead of "finding the remote" (dedicating a resource for a few days to determine what's causing the data to be incorrect). Put another way, they keep taking the car into the shop long after it would have been cheaper to just buy a new car.
I'm reminded again of my philosophy concering a distinction between "good lazy" and "bad lazy". More to the point, it strikes me as a distinction between short-term priorities and long-term investment. "A stitch in time saves nine", so to speak.
How do you sell stakeholders on this distinction? One of the luxuries of my current position is that I rarely have to: by the time I'm involved in the process, I'm typically interacting with folks already open to suggestion on how best to obtain value from the services we provide. That helps to facilitate discussions on which changes to an application would best improve performance; which template/element inheritance hierarchy would best improve maintainability; which additional Lotus software offerings would most empower their user community. While our recommendations may not always be accepted, the nature of being the "outside help" is that someone has already decided that an investment now may pay off later. But I'm curious: for those of you who have to make this case "from the inside", what arguments have you found to be most effective?
(cross-posted at BleedYellow)
Comments
Posted by Charles Robinson At 12:36:02 On 03/02/2008 | - Website - |