A PRAGMATIC APPROACHBrent Bradbury

Joshua Bruning

THE EVILS OF DUPLICATION

Imposed Duplication Multiple representations of information Documentation in code Documentation and code Language issues

Inadvertent Duplication Impatient Duplication Interdeveloper Duplication

DRY – Don’t Repeat Yourself!

Make It Easy to Reuse!

ORTHOGONALITY

What is Orthogonality? Independence

A Nonorthogonal System Benefits of Orthogonality

Gain Productivity Changes are localized Promotes reuse M*N*cos(theta)

Reduce Risk Diseased sections of code are isolated Less fragile Better tested Isolated interfaces

Eliminate Effects Between Unrelated

Things

ORTHOGONALITY (CONT.)

Project Teams Design Toolkits and Libraries Coding

Keep your code decoupled Avoid global data Avoid similar functions

Testing Documentation Living with Orthogonality

REVERSIBILITY

“Instead of carving decisions in stone, think of them more as being written in the sand at the beach.”

Flexible Architecture Isolate components Soft, pliable decisions will allow cross-platform

compatibility to be built in. Any specific software components should be

implemented in a reversible way. If you have to use custom exception calling in C++ for example, implement it with an easily changeable macro.

TRACER BULLETS

Code That Glows in the Dark Users get to see something working early Developers build a structure to work in You have an integration platform You have something to demonstrate You have a better feel for progress

Tracer Bullets Don’t Always Hit Their Target Tracer Code versus Prototyping

Use Tracer Bullets to Find the Target

PROTOTYPES AND POST-IT NOTES

Things to Prototype Architecture New functionality in an existing system Structure or contents of external data Third-party tools or components Performance issues User interface design

How to Use Prototypes Correctness Completeness Robustness Style

PROTOTYPES AND POST-IT NOTES

Prototyping Architecture Are the responsibilities of the major components well

defined and appropriate? Are the collaborations between major components

well defined? Is coupling minimized? Can you identify potential sources of duplication? Are interface definitions and constraints acceptable?

How Not to Use Prototypes Be clear that the prototype code is disposable and

poor. Be sure to communicate that prototype code is not

to be deployed, and manage expectations accordingly.

DOMAIN LANGUAGES

Designing a simple parsable language as a method of capturing requirements can make development faster and more reliable.

Implementing a Mini-Language Make your own grammar and language, or Extend an existing language, like Python

Data Languages and Imperative Languages Data languages produce some form of data

structure, and respresent configuration information.

Imperative languages can be executed, and can ease program maintenance by acting as a go-between to high level scripts.

Program Close to the Problem Domain

ESTIMATING

Learning to estimate will give you the “apparently magical” skill to determine the feasibility of a given goal.

How Accurate is Accurate Enough? First assess how accurate an estimate the

customer needs Choose your units accordingly-- “6 months”

sounds general whereas “130 days” sounds very specific

ESTIMATING (CONT.) Where do Estimates Come From?

Often from someone who has already done it, bolstered by doing the following…

Understand what’s being asked Define assumptions and scope

Build a Model of the System A simple mental model will allow you to think

through the complexities of the proposed software. Your experience will tell you when to stop refining the model.

Break the Model into Components Understand the mathematical complexity of each

software component.

ESTIMATING (CONT.)

Give Each Parameter A Value Decide which parameters represent critical

points in execution, and calculate how much time they’ll take to execute.

Calculate the Answers Use all of the small estimations to make a final,

large estimation.