A pragmatic approach
Download
1 / 12

ch2-a-pragmatic-approach - PowerPoint PPT Presentation


  • 191 Views
  • Updated On :

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ch2-a-pragmatic-approach' - LionelDale


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
A pragmatic approach l.jpg

A Pragmatic Approach

Brent Bradbury

Joshua Bruning


The evils of duplication l.jpg
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!


Orthogonality l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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


Prototypes and post it notes l.jpg
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 notes8 l.jpg
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 l.jpg

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.


Estimating l.jpg

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


Estimating cont l.jpg
ESTIMATING (CONT.) magical” skill to determine the feasibility of a given goal.

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 cont12 l.jpg
ESTIMATING (CONT.) magical” skill to determine the feasibility of a given goal.

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.


ad