1. Writing better software Svilen Ivanov, Netclime Inc. (svilen@netclime.com)

2. The Goal

To show you a path for becoming better programmer

• No tool, OS, vendor or product can drive a significant breakthrough (nosilver bullet )

Be more productive and effective

Based on both experience and theory (good solutions in particular cases)

3. The Philosophy (1)

Provide options, don't make lame excuses

• Explain whatcanbe done: refactoring, more prototyping, better testing, automation

Fight software entropy (disorder in the system:

• Broken window theory

• Repair bad designs, correct the wrong decisions, improve poor code as early as possible

• It takes extra effort to keep the project pristine

4. The Philosophy (2)

Good-enough software

• Make the quality a requirement issue

• Users tend to prefer good software today than perfect software tomorrow

• Modularity of the software is important to achieve the goal

Invest in your knowledge portfolio

• expiring asset - new tools/technologies

• How:

• • Learn new language every year

• • Read technical (or non-technical) book every quarter

• • Take classes, participate in local user groups (isolation is deadly)

• • Learn new environment

• • Stay current - surf web

5. The Philosophy (3)

Critically analyze what you read and hear

• Don't let vendor/media hypes trick you

Communication skills

W hat do you want them to learn? What is theiri nterest in what you've got to say? Hows ophisticated are they? How muchd etail do they want? Whom do y o u want to own the information? How can youm otivate them to listen to you? 6. The Approach (1)

DRY Don't repeat yourself

• Every piece of knowledge must have single, unambiguous,authoritative representation within the system

• Maintenancedoesn'tstart after finishing the project

• Types of duplication

• • Imposed Duplication (developers feel they have no choice for duplication)

• • • Multiple representation of same information (spec/DB/code)

• • • Comments (why vs. how)

• • • Documentation in code

• • • Language issues

• • Inadvertent Duplication (mistakes in design)

7. The Approach - DRY

• • • Inadvertent Duplication Example

class Line { public: Point start; Pointend; double length; }; class Line { public: Point start; Pointend; double length() { return start.distanceTo(end); } }; 8. The Approach - DRY

• • Impatient Duplication (developers get lazy)

• • • Shortcuts make for long delay

• • Interdeveloper Duplication (developers don't realize they produce duplication)

• • • Examples: escaping, date validation routines

• • • Make it easy to reuse

• • • Read others source code (code review or pair programming)

9. How to change a diaper

STEP 1 - Check to make sure that you have everything you need before changing the diaper.

STEP 2 - Place a disposable covering on the diaper table. Paper towels, old computer paper, wax paper, clean paper bags, or butcher paper are inexpensive choices.

STEP 3 - Remove soiled diaper and soiled clothing.

STEP 4 - Dispose of soiled diaper in a covered, plastic-lined container.

STEP 5 - Clean child's bottom with disposable wipes. Wipe front to back. Dispose of wipes.

STEP 6 - Put on a clean diaper and if necessary, clean clothing.

STEP 7 - Wash the child's hands with soap and warm running water.

STEP 8 - Remove disposable covering and discard. Remove soiled clothing, place in a plastic bag to be taken home.

STEP 9 - Clean and disinfect diapering area with bleach solution.

STEP 10 - Wash your hands with soap and warm running water.

10. The Approach - Orthogonality

Orthogonality

• Concept for producing systems which are easy to design, build, test and extend

• The term is borrowed from geometry - perpendicular

• Promotes decoupling (independence) of modules and cohesion

Move parallel to X-axis No change on Y-axis X Y 11. The Approach - Orthogonality

• Benefits

• • Eliminate effects between unrelated things

• • Gain productivity

• • • Changes are localized

• • • Promotes reuse

• • • Combining 2 orthogonal components does more

• • Reduce risk

• • • Modules are isolated

• • • Allows better testing

• • • Freedom of choice for third-party components or vendors

• • • The resulting system is less fragile

• • Minimize dependency between project teams

12. The Approach - Orthogonality

Examples of orthogonal toolkits/patterns

• Model-View-Controller

• • Each component is orthogonal (e.g. you can add views w/o changing the model)

• Aspect-Oriented Programming

• • Lets you to express a behavior that would be distributed throughout the code (e.g. Logging):

• • There is CPAN module: Aspect

aspect Trace { advise * FooClass.*(..) { static before { Log.write(Entering: + methodName); } } } 13. The Approach - Orthogonality

Coding hints

• Keep you code decoupled

• Avoid global data

• • Singleton pattern could replace global data

• Consider Strategy pattern to avoid duplication of code of functions which has similar beginning / end but different algorithm

Testing

• Orthogonal systems are easier to test automatically

• RCS to examine is your system orthogonal

Orthogonality and DRY principle

• Minimize interdependently and duplication

14. Reversibility

Reversibility

• Requirements often changes

• Making critical (irreversible) decision is tough

• After each critical decision the target changes

• Following the DRY and Orthogonality principles we minimize the need of critical decisions

• • Example: database abstraction

• The decisions aren't cast in stone!

• • Flexible architecture

15. Tracer Code

Concept

• Create end-to-end system which most components are stubs (limited functionality)

• Used to refine user requirements and find the target

Benefits

• Users get to see something work early

• Developers build a structure to work in

• You have and integration platform

• You have something to demonstrate

• You have a better feel for progress

Bad news tracer code don't always hit the target

16. Prototyping

Prototyping

• Aim to explore specific aspect of the system

• The code is disposable ( rm -rf * )

• 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 use dummy data

17. Prototyping (2)

• • Completeness very limited functionality

• • Robustness error checking may be incomplete

• • Style may be lack of comments or documentation, but usually the result is a document

• Tend to use higher-level language

• Prototyping Architecture

• • Are the responsibilities of the major components well defined?

• • Are the collaborations between major components well defined?

• • Is coupling minimized?

• • Can you identify potential sources of duplication?

• • Are interface definitions and constraints acceptable?

• • Does every module have an access path to the data it needs during execution? Does it have that accesswhenit needs it?

• Hownotto use prototypes

18. Domain Languages (1)

Program close to the problem domain

• Example Watchcub

Hostgandalf.al.nc Pace300 Port80 Typeport mars::mars_ping Typedcp Hosttrial.chartscape.net URI/Common/watchcub.html port80_gandalf 19. Domain Languages (2)

Implementing a mini language

• Simple regular expression parser

• Backus-Naur Form (BNF)

• Subset of existing language (ECMA script, Perl, Python)

Data languages (configuration information)

Imperative languages

Stand-alone vs. Embedded languages

Easy development or Easy maintenance

expect login: send svilenexpect password: send s3cre3t 20. Estimating

Estimate to avoid surprises

How to estimate

• Understand what's been asked

• Build a model of the system

• Break the model in components

• Give each parameter a value

• Calculate the answers

Keep track of your estimates

Iterate the Schedule with the Code

I'll get back to you

21. What's next (1)

A (possible) future topics

• The basic tools

• • Debugging

• • Code generators

• • Source code control

• • The power of plain text and shell

• Pragmatic paranoia

• • Design by contract

• • Assertive programming

• • When to use exceptions

• • How to balance resources

22. What's next (2)

• Design

• • Decoupling

• • Metaprogramming

• • Temporal Coupling

• • It's just a view

• While coding

• • Programming by coincidence

• • Algorithm speed

• • Refactoring

• • Code that's easy to test

• • Ruthless testing

• Management

• • Pragmatic teams

• • The specification trap

23. Thank you!

Resources

• The pragmatic programmer, Hunt et. al (SE027)

Questions?