Head First Software Development

Chapter 1. Great Software Development: Pleasing your customer

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.

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.

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.

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.

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.

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.

Note

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

Sharpen your pencil

Can you figure out where things went wrong? Below are three things Tom said he wanted his site to allow for. Your job is to choose the option underneath each item that most closely matches what Tom means. And for the third one, you’ve got to figure out what he means on your own. Good luck!

1. Tom says, “The customer should be able to search for trails.”

   	The customer should see a map of the world and then enter an address to search for trails near a particular location.
   	The customer should be able to scroll through a list of tourist spots and find trails that lead to and from those spots.
   	The customer should be able to enter a zip code and a level of difficulty and find all trails that match that difficulty and are near that zip code.

2. Tom says, “The customer should be able to order equipment.”

   	The customer should be able to view what equipmentTom has and then create an order for items that are in stock.
   	The customer should be able to order any equipment they need, but depending on stock levels the order may take longer if some of the items are back-ordered.

3. Tom says, “The customer should be able to book a trip.”

   

Relax

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.

Sharpen your pencil Solution

Can you figure out where things went wrong? Your job was to choose the option underneath each item that most closely matches what Tom means. And for the third one, you had to figure out what he means on your own.

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

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.

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.

There are no Dumb Questions

Q:	Q: What if I’m sure that I know what the customer wants at the beginning of a project? Do I still need to iterate?
A:	A: Absolutely. Iteration and getting feedback from your customer is important especially when you think you know it all up front. Sometimes it can seem like a complete no-brainer on a simple piece of software, but checking back with the customer is ALWAYS worth it. Even if the customer just tells you you’re doing great, and even if you actually do start out with all the right requirements, iteration is still a way to make sure you’re on the right track. And, don’t forget, the customer can always change their mind.
Q:	Q: My entire project is only two months long. Is it worth iterating for such a short project?
A:	A: Yep, iteration is still really useful even on a very short project. Two months is a whopping 60 days of chances to deviate from the customer’s ideal software, or misunderstand a customer’s requirement. Iteration lets you catch any potential problems like this before they creep into your project. And, better yet, before you look foolish in front of your customer.
Q:	Q: Wouldn’t it just be better to spend more time getting to know what the customer really wants, really getting the requirements down tight, than always letting the customer change their mind midstream?
A:	A: You’d think so, but actually this is a recipe for disaster. In the bad old days, developers used to spend ages at the beginning of a project trying to make sure they got all the customer’s requirements down completely before a single line of code or design decision was made. Unfortunately, this approach still failed. Even if you think that you completely understand what the customer needs at the beginning, the customer often doesn’t understand. So they’re figuring out what they want as much as you are. You need a way of helping your team and your customer grow their understanding of their software as you build it, and you can’t do that with a Big Bang, up-front requirements approach that expects everything to be cast in stone from day one.
Q:	Q: Who should be involved in an iteration?
A:	A: Everyone who has a say in whether your software meets its requirements, and everyone who is involved in meeting those requirements. At a minimum, that’s usually your customer, you, and any other developers working on the project.
Q:	Q: But I’m only a team of one, do I still need to iterate?
A:	A: Good question, and the answer is yes (starting to detect a theme here?). You might only be a development team of one, but when it comes to your project there are always, at a minimum, two people who have a stake in your software being a success: your customer and you. You still have two perspectives to take into account when making sure your software is on the right path, so iteration is still really helpful even in the smallest of teams.
Q:	Q: How early in a project should I start iterating?
A:	A: As early as you have a piece of software running that you can discuss with your customer. We normally recommend around 20 work days—1 calendar month, per iteration as a rule of thumb—but you could certainly iterate earlier. One- or two-week iterations are not unheard of. If you aren’t sure about what a customer means on Day 2, call them. No sense waiting around, guessing about what you should be doing, right?
Q:	Q: What happens when my customer comes back with bad news, saying I’m way off on what I’m building. What do I do then?
A:	A: Great question! When the worst happens and you find that you’ve deviated badly during an iteration, then you need to bring things back into line over the course of the next couple of iterations of development. How to do this is covered later on, but if you want to take a peek now, fast-forward to Chapter 4.

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!

Note

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.

Note

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.

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:

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:

Exercise

It’s time to bring iterations into play on Tom’s Trails. Each of the features that Tom wants for Trails Online has had estimates added to specify how long it will take to actually develop. Then we figured out how important each is to Tom and then assigned a priority to each of them (10 being the highest priority, 50 being the lowest). Take each feature and position them along the project’s timeline, adding an iteration when you think it might be useful.

