jamesladdcode.com

I have not written a post for a while as I have been very busy working, developing Redline Smalltalk and looking after my twin boys. Recently I did get some free time and I needed a break from Redline Smalltalk and I picked up a book by Kent Beck from the top of my pile of books to be read. Yes there is a pile and there are about six books in it right now, there is even another Kent Beck book, which should not be a surprise to anyone as Kent is a great mind and his writing is worth your time.

The Kent Beck book I read was “Smalltalk Best Practice Patterns” and while you may think “what the! Isn’t this posts title about Ruby?” what I want to get across is that this book transcends a specific language and is applicable to any Object Oriented language and to anyone wanting to get a good grounding in “Best” practice and patterns of development. Having done Smalltalk, Ruby, Java and C++ I can see how each and every nugget can be applied. So regardless of your language choice you should choose to get this book.

So what does “Smalltalk Best Practice Patterns” have in it?

SBPP is a quick and easy read and it took me about 16 hours to finish it, but of course I am still thinking about the material in the book and how best to apply it. There are 92 specific items covered and a very good real world example and discussion of why. The real world, every day nature of the book makes it a must have, each section has the following elements:

• Title
• Preceding Patterns
• Problem
• Forces
• Solution
• Discussion
• Following Patterns

The appendix having a reference to each point making it great to have near by.  The book contains the following sections and topics:

• Introduction
• Patterns
• Behavior
  Methods
  Message
• State
  Instance Variables
  Temporary Variables
• Collections
  Classes
  Collection Protocol
  Collection Idioms
• Classes
• Formatting
• Development Example
• Appendix A:  Quick Reference

Being a big fan of immutable Objects I especially enjoyed the section on “Getting Method”. If you only adopt one thing from this book I hope it is about private getting methods, sometimes called “getters” or “accessors”. It is hard to stress how much better a large amount of software would be if it adopted this practice. This is how Kent puts it:

“Here’s the real secret of writing good Getting Methods - make them private at first. I cannot stress this enough.” and goes on to say “There are cases where you will publish the existence of Getting Methods for use in the outside world. You should make a conscious decision to do this after considering all the alternatives. It is preferable to give an object more responsibility, rather than have it act like a data structure.”

One comment from a reader, Kyle Brown is “The patterns in this book are absolutely fundamental to good Smalltalk programming. No one who calls himself a Smalltalk programmer should be without the knowledge in this book” and I would go so far as to say that no one who calls themselves an Object Oriented developer should be without the knowledge in this book.

We have a new Customer at home and they have three requirements:

1. As a BABY, I don’t want to feel hungry
2. As a BABY, I don’t want to be uncomfortable
3. As a BABY, I don’t want to be over tired

What I hope you will notice from the above requirements is that they are stated as close to a problem as possible, and the level of ambiguity is rather low. While this example may seem trivial it is surprising how many requirements I see that are stated in terms of a solution, that contain attributes of a solution or are peppered with ambiguity. I have found it hard to get a Customer to see these problems and amend the requirements accordingly; I think it’s much harder than looking after my new Customer, and that’s all consuming and *very* hard.

Agile encourages small feedback cycles and on my current work project this cycle is two weeks, and while this is the timeframe in which the Customer will confirm our course to be correct or not, we can do a lot more to ensure the possibility of moving in the correct direction by spending more time on the requirements themselves. Time spent removing ambiguity and ensuring the wording makes clear what the problem being solved is.

Studies have shown that the costs of fixing errors in the production phase created by false assumptions and ambiguity in the requirements phase are a ratio of some 40 - 1000 times. So economics suggest that more time should be spent on the requirements, and although Agile may mitigate some of these risks the risks remain making it economically prudent to have good requirements.

As a developer I want to give the Customer what they want, and by ensuring they convey the problem they are trying to solve, I am more likely to give them a solution to the problem, even where ambiguity exists. Where a requirement states all or part of a solution the chances are you wont have solved the Customers problem, since you don’t know what it is, and the Customer wont be happy because the problem still exists. A requirement that states a solution can sometimes remove the possibility of options being presented to the Customer, but this depends on the team culture.

Ambiguity exists when two people can read the same requirement and make different assumptions, for example, comparative words like “small” or “inexpensive” lead to ambiguity.

