1. How to become a pragmatic programmer By Rick Mason, BusinessGrade.com

2. The book

3. The Book and it’s lessons Set of principles Goal building better software While Improving productivity, accuracy and job satisfaction Write flexible, dynamic and adaptable code

4. Agile is a set of principles not tools But there are specific tools that help Source control Frameworks and ORM Testing and automation tools Communication tools Bug tracking and project management

5. The cat ate my source code Take responsibility for your code Don’t live with broken windows Put out fires

6. Stone soup and boiled frogs The story of stone soup Don’t take support for granted Lead by example

7. The D.R.Y. principle Don’t repeat yourself Write less code Have fewer problems

8. Reasons for duplication Imposed – It’s the environment Inadvertent – Developers didn’t realize Impatient – Lazy developers Inter-developer duplication

9. The orthogonality principle Geometry – Lines meet at right angles Agile - Write decoupled modules

10. Is your program like a house of cards?

11. Goal : Design components that are self contained Benefit: Small components easier to write Benefit: Code reuse

12. Reduced risk from self contained components Diseased code is isolated Code is less fragile

13. Tips for writing orthogonic code Write shy code – Don’t reveal anything unnecessary Avoid global data Avoid similar functions – one function called with parameter

14. Principle of Reversibility Change happens so plan for it What if the database changes? Or a 3 rd party library gets changed? Build a flexible architecture

15. Use tracer bullets What’s a tracer bullet? If the project has unknowns Client isn’t sure what he wants Build a quick less than fully functional concept

16. Use code generators Producing same code over and over again? Consider using a code generator For example CRUD model

17. Design by contract Architect by contract Preconditions: What must be true to call the routine? Post conditions – What state has the routine returned? Class invariants – What is true from perspective of caller Share your assumptions with the client

18. Use an information radiator Whiteboards Dashboards Wiki can function as a dashboard

19. Decoupling and the law of Demeter The example of the terrorist cell Build modules that limit interaction If your module depends on three others And they each depend upon three more Any of them can blow up your module

20. Rules for refactoring code Duplication – Violate DRY principle Non-orthogonal code – Reduce module dependence Outdated knowledge – Problem changes Performance

21. The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. - Seymour Cray, Cray Computer

22. Testing Use your contract to test your assertions using code CFUnit and CFCUnit Justifying the time? Write the test, then fix the bug

23. Rules for commenting code Why something is done, it’s purpose and goal Author and date Use descriptive variables SalesOrderDelete not SOD

24. Questions? Rick Mason – RMason@BusinessGrade.com