book

Head First Software Development

by Dan Pilone, Russ Miles

December 2007

Beginner to intermediate

495 pages

10h 45m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Author(s) of Head First Software Development
Who is this book for?Who should probably back away from this book?We know what you’re thinkingWe know what your brain is thinkingMetacognition: thinking about thinkingHere’s what WE didHere’s what YOU can do to bend your brain into submissionRead MeThe technical review teamAcknowledgmentsSafari® Books Online
Tom’s Trails is going onlineMost projects have two major concernsHow much will it cost?How long will it take?The Big Bang approach to developmentFlash forward: two weeks laterBig bang development usually ends up in a BIG MESSIf your customer isn’t happy, you built the wrong softwareGreat software development is...Getting to the goal with ITERATIONEach iteration is a mini-projectEach iteration is QUALITY softwareThe customer WILL change things upIt’s up to you to make adjustmentsYou’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 software isn’t complete until it’s been RELEASEDTools for your Software Development Toolbox
Orion’s Orbits is modernizingTalk to your customer to get MORE informationBluesky with your customerSometimes your bluesky session looks like this...Find out what people REALLY doYour requirements must be CUSTOMER-orientedDevelop your requirements with customer feedbackUser stories define the WHAT of your project... estimates define the WHENCubicle conversationPlaying planning pokerPut assumptions on trial for their livesA BIG user story estimate is a BAD user story estimateThe goal is convergenceHow close is “close enough”?The requirement to estimate iteration cycleFinally, you’re ready to estimate the whole project...And the total project estimate is...Tools for your Software Development Toolbox
Customers want their software NOW!Prioritize with the customerWhat is “Milestone 1.0”?We know what’s in Milestone 1.0 (well, maybe)Sanity-check your Milestone 1.0 estimateIf the features don’t fit, reprioritizeMore people sometimes means diminishing returnsWork your way to a reasonable Milestone 1.0Iterations should be short and sweetComparing your plan to realityVelocity accounts for overhead in your estimatesProgrammers think in UTOPIAN days...Here’s what a programmer SAYS...... but here’s what he’s really THINKINGDevelopers think in REAL-WORLD days...When is your iteration too long?Deal with velocity BEFORE you break into iterationsTime to make an evaluationDeliver the bad news to the customerManaging pissed off customersThe Big Board on your wallHow to ruin your team’s livesTools for your Software Development Toolbox

