obsessively thorough software design preview

8/4/2019 Obsessively Thorough Software Design Preview

1/18

Obsessively ThoroughSoftware Design


3/18

ObsessivelyThorough

Software Design


4/18


5/18

Chapter 1

09 | When Bad Things Happen to Good Projects

Chapter 2

17| So, Now What?

Chapter 3

27 | Interface-Driven Architecture Project Plan

Contents


6/18


7/18

About the AuthorsHal Helms

www.HalHelms.com

A key consultant on Epicenter's client projects, Hal Helms is a pioneer in object-

oriented so tware architecture and a legend in the development community. Known

worldwide as a Java and ColdFusion guru, Hal has served as a trainer and consultantto many global organizationsincluding eBay, the Federal Reserve Board, UPS, the U.S.

Army, and Regions Bank. He is the author o many books on ColdFusion, including the

ColdFusion MX Developer's Handbook and ColdFusion MX Bible.

Hal was the rst to introduce the concept o building an interactive demo as a key

part o the so tware development processan idea he re ned into Inter ace-Driven

Architecture, in partnership with Epicenter ounder Clark Valberg. Together, the twowrote the book on this innovative method: Obsessively Thorough So tware Design.

Clark Valberg

www.ClarkValberg.com

A passionate advocate or business-driven so tware development, Clark Valberg isthe ounder and CEO o Epicenter Consulting a Manhattan-based rm dedicated to

trans orming the way organizations operate through strategic custom so tware.

Clark is the co-inventor o Inter ace-Driven Architecture and co-author o Obsessively

Thorough So tware Design. By ostering an interactive development process that

encourages cooperation between business leaders and so tware architects, this

methodology o ers a radically innovative way o developing custom so tware.


8/18


9/18

When BadThings

Happen to

C h a p t e r 1


10/18

We might as well get the bad news out right away. In a widely-cited report,

The Standish Group disclosed the results of a thorough study on custom

software applicationsincluding websites and Web applications.

Aptly named, The CHAOS Report revealed that, in 2004, custom so t-

ware projects were delivered on time and on budget only 29% o the time.

Outright project ailures accounted or 18% o all attempted projects. The

remaining 53% were charitably deemed challengedwith cost overruns

averaging 43% more than the budgeted amount and with time overruns up

to 180% greater than time originally allocated.

This So tware Project Survival Guide was written to help you avoid thecommon ate o so many so tware projects by helping you understand the

recurring causes or such ailure.

An Onset of Can-Do FluIts not that so tware developers want to ail: were as rustrated as anyone

when yet another project alls into the challenged category or, worse, be-comes an outright ailure. So why does it keep happening?

Consider how so tware project contracts are granted. In the typical scenario,

several so tware development rms will be asked to o er a bid on a project.

Working with a little in ormationa Request or Proposal, perhaps, or

simply rom an interview with the client,the development rm is asked to

commit themselves to a rm, xed bid or the entire project.

At exactly the point where the so tware rm knows almost nothing about

what customer requirements will truly be, they are asked or a xed price. At

exactly the point where the risk is maximal, the development rm is asked

to commit to a set price and a rm date.

It might seem that the developers would logically seek to mitigate their risk

by charging as much as possible and promising as little as possible. But de-velopers are prone to a work-related illness: the Can-Do Flu Symptoms o the


11/18

We Have Another Term for itKnowing that they will be competing or your business against other

developers similarly a ficted, they will happily provide you with a bid that in-cludes a xed price and a rm delivery date. In the industry, we re er to these

as back-o -the-envelope bids. And, un ortunately, theyre usually worth the

paper that envelope is constructed rom.

Now, developers arent really quite that oolish. They know that once they

have the job, they have a truly e ective risk-mitigation strategy: the Change

Order. Since they dont know enough to provide a ully speci ed bid, the

language o the proposal is necessarily vague. When, during the course o

building the so tware, they discover something they did not anticipate, the

change order provides convenient cover.

The Case of the Disappearing

DeveloperIn our scenario, one o the rms is granted the project. Now, something curi-

ous happens: a ter a ew initial meetings, the developer disappears! No more

meetings, only occasional phone calls and possibly a ew emails. You are not

overly concernedyouve discussed the requirements with the developer.

They may have interviewed some o the people who will use the so tware.

Custom software

projects were delivered


12/18


13/18

Now they have to go produce the code.

What you dont knowand what the developer likely has no idea o is that