Oh, one other thing. Tom doesn’t want customers to be able to buy equipment unless they’ve logged in to the web site. Be sure and take that into account in your plan.

Exercise Solution

Your job was to build an iteration plan for Tom’s Trails. You should have come up with something like we did, below:

Note

This is probably the only plan that serves the customer’s priorities, keeps iterations at a manageable length, and gets the job done. If you came up with something different, take a hard look at why you made different choices than we did.

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.

There are no Dumb Questions

Q:	Q: The last feature scheduled for my iteration will push the time needed to way over a month. What should I do?
A:	A: Consider shifting that feature into the next iteration. Your features can be shuffled around within the boundaries of a 20-day iteration until you are confident that you can successfully build an iteration within the time allocated. Going longer runs the risk of getting off course.
Q:	Q: Ordering things by customer priority is all fine and good, but what happens when I have features that need to be completed before other features?
A:	A: When a feature is dependent on another feature, try to group those features together, and make sure they are placed within the same iteration. You can do this even if it means doing a lower-priority feature before a high-priority one, if it makes the high-priority feature possible. This occurred in the previous exercise where the “Log In” feature was actually a low customer priority, but needed to be in place before the “Buy Equipment” feature could be implemented.
Q:	Q: If I add more people to the project, couldn’t I do more in each of my iterations?
A:	A: Yes, but be very careful. Adding another person to a project doesn’t halve the time it takes to complete a feature. We’ll talk more about how to factor in the overhead of multiple people in Chapter 2, when we talk about velocity.
Q:	Q: What happens when a change occurs and my plan needs to change?
A:	A: Change is unfortunately a constant in software development, and any process needs to handle it. Luckily, an iterative process has change baked right in...turn the page and see what we mean.

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

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.

But there are some BIG problems...

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

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

... and the deadline hasn’t changed.

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:

   

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.

   

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.

   

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.

   

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

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.

There are no Dumb Questions

Q:	Q: What happens when the customer comes up with new requirements and you can’t fit all the extra work into your current iteration?
A:	A: This is when customer priority comes into play. Your customer needs to make a call as to what really needs to be done for this iteration of development. The work that cannot be done then needs to be postponed until the next iteration. We’ll talk a lot more about iteration in the next several chapters.
Q:	Q: What if you don’t have a next iteration? What if you’re already on the last iteration, and then a top priority feature comes in from the customer?
A:	A: If a crucial feature comes in late to your project and you can’t fit it into the last iteration, then the first thing to do is explain to the customer why the feature won’t fit. Be honest and show them your iteration plan and explain why, with the resources you have, the work threatens your ability to deliver what they need by the due date. The best option, if your customer agrees to it, is to factor the new requirement into another iteration on the end of your project, extending the due date. You could also add more developers, or make everyone work longer hours, but be wary of trying to shoehorn the work in like this. Adding more developers or getting everyone to work longer hours will often blow your budget and rarely if ever results in the performance gains you might expect (see Chapter 3).

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.

Development Techniques

Iteration helps you stay on course

Plan out and balance your iterations when (not if) change occurs

Note

Here are some of the key techniques you learned in this chapter...

Every iteration results in working software and gathers feedback from your customer every step of the way

Note

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

Development Principles

Deliver software that’s needed

Deliver software on time

Deliver software on budget

Bullet Points

• The feedback that comes out of each iteration is the best tool for ensuring that your software meets the needs of your customers.

• An iteration is a complete project in miniature.

• Successful software is not developed in a vacuum. It needs constant feedback from your customer using iterations.

• Good software development delivers great software, on time and on budget.

• It’s always better to deliver some of the features working perfectly than all of the features that don’t work properly.

• Good developers develop software; great developers ship software!

Software Development Cross

Let’s put what you’ve learned to use and stretch out your left brain a bit. All of the words below are somewhere in this chapter. Good luck!

Across

Down

2. I’m the person or company who ultimately decides if your software is worth paying for. 4. Good Developers develop, great developers ......... 6. An iteration produces software that is ......... 7. Aim for ......... working days per iteration. 9. The number of development stages that are executed within an iteration. 12. I am one thing that your software needs to do. 13. The date that you need to deliver your final software on. 15. Iteration is ......... than a process. 16. The single most important output from your development process. 17. Software isn’t complete until it has been .........

1. A ......... is really just a sequence of steps. 3. When a project fails because it costs too much, it is ......... 5. I contain every step of the software development process in micro and I result in runnable software. 8. The minimum number of iterations in a 3 month project. 10. Software that arrives when the customer needs it is ......... 11. An iteration is a complete mini-......... 14. The types of software development projects where you should use iteration.

Software Development Cross Solution