Introducing iSwoonDo your tasks add up?Plot just the work you have leftAdd your tasks to your boardStart working on your tasksA task is only in progress when it’s IN PROGRESSWhat if I’m working on two things at once?Your first standup meeting...Task 1: Create the Date classStandup meeting: Day 5, end of Week 1...Standup meeting: Day 2, Week 2...You have to track unplanned tasksUnexpected tasks raise your burn-down rateVelocity helps, but...We originally calculated velocity as...So we have this much “float”...... but it may not be enough!We have a lot to do...You’ve got more work to do......and your burn-down rate is going in the wrong direction....but we know EXACTLY where we stand
iSwoon is in serious trouble...This design breaks the single responsibility principleSpotting multiple responsibilies in your designGoing from multiple responsibilies to a single responsibilityYour design should obey the SRP, but also be DRY...The post-refactoring standup meeting...Unplanned tasks are still just tasksPart of your task is the demo itselfWhen everything’s complete, the iteration’s done
You’ve got a new contract—BeatBox ProAnd now the GUI work...And a quick test...And Bob does the same...Demo the new BeatBox for the customerStandup meetingLet’s start with VERSION CONTROLFirst set up your project......then you can check code in and out.Most version control tools will try and solve problems for youBob tries to check in his code...... but quickly runs into a problem.The server tries to MERGE your changesNonconflicting code and methods are easyYour version control software will combine filesBut conflicting code IS a problemIf your software can’t merge the changes, it issues a conflictNow show the customer...More iterations, more stories...Standup meetingWe have more than one version of our software...Good commit messages make finding older software easierPlay “Find the features” with the log messagesNow you can check out Version 1.0(Emergency) standup meetingTag your versionsSo what?Tags, branches, and trunks, oh my!Fixing Version 1.0...for real this time.We have TWO code bases nowWhen NOT to branch...Branch when...Do not branch when...We fixed ersion 1...... and Bob finished ersion 2.0 (so he says)Version control can’t make sure your code actually works...Tools for your Software Development Toolbox
Developers aren’t mind readersBuilding your project in one stepAnt: a build tool for Java projectsProjects, properties, targets, tasksGood build scripts...... generate documentation... compile your project... clean up the mess they makeGood build scripts go BEYOND the basicsYour build script is code, tooNew developer, take twoTools for your Software Development Toolbox
Things will ALWAYS go wrong...Standup meetingThere are three ways to look at your system...Your users see the system from the outsideTesters peek under the covers a littleDevelopers let it all hang out... and you need to consider each of these viewsBlack-box testing focuses on INPUT and OUTPUTGrey-box testing gets you CLOSER to the codeGrey-box testing is like black-box testing...but you can peekWhite-box testing uses inside knowledgeWhite-box tests tend to be code-on-codeHanging your tests on a frameworkTesting EVERYTHING with one stepAutomate your tests with a testing frameworkUse your framework to run your testsContinuous integration tools run your tests when you check in your codeAt the wheel of CI with CruiseControlTesting guarantees things will work... right?Standup meetingTesting all your code means testing EVERY BRANCHUse a coverage report to see what’s coveredGetting good coverage isn’t always easy...Standup meetingTools for your Software Development Toolbox
Test FIRST, not lastSo we’re going to test FIRST...Analyze the taskWrite the test BEFORE any other codeWelcome to test-driven developmentYour first test...... fails miserably.NOW write code to get the test to pass.Get your tests to GREENRed, green, refactor...In TDD, tests DRIVE your implementationCompleting a task means you’ve got all the tests you need, and they all passWhen your tests pass, move on!Different task, same processRed: write (failing) testsGreen: write code to pass testsSimplicity means avoiding dependenciesAlways write testable codeWhen things get hard to test, examine your designThe strategy pattern provides for multiple implementations of a single interfaceKeep your test code with your testsTesting produces better codeMore tests always means lots more codeStrategy patterns, loose couplings, object stand ins...We need lots of different, but similar, objectsWhat if we generated objects?A mock object stands in for real objectsMock objects are working object stand-insGood software is testable...A whole-lotta-nuthin’It’s still me...Ghosts from the pastIt’s not easy bein’ green...When all of your tests pass, you’re doneA day in the life of a test-driven developer...Tools for your Software Development Toolbox
Your iteration is just about complete...... but there’s lots left you could doStandup MeetingSystem testing MUST be done...... but WHO does system testing?Developer testingTester testingSystem testing depends on a complete system to testGood system testing requires TWO iteration cyclesMore iterations means more problemsThe life (and death) of a bugSo you found a bug....Bugs belong in a bug trackerAnatomy of a bug reportBut there’s still plenty left you COULD do...Time for the iteration reviewElements of an iteration reviewSome iteration review questionsA GENERAL priority list for getting EXTRA things done...Tools for your Software Development Toolbox
What is working software?...completing your iteration’s work...passing all your tests... satisfying your customerYou need to plan for the next iterationVelocity accounts for... the REAL WORLDAnd it’s STILL about the customerSomeone else’s software is STILL just softwareCustomer approval? Check!Testing your codeHouston, we really do have a problem...Standup meetingTrust NO ONEYou without your processYou with your process
First, you’ve got to talk to the customerStandup meetingPriority one: get things buildableWe could fix code...... but we need to fix functionalityFigure out what functionality worksNOW you know what’s not workingSpike test to estimateWhat do the spike test results tell you?You can then figure out how long it will take for your team to fix all the bugsYour team’s gut feeling mattersFeed confidence into your estimateGive your customer the bug fix estimateThings are looking good...... and you finish the iteration successfully!AND most importantly the customer is happyTools for your Software Development Toolbox
Pinning down a software development processThere is no silver-bullet processA good process delivers good softwareFormal attire required...Do what you’re doing...just prettierSome additional resources...More knowledge == better processTools for your Software Development ToolboxIt’s time to leave a mark on the board world!
#1. UML class diagramsClass diagrams show relationships#2. Sequence diagrams#3. User stories and use cases#4. System tests vs. unit tests#5. Refactoring