We have a natural desire to fix things. As engineers we find satisfaction in resolving technical problems and, if you’re following test-driven practices, keeping them resolved. These thoughts flow through our minds as the primitive keyboard-wielding code monkeys we evolved from. What distinguishes us from our fecal-flinging counterparts, however, is our ability to question these instincts and wear business, user and developer hats simultaneously. Here are some additional questions we should consider before immediately reacting with technobabble.
- What business value could be realized by addressing this issue? It would be ideal to resolve it, yes, but is there any ROI for the time spent?
- How risky is this? If cleaning the big red button could potentially fire the nuke, you might want to leave the booger on it.
- How critical is this issue? If sufficient workarounds exist or this does not prevent people from working, perhaps you could move it below other todo list items that are.
- How does this make users feel? Requiring the user to click OK every two minutes will create desire to stab you with a sharp object. Your death will generate bad vibes around the project.
- What is the business impact? If the tree fell, but nobody lives in the woods.. what tree?
- What are the dependencies and dependants? Superman requires his tights be dry-cleaned before saving the planet today. You might want to run to the dry-cleaners.
- When could a resolution actually be delivered? It may take 2 minutes to fix, but if users can’t get it for two months perhaps the work can be postponed.
- Who is be most appropriate person to handle it? Maybe it’s you. Maybe it’s the guy who actually wrote the code.
- What actually needs to be fixed? Don’t replace the alternator if you only need a battery.
- Where does this fall in the project timeline? If the next deliverable is already late, you might need to rescope by sitting down with the business and reevaluating what is truly necessary.
Leave a Reply