1

BREAKING THE SOFTWARE DEATH CYCLE SPIRAL MARCH WITH DDD

DANIEL DOUBROVKINE | JAN 2011

@DBLOCKDOTORG

APPL ICATION SECURITY , INC.

HTTP: / /CODE.DBLOCK.ORG

2

SOFTWARE DEATH CYCLE

NY-based Social Networking Start-Up (2006-2008)

• We had the best and the brightest …

• Company: MM series A, B, …• CEO: visionary idea in business SN• Science: MIT• Marketing: New York Times, WSJ mentions• Sales: paid betas, MM$ pipeline• Engineering: Stanford, ex-MSFT, ex-Google

#FAIL

3

SOFTWARE DEATH CYCLE (AGAIN)

NY-based Database Security, Risk and Compliance Company

• Desktop Application

• Exponentially growing revenue, monthly releases• Enterprise Application

• Failed to install• Confused users• Missing obvious features

#FAIL

4

ENTERPRISE PRODUCT #FAIL

“This failure is a management problem.

Sales needed new features. Product management designed the features. My team implemented the features that product management told me to implement.

It got harder to add new features. It was their fault.”

- K.

5

DEATH CYCLE SYMPTOMS (PEOPLE)AS OPPOSED TO MY CURRENT TEAM

• You feel the Sword of Damocles

• Talking about #fail at your daily espresso venue

• Pride in shipping, not in the product

• Sum of individuals is far larger than progress of company

• Discussions about other companies hiring in the open

• Outlook and face-to-face procrastination

• Blind faith in open headcount

http://programmers.stackexchange.com/questions/25181/what-are-the-symptoms-events-or-actions-of-a-software-death-cycle

6

BREAKING THE DEATH CYCLE

Agile People

Architecture Products

DDD

7

BEFORE YOU BEGIN: BECOME AN AGENT OF CHANGE

• You’re going to use all your previously earned credit

• Your goal is a product you can be proud of

• Only pigs matter

• Development Manager• Development Leads

• Developers

• Product Owners• Chickens will be sacrificed managed

• Executive Management• Sales & Marketing

8

STEP 1: GROW DOMAIN ROOTS

• Choose a small team

• Everyone is very busy …• Agree that you disagree

• Asset: marketing selling the product• “You can apply an asset-wide policy across database

instances between vulnerability assessment and monitoring.”

• Database: vulnerability assessment terminology• Instance: activity monitoring terminology

• Anchor a taxonomy in writing

• Domain wiki• Scheduled domain research three times a week

9

WIKI

10

STEP 2.1: START IN THE MIDDLE

• Start with a core term:

• “An asset is …”• “An asset has one or more [[Asset Endpoint|endpoints]]

…”• “Assets can be [[Asset Archive|archived]] …

11

WIKI

http://appseclink/prodmanagement/DbProtect%20Ranger%20Wiki/Asset.aspx

12

STEP 2.2: BE THE DDD CLERK

• Keep typing

• Don’t let discussions go on tangents• Ask people to dictate sentences, type them• Let them drive it.

13

WIKI

http://appseclink/prodmanagement/DbProtect%20Ranger%20Wiki/Forms/EditForm.aspx?ID=407

14

STEP 2.3: THINGS WE DON’T KNOW

• Time box discussions

• Use “things we don’t know as an outlet”

15

WIKI

http://appseclink/prodmanagement/DbProtect%20Ranger%20Wiki/Object%20Privilege.aspx

16

STEP 2.4: REMOVE IMPLEMENTATION

• Domain is how we (developers, customers, etc.) want it to be, not how it’s implemented.

• Cut all implementation discussions• Use implementations as examples• Use stories as an overflow strategy.

17

WIKI

http://appseclink/prodmanagement/DbProtect%20Ranger%20Wiki/Principal.aspx

18

STEP 2.5: GIVE HOMEWORK

• Research and implement a new term

• Write a user story

• Refactor agreed-upon taxonomy

• Have a place to start next time!

19

WIKI

20

STEP 3: MAKE DDD AN OPEN PROCESS

• Regular brown bags on terms

• Asset Management• Endpoints and Credentials

• Vulnerability Assessment• Findings, non-findings

• Rights Management• Users, Roles, Objects

• Activity Monitoring• Events, Alerts

• Invite team members

• A term is debated in the corridor• An implementation of the domain doesn’t stick

21

STEP 4: INVITE HUMANS

• Humans != Engineers

• UX designer• Product Owner• Service Engineer

• Use humans to tell and write stories

• Obvious stories first• Actual stories with fictional names

• Star Trek• Достоевский

22

DDD PROBLEM: UNIFICATION (1/2)

• Knew that users ‘type in credentials till something tests ok’.

• Defined ‘endpoints’ as connection information (eg. IPv4 address).

• Organized endpoints in ‘profiles’ to submit to jobs.

• Walked in circles with credentials, jobs and roles.

23

DDD SUCCESS: UNIFICATION (2/2)

• Knew that ‘credential managers’ edit credentials.

• Knew that ‘job managers’ edit connection information.

• Learned that credentials are never used separately from connection information.

• Merged credentials into endpoints.

24

DDD SUCCESS: COHESION

• Created ‘asset’ concept that aggregates databases, listeners, redirectors, operating systems, etc.

• Knew that the system connects to assets.

• Learned that the system connects to databases, operating systems, WMI, remote registry using different protocols.

• Learned that those ‘things’ have a lot in common and called it ‘asset service’.

• Cohesion: asset service already existed from search context!

25

BREAK THE DEATH CYCLE!

• Obvious customer validation of value of DDD

• Big bank customer talking at Engineering All Hands• Eureka moments in DDD

• Oxytocin to the domain modelers’ brains• Ubiquitous Language amongst Engineers

• Less translating, more thinking• Simpler domain leads to simpler software

• Inverse pyramid of features• Engineering Momentum

• Less iterations to value• Higher Sales

• Rights Management booked MM$ sales with pre-release

26

CONCLUSIONS: DDD

• an effective, practical and implementable tool that can help break the software death cycle

• fits naturally with agile teams

• requires participation of people and a significant commitment in time

• extremely simple and efficient barrier between pigs and chickens

27

QUESTIONS

Daniel Doubrovkine | Jan 2011

@dblockdotorg

application security, inc.

http://code.dblock.org