Chapter 1. Great Software Development: Pleasing your customer

image with no caption

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.

Tom’s Trails is going online

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.

image with no caption

Most projects have two major concerns

Talk to most customers and, besides their big idea, they’ve probably got two basic concerns:

How much will it cost?

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.

image with no caption

How long will it take?

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.

image with no caption

The Big Bang approach to development

With only a month to get finished, there’s no time to waste. The lead developer Tom hired gets right to work.

image with no caption

Flash forward: two weeks later

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.

Big bang development usually ends up in a BIG MESS

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.

image with no caption

If your customer isn’t happy, you built the wrong software

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.


The emphasis here is that you think you’re finished... but you may not be.

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.

image with no caption

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.

Great software development is...

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...

image with no caption

Brain Power

Can you think of three examples of software you’ve been involved with where at least one of these rules was broken?

Getting to the goal with ITERATION

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.

Without iteration...

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.

image with no caption

With iteration...

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.

image with no caption

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!


Continuous building and testing is covered in Chapter 6 and Chapter 7.

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.

image with no caption

Each iteration is a mini-project

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:

image with no caption

Each iteration is QUALITY software

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:

image with no caption

Your iteration length should be at the right tempo for YOUR project

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.

The customer WILL change things up

Tom signed off on your plan, and Iteraton 1 has been completed. You’re now well into your second iteration of development and things are going great. Then Tom calls...

image with no caption

It’s up to you to make adjustments

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.

image with no caption

But there are some BIG problems...

You’re already a long way into development...

image with no caption

... and you’ve still got other features to build...

image with no caption

... and the deadline hasn’t changed.

image with no caption

Iteration handles change automatically (well, sort of)

Your iteration plan is already structured around short cycles, and is built to handle lots of individual features. Here’s what you need to do:

  1. 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:

    image with no caption
  2. 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.

    image with no caption
  3. Rework your iteration plan

    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.

    image with no caption
  4. 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.

    image with no caption
image with no caption

A process is really just a sequence of steps

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 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.

image with no caption

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.

Your software isn’t complete until it’s been RELEASED

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.

image with no caption

Tools for your Software Development Toolbox

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.


...and some of the principles behind those techniques.

Get Head First Software Development now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.