A P RAGMATIC A PPROACH Brent Bradbury Joshua Bruning

T HE E VILS OF D UPLICATION 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!

O RTHOGONALITY 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

O RTHOGONALITY ( CONT.) Project Teams Design Toolkits and Libraries Coding Keep your code decoupled Avoid global data Avoid similar functions Testing Documentation Living with Orthogonality

R EVERSIBILITY “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.

T RACER B ULLETS 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

P ROTOTYPES AND P OST - IT N OTES 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

P ROTOTYPES AND P OST - IT N OTES 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.

D OMAIN L ANGUAGES 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

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