the success or ailure o your project is already determined before a single

line of code is written . The root cause o ailure is ignorance.

A piece o so tware that both meets your current needs and has the fex-

ibility to adapt easily to new ones is based on a scale model o your busi-

ness. It needs to refect both the ormal knowledge o your business and the

techniques and policies that make your business uniquely yoursa sort o

tribal knowledge.This kind o in ormationvital to the success o your projectcannot be

gleaned rom a ew meetings and the occasional phone call. The user re-

quirements the developer has uncovered are but the tip o the iceberg. What

lies hidden beneath are the real needs o your business. Given this, is it any

wonder that only 29% o custom so tware succeeds?

Project TimewarpWhile the developers are hard at work on your project, time advances. At

some point, youll start making inquiries about the state o the project. Its

a running joke within the industry that at any point when a developer is

asked, How ar along are you?, s/he will answer: 90%. Indeed: the rst

90% o the job only took six weeks; its the nal 10% that can run into

many more months.

Theres a good reason or this project timewarp: the rst 90% o the job was

the easy part. Its the techie part developers enjoydesigning databases,

writing so tware modules, and so orth. All o this would be ne, i the de-

velopers were the ultimate judges o the projects success. But, theyre not.


14/18

With each new day come new questions developers must ace about how

your so tware should unction. But removed rom the process are the only

people who can and should answer these decisions: users. And without

these users, developer must make guesses about how your business works

and how the so tware should behave.

These are the dog days o the project, where developers are caught in the

quagmire o absent user requirements. Long gone are the halcyon days

where lo ty promises were made. Weve entered the phase o the project

known as The Death March. The goal now is to deliver something and

get on with the next project thats already behind schedule.

Anyway, the developers say to themselves, the client is bugging us to

deliver the so tware and, besides, this project was underbid. What can they

expect? A jibe all developers know is that a project will run out o time

and money long be ore it runs out o excuses.

A project will run

out of time andl b f i


15/18

Ta-Da Time!Its time to deliver the so tware. A ter many weeks o patient waiting, the

users will get a chance to see the so tware designed to make them more

productive and even open new opportunities or the business.

A meeting to demonstrate the new so tware is held. Theres palpable

excitement as the rst screen is displayed. Then the next screen. And the

next. The developer races through the eatures o the so tware, ignoring

the blank looks o the users.

Is this what were actually going to use? a bold user may inquire. Another

may venture a suggestion: You know what would be nice And now, or

the rst time in the project, the developer gets real user requirements

when theres neither time nor money to make the so tware work.

Now, things arent always this bleak, o course. Sometimes, the develop-

ers get it just right. Actually, that happens 29% o the time. The problem

is that weve involved real users exactly twice in the process at the

beginning o the project, when it was too early or them to give us any

meaning ul eedback, and at the endwhen its too late to make use o

that eedback.

We said earlier that the success or ailure o a project was determinedbe ore the rst line o code is written. Why? Because the die was cast when

the developers proceeded be ore the true requirements were known. This

is, ar and away, the greatest single cause or so tware project ailure.

In act, Dr. Ralph Young, o Northrup Grumman In ormation Technology

Division, estimates that 85% o de ects in developed so tware originate in

ailed requirements.


16/18

Time for Some Good News? The good news is that the causes o so tware project ailure are well

knownand avoidable. The rest o this Survival Guide explains how youcan make sure your project is in that elite 29% o successes.

Beating the Odds: ConductingSuccessful Software ProjectsWhile its true that over 70% o so tware projects involve some signi cant

degree o ailure, that number is not spread evenly across all so tware

production methodologies. In the last several years, a new and highly suc-

cess ul approach to so tware project management has emerged under the

banner o agile so tware practices.


17/18So NowC h a p t e r 2


18/18

OBSESSIVELY THOROUGH

SOFTWARE DESIGN THE BOOK Obsessively Thorough Software Design was created by

Epicenter founder, Clark Valberg, and software architect and guru, Hal

Helms. Based on years of research from numerous corporate case

studies, the guide examines the fundamental architectural and

operational flaws that have previously bedeviled companies trying to

embrace the Web. The authors call on experiences with such major

entities as UPS, eBay, Adobe, and IBM to demystify the software

design experience, and pave the way for effectively doing business on

the web.

To purchase the rest of this book, go to:

http://www.epicenterconsulting.com/book.cfm

obsessively thorough software design preview

Documents