Better Software - April 2009 - (Page 51) The Last Word Do You Know Why You’re Doing That? by Jonathan Kohl Ambiguity can kill software projects. If you don’t have a clear idea of what you are trying to achieve, you can waste time figuring it out by trial and error. The vision for a software product is the starting point for a software project. If it is vague, it leads to confusion, duplication of effort, and wasted work. If you don’t know why you are doing what you are doing, you may be busy, but you may not be contributing. Wait a minute! Isn’t it someone else’s job to make sure the right product gets built? Isn’t that what management is for? Shouldn’t someone else worry about whether our software provides value to our users? Our job is to code, test, and perform other tasks that help us develop software, right? Sure, management has a responsibility, but so do we technical workers. Business people rely on us to help them translate their product ideas into software, and it’s our job to help them be successful. After all, that’s what they pay us for. Helping ensure our projects are on track may sound like extra work, but a bit of effort can save a lot of heartache in the long run. Here’s an example: A company founder has a vision for a software project. He’s a “big-picture thinker” who often sees opportunities others don’t. He has the connections to raise money and the influence to gather the people who can translate his vision into working software. This visionary may say, “We’re going to build best-in-class educational software for universities.” That sounds focused, doesn’t it? It even identifies a target market. But, look more closely. The problem is that it describes a product category, not a real product. It’s vague. But, we have enough to go on, don’t we? We don’t believe in “big design up front,” anyway. The design will emerge over time, right? Unfortunately, that’s often not how this kind of project plays out. it would still do Programmers are brought nothing. You were on board. They are given If you don’t know doing work but not a tight deadline and start accomplishing anyworking. It’s unclear from a why you are doing thing. This is the programming perspective what danger on software the team should build. But, that don’t team members think they will what you are doing, you may projects clear vision. have a figure it out over time. They You work hard, you can just start writing code and tests and the product will apbe busy, but you may not be fill up your time with tasks, but you pear. Besides, it’s management’s might not actually responsibility to tell them what contributing. accomplish anything to build. If it’s wrong, it’s manuseful. agement’s fault! I’ve talked to Time passes. The original vision is still vague, but at least the pro- many business analysts, product mangrammers have created working soft- agers, and even company founders who ware. They demonstrate it regularly to can’t clearly communicate what their the business folks. But, it never does products do and who their customers quite align with the product vision. are. When this happens, it doesn’t seem Changes are made, and the program- to matter which methodology the demers bring it back again. After several velopment team uses—whether it is a iterations, the emerging product is still waterfall, big-design-up-front project, as vague as the original idea. Sometimes, or a lightweight, emergent-design agile teams even burn through their entire project—the vague vision produces budget doing this, and the project gets vague software. Teams should nail down their product cancelled. If this is a startup, the executives must go back to investors and visions and basic goals before starting a explain why they spent all their money project. It’s cheaper and easier to figure without creating a product that can be out the direction to take at that point, sold. It can be enough to put a startup when there are fewer people (and costs) involved. This isn’t big design up front, under. What went wrong? We had a group where we try to predict the future and of people working together at great ex- which can have equally poor results. It’s pense to the company, without anyone about getting down to basics about what really knowing what he was working on. we are doing and why. Early, lightweight We can’t just blame management—on planning can really pay off. With a clear vision, teams experiprojects like this, we are all responsible. Often, if just one or two people speak ence: up early in the project—saying, “I don’t • Less wasted work—Teams know know why we’re doing this,” or, “Let’s what needs to get done, so there’s get clarification before we proceed”— less churn. many problems could be averted. • Increased productivity—IndividA few years ago, a friend of mine uals have a better idea of what showed me what she called a “dotheir roles and tasks are. nothing machine.” It was a solid wood • Early warning signals—Input block with a handle on it. Turn the from the people doing the work handle and the machine just sat there, can help identify problems early doing nothing. You could turn the handle on. quickly or turn the handle slowly—and • More meaningful work—Tasks www.StickyMinds.com APRIL 2009 BETTER SOFTWARE 51 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.