Post on 17-Dec-2015
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.