There are a lot of techniques for refining requirements, driving out ambiguity and focusing the requirements to convey the problem and the best collection of these techniques I have found is in the book “Exploring Requirements, Quality Before Design” by Donald C. Gause & Gerald M. Weinberg. However, if time to read the book is an issue, just ask “why?” at least five times on each requirement and “what problem does this solve?”. I typically find this approach uncovers a mass of things that need to be covered.

Update:

Some people have asked me about how requirements can be ambiguous and I thought an example from the book would be ideal. In keeping with things that appeal to my new Customer, I have chosen the example in the book where the authors take a familiar nursery ryme and apply a process of emphasizing each of the words in the line, one by one, and then in combinations to identify ambiguity. They uncover 32 different meanings of just the first line of the familiar poem, that could be 32 different solutions all of which may not be right for the Customer. The poem is:

Mary had a little lamb.
its fleece was white as snow.
And everywhere that Mary went,
The lamb was sure to go.

Here are some of the different meanings uncovered in just the first line of the poem, but please get the book to see the full set which really drives home this technique.

Mary had a little lamb.
(It was Mary’s lamb, not Tom’s, Dick’s or Harry’s.)

Mary had a little lamb.
(She no longer has the lamb)

Mary had a little lamb.
(She had only one lamb, not several.)

Mary had a little lamb.
(It really was surprisingly small.)

Mary had a little lamb.
(She didn’t have a dog, cat, cow, goat, or parakeet.)

Mary had a little lamb.
(John still has his little lamb.)

Mary had a little lamb.
(As contrastred with Pallas, who still has four large turtles.)

My personal favourite is what happens when you apply different dictionary meanings to the words, like ‘had’, for example:

Mary had a little lamb.  So what did she have for desert ?

I’m very pleased to see that Robert C. Martin has another book coming out really soon. Clean Code: A Handbook of Agile Software Craftsmanship.

You can see the table of contents over at the ObjectMentor blog here.

It will be nice to get all these topics covered in one book.

At the recent Melbourne Patterns Group (that I blogged about here) Gian Lorenzetto lent me a copy of the book Implementation Patterns by Kent Beck and Chapter 4 of the book is called “Motivation”. This chapter is a great description of the “costs” of software development and I wanted to share it with you. If you can find a better description then please let me know about it.

“Chapter 4 Motivation

Thirty years ago Yourdon and Constantine in Structured Design identified economics as the underlying driver of software design. Software should be designed to reduce its overall cost. The cost of software is divided into the initial cost and the cost of maintenance:

cost _total = cost _develop + cost _maintain

Once the industry gained experience with software development, it was a big surprise to many that the cost of maintenance is much higher than the cost of initial development. (Projects with little or no maintenance should use a very different set of implementation patterns from those presented in the remainder of this book.)

Maintenance is expensive because understanding existing code is time consuming and error-prone. Making changes is generally easy when you know what needs changing. Learning what the current code does is the expensive part. Once the changes are made, they need to be tested and deployed.

cost _maintain = cost _understand + cost _change + cost _test + cost _deploy

One strategy for reducing the overall cost is to invest more in initial development in hope of reducing or eliminating the need for maintenance. Such efforts have generally failed to reduce overall costs. When code needs to change in unanticipated ways, no amount of forethought can perfectly prepare the code for change. The premature attempts to make the code general enough to meet the future needs often interfere with the unanticipated changes that turn out to be necessary.

Substantially increasing the up-front investment in software runs counter to two important economic principles: the time value of money and the uncertainty of the future. Since a dollar today is worth more than a dollar tomorrow, in principle and implementation strategy should generally encourage deferring costs. Also, because of uncertainty an implementation strategy should generally take immediate benefits in preference over possible long term benefits. While this may sound like an license to hack without regard for the future, the implementation patterns are focused on ways to gain immediate benefit while setting up clean code for ease of future development.

My strategy for reducing overall costs is to ask all programmers to address the cost of understanding code during the maintenance phase by focusing on communicating, programmer-to-programmer. The immediate benefits of clear code are fewer defects, easier sharing of code, and smoother development.

Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts.”

I started software development 23 years ago and in those first couple of years I worked with a guy who used to say “The quickest way to do anything is not to have to do it.”, and this is why you should get the book “Prefactoring by Ken Pugh, Copyright 2005 O’Reilly Media Inc., 0-596-00874-0. That guy used to also say “bugger all of bugger all is still bugger all”, but that isn’t covered in the book so I’ll stick with the first saying.

There is a lot of buzz around Refactoring and how to improve software that is already written, but Prefactoring is a collection of guidelines that help you make better software the first time around. The guidelines won’t remove your need to refactor, but they will have made it easier to do when the time comes. Having a copy of Prefactoring is like having a senior software developer pairing with you all the time.

You should buy the Prefactoring book because it collects together in one place many guidelines that help you write better software.  The explanations for the guidelines are clear and the guidelines themselves are well presented. Close to each guideline is an exert box containing some text that helps to explain the “why” of the guidelines. There wasn’t a guideline that was new to me, but the way they are presented will make it much easier for me to explain “why” to other team members when I suggest they take a different approach to their code.

What follows is the list of guidelines to give you an idea what is covered. This list is no substitute for getting the book since you miss out on the “why” for each guideline. Maybe later I’ll expand this list with the additional sentences that go with each guideline, if enough people ask for it.

1. A Rose by Any Other Name Is Not a Rose
2. Adapt a Prefactoring Attitude
3. Adopt And Adapt
4. Avoid Premature Generalization
5. Avoid Premature Inheritance
6. Be Ready to Import and Export
7. Build Flexibility for Testing
8. Business Rules Are a Business unto Themselves
9. Clump Data so That There Is Less to Think About
10. Communicate With Your Code
11. Consider Failure and Expectation, Not an Exception
12. Consider Privacy
13. Consistency Is Simplicity
14. Create Interface Contracts
15. Decide on a Strategy to Deal with Deviations and Errors
16. Declaration over Execution
17. Decouple with Associations
18. Do a Little and Pass The Buck
19. Do a Little Job Well and You Will Be Called upon Often
20. Document Your Assumptions and Your Decisions
21. Don’t Change What It Is
22. Don’t Let The Cold Air In
23. Don’t Overclassify
24. Don’t Reinvent the Wheel
25. Don’t Repeat Yourself (DRY)
26. Don’t Speed Until You Know Where You Are Going
27. Exceptional Guideline
28. Explicitness Beats Implicitness
29. Figure Out How to Migrate Before You Migrate
30. Get Something Working
31. If It Can’t Be Tested, Don’t Require it
32. If It Has Collection Operations, Make It a Collection
33. If You Forget Security, Your Not Secure
34. Honor The Class Maxims
35. Know Who It Is
36. More Is Sometimes Less
37. Most Strings Are more than just a String
38. Never Be Silent
39. Never Let a Constant Slip into Code
40. Nothing Is Perfect
41. Overloading Functions Can Become Overloading
42. Perform Retrospectives After Each Release
43. Place Methods In Classes Based on What They Need
44. Plan for Testing
45. Plan Globally, Develop Locally
46. Plan Your Logging Strategy
47. Prototypes Are Worth A Thousand Words
48. Report Meaningful User Messages
49. See What Condition Your Condition Is In
50. Separate Concerns to Make Smaller Concerns
51. Separate Policy From Implementation
52. Split Interfaces
53. Splitters Can Be Lumped More Easily Than Lumpers Can Be Split
54. Test or Production: That Is The Question
55. Test the Interface, Not the Implementation
56. The Easiest Code to Debug Is That Which Is Not Written
57. The Spreadsheet Conundrum
58. Think About The Big Picture
59. Think Interface, Not Inheritance
60. To Test or Not to Text
61. Use the Client’s Language
62. Use the Same Layout to Get the Same Layout
63. Validate, Validate, Validate
64. When in Doubt, Indirect
65. When You’re Abstract, be Abstract All the Way

The Elements of UML Style, Scott W. Ambler (Cambridge) is one of the small pocket books like The Elements of Java Style that is very handy to have around. I’m constantly forgetting little bits here and there about UML like if dimonds are filled or not-filled and this reference covers everything in a handy keep on your desk or in your backpack size. There is even a section on Agile Modeling.

Technically this isnt about a book but a report on a book. If you like Agile XP then this is a must read.

The New XP, Michele Marchesi a report on Extreme Programming Explained — Second Edition, Kent Beck, Cynthia Andres

Extreme Programming - Pocket Guide, by chromatic, O’Reilly is a neat little pocket book and good to keep around or in the back pack.

A Practical Guide to Extreme Programming, by David Astels, Granville Miller and Miroslav Novak.

Very thorough on all aspects of an XP project from the begining to the end. Lots of good examples.