1 / 12

A Pragmatic Approach

A Pragmatic Approach. Brent Bradbury Joshua Bruning. The Evils of Duplication. DRY – Don’t Repeat Yourself!. Imposed Duplication Multiple representations of information Documentation in code Documentation and code Language issues Inadvertent Duplication Impatient Duplication

LionelDale
Download Presentation

A Pragmatic Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Pragmatic Approach Brent Bradbury Joshua Bruning

  2. The Evils of Duplication DRY – Don’t Repeat Yourself! • Imposed Duplication • Multiple representations of information • Documentation in code • Documentation and code • Language issues • Inadvertent Duplication • Impatient Duplication • Interdeveloper Duplication Make It Easy to Reuse!

  3. 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

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

  5. 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.

  6. Tracer Bullets Use Tracer Bullets to Find the Target • 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

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

  8. 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.

  9. Program Close to the Problem Domain 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.

  10. 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

  11. 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.

  12. 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.

More Related