If your customer’s unhappy, everyone’s unhappy!
Every great piece of software starts with a customer’s big idea. It’s your job as a professional software developer to bring that idea to life. But taking a vague idea and turning it into working code—code that satisfies your customer—isn’t so easy. In this chapter you’ll learn how to avoid being a software development casualty by delivering software that is needed, on time, and on budget. Grab your laptop, and let’s set out on the road to shipping great software.
Trekkin’ Tom has been providing world-famous trail guides and equipment from his shack in the Rockies for years. Now, he wants to ramp up his sales using a bit of the latest technology.
Talk to most customers and, besides their big idea, they’ve probably got two basic concerns:
No surprise here. Most customers want to figure out how much cash they’ll have to spend. In this case, though, Tom has a pile of money, so that’s not much of a concern for him.
The other big constraint is time. Almost no customer ever says, “Take as long as you want!” And lots of the time, you have a specific event or date the customer wants their software ready for.
In Tom’s case, he wants his website available in three months’ time, ready for the big TrailMix Conference coming up.
Tom’s lead developer has pulled out all the stops to build Tom’s Trails Online, putting all her finest coding skills into play and producing what she thinks Tom wants her to build.
Even though a lot of work went into the project, Tom hasn’t seen any of the (hopefully) completed work yet. Let’s see what he thinks about the completed website.
Big bang software usually means working a whole lot, but it also means not showing the customer much until your work is done. The risk with that approach is you think you’re building what the customer wants with no real feedback until you think you’re finished.
And, no matter how great YOU think your software is, it’s the customer you have to make happy. So if the customer doesn’t like what you’ve built, don’t waste time trying to tell them they’re wrong. Just get ready to do some rework.
But how do you figure out what the customer really wants? It’s not always easy...
Confused about what Tom really meant? It’s okay... just do your best.
If you’re having a hard time figuring out which option to choose, that’s perfectly normal. Do your best, and we’ll spend a lot more time in this chapter talking about how to figure out what the customer problems.
If you’re not sure what the customer wants, or even if you think you’re sure, always go back and ask
When it comes to what is needed, the customer is king. But it’s really rare for the customer to know exactly what he wants at the beginning of the project.
When you’re trying to understand what your customer wants, sometimes there’s not even a right answer in the customer’s head, let alone in yours! If you disappear in a hurry and start coding, you may only have half the story... or even less.
But software shouldn’t be guesswork. You need to ensure that you develop great software even when what’s needed is not clear up front. So go ask the customer what they mean. Ask them for more detail. Ask them for options about how you might implement about their big ideas.
Software development is NOT guesswork. You need to keep the customer in the loop to make sure you’re on the right path.
We’ve talked about several things that you’ll need for successful software. You’ve got the customer’s big ideas to deal with, their money you’re spending, and a schedule you’ve got to worry about. You’ve got to get all of those things right if you’re going to build consistently great software.
Great software development delivers...
The secret to great software development is iteration. You’ve already seen that you can’t simply ignore the customer during development. But iteration provides you a way to actually ask the question, at each step of development, “How am I doing?” Here are two projects: one without iteration, and one with.
Suppose you take the Big Bang approach to development—or any other approach where you’re not constantly checking in with the customer. The likely outcome? Missing what the customer wanted, and by a lot, not just a little.
This time, you decide that every time you make significant progress you’ll check with the customer and refine what you’re working on. You also don’t make any major decisions without incorporating customer feedback.
Iteration is like a frequent checkup for your software. You’ll always know how you’re doing.
No matter how big the team, or how long the project, iteration is ALWAYS one of the keys to building great software.
An iteration produces working software
With the old Big Bang approach to developing software, you probably wouldn’t have any software ready until the end of the project, which is the worst time to realize that you’ve gone wrong!
With iteration, you check every step of the way that you’re going in the right direction. That means making sure your software builds from almost day one (and more like hour one if you can manage it). You shouldn’t have long periods where code doesn’t work or compile, even if it’s just small bits of functionality.
A working build also makes a big difference to your team’s productivity because you don’t have to spend time fixing someone else’s code before you can get on with your own tasks
Then you show your customer those little pieces of functionality. It’s not much, sometimes, but you can still get an OK from the customer.
With iteration, you take the steps you’d follow to build the entire project, and put those steps into each iteration. In fact, each iteration is a mini-project, with its own requirements, design, coding, testing, etc., built right in. So you’re not showing your customer junk... you’re showing them well-developed bits of the final software.
Think about how most software is developed: You gather requirements (what your customer wants), build a design for the entire project, code for a long time, and then test everything. It looks a bit like this:
But suppose you didn’t look at iteration as just a way to write big software. Think of iteration as little cycles, where you’re gathering requirements, designing, writing code, and testing. Each cycle produces working, quality software:
An iteration helps you stay on track, and so you might decide to have iterations that are shorter or longer than 30 days. Thirty days might seem like a long time, but factor in weekends, and that means you’re probably going to get 20 days of actual productive work per iteration. If you’re not sure, try 30 calendar days per iteration as a good starting point, and then you can tweak for your project as needed.
The key here is to iterate often enough to catch yourself when you’re deviating from the goal, but not so often that you’re spending all your time preparing for the end of an iteration. It takes time to show the customer what you’ve done and then make course corrections, so make sure to factor this work in when you are deciding how long your iterations should be.
Tom’s new idea means three new features, all high-priority. And we don’t even know how long they’ll take, either. But you’ve got to figure out a way to work these into your projects.
But there are some BIG problems...
Estimate the new features
First, you need to estimate how long each of the new features is going to take. We’ll talk a lot more about estimation in a few chapters, but for now, let’s say we came up with these estimates for the three new features:
Have your customer prioritize the new features
Tom already gave everything a priority of “20,” right? But you really need him to look at the other features left to implement as well, and prioritize in relation to those.
The ordering is set based on prioritization, and there aren’t any dependencies. So now you change your plan, keeping your iteration length and the overall schedule in mind.
Check your project deadline
Remember the TrailMix Conference? You need to see if the work you’ve got left, including the new features, still can get done in time. Otherwise, Tom’s got to make some hard choices.
Process, particularly in software development, has gotten a bit of a bad name. A process is just a sequence of steps that you follow in order to do something—in our case, develop software. So when we’ve been talking about iteration, prioritization, and estimation, we’ve really been talking about a software development process.
Rather than being any formal set of rules about what diagrams, documentation, or even testing you should be doing (although testing is something we’d definitely recommend!), a process is really just what to do, and when to do it. And it doesn’t need an acronym...it just has to work.
We don’t really care what process you use, as long as it has the components that ensure you get great, quality software at the end of your development cycle.
Iteration is more than a process
Regardless of the actual steps involved in the process you choose, iteration is a best practice. It’s an approach that can be applied to any process, and it gives you a better chance of delivering what is needed, on time and on budget. Whatever process you end up using, iteration should be a major part.
The right software development process for YOU is one that helps YOU develop and deliver great software, on time and on budget.
You added the new features, and now you and your team have finished the project on time and on schedule. At every step of the way, you’ve been getting feedback from the customer at the end of each iteration, incorporating that feedback, and new features, into the next iteration. Now you can deliver your software, and then you get paid.
Software Development is all about developing and delivering great software. In this chapter, you learned about several techniques to keep you on track. For a complete list of tools in the book, see Appendix ii.