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.

I recently got a copy of the book An Introduction to Seaside so I went for a quick trip to Seaside over the last week and it was refreshing and fun.  Seaside is a Web Application development framework for Smalltalk and the book is a well paced introduction to all you need to know to start writing Web Apps in Smalltalk.

An Introduction to Seaside was not available at Amazon so I ordered it through www.lulu.com, and received it in about 6 working days. The book is reminiscent of the original Smalltalk series of books complete with half tone boxes containing useful code (see image) which brought back lots of memories for me. The flow of the book is well structured and the links and references are very useful, like where to download a copy of Smalltalk for your platform, complete with a working set of Seaside libraries. I chose the Squeak download since most of the examples that detailed what to do in a Smalltalk environment target Squeak.

Some of the grammar in the book was a little wrong and I felt that the book could have been translated from another language into English, but none of the instances detracted from the introduction and instruction.

The book takes you through the development of a ToDo application which is a simple task but one that touches on all the things you may wish to do with a Web App these days, like security, persistence and Ajax support. I would have liked to see more information on testing but there are some solid links to the Smalltalk test frameworks.

Seaside itself is fantastic and I enjoyed working with it more than any other framework I have used so far for Web development, even those like Rails and GWT. The use of a ‘continuations’ approach to the web conversation and the real object oriented focus which you come to expect from Smalltalkers makes it a pleasure and *very* productive. If I had time I’d port it to other languages as a community service, since everyone should be able to develop Web Apps with this simplicity and productivity.

Should you want to know more then I encourage you to read A Quick Trip To ObjectLand to quickly understand Smalltalk and An Introduction to Seaside to understand Seaside. Give it a try, you won’t regret it.

In 2000 Australia was buzzing because we had the Olympic games, and I was buzzing too but not because of the games. I was about to fly to Sydney to pitch to Macquarie Bank for venture capital for my new idea. The idea was for a technology to enable two systems to communicate more easily without requiring additional programming. In a nutshell it sent Smalltalk between the client and the server in a similar way to how JSON works now. I even had a demo where you could speak commands into a microphone, they were converted to Smalltalk, sent to the server and the response came back and was spoken to you. I learned an important and expensive lessing during this time, that describing ideas with or without a prototype is hard, and that VC’s are more interested in what technology enables than technology itself. Aside from that I wish I could have described my idea in such a way that the audience just “got” it, and I could have if I had read “The Back Of The Napkin, solving problems and selling ideas with pictures” by Dan Roam before hand.

“The Back of the Napkin” presents a process for breaking down your thoughts, seeing their relationships and a framework for selecting the right diagram to best represent those thoughts when showing them to others. There is even a section on how to give the pitch once the thoughts and diagrams are ready, including a detailed example from start to finish involving a Software company and it’s lagging product. I think this example in itself is worth the cost of the book.

Dan presents ways to better ’see’ problems and discover your ideas, the SQVID process which is a series of five questions that refine our idea and bring out what is important to us and our audience, and  a process for developing and showing those ideas. It is easy to read and entertaining.  I think “The Back of the Napkin” is another one of those books I wish were mandatory reading at school since the process and framework could have served me so many times when I needed the audience to just “get” my idea.

I have finished reading The Rails Way, by Obie Fernandez and it was an excellent read, covering all the aspects of developing web applications in Ruby with the Rails framework that one could want in an introduction. All the parts are covered in some detail, and I think it would be hard to find something you would need to get a Rails Application done that is not covered. However, a little more detail on Production Web Server tools and deployments would have been nice and maybe that is covered in the Second Edition of the book. The Sections are logical and the examples clear and useful, with lots of sidebars outlining Ruby and Rails idioms and the thinking in the community which adds a realism balance to the theory. I have not been coding in Ruby long enough to comment too critically, but I would say this is a good book to have if you are planning to ride the rails.

The title of this post comes from chapter twelve ‘The Trouble With Rules’ of the book Maverick! by Ricardo Semler which details the unusual but common sense approach to Business adopted by SEMCO.

SEMCO threw away the traditional Business structures and rules and were much better for it; they believe that “with a few exceptions, rules and regulations only serve to:

1. Divert attention from a company’s objectives.
2. Provide a false sense of security for executives.
3. Create work for bean counters.
4. Teach men to stone dinosaurs and start fires with sticks.

The desire for rules and the need for innovation are, I believe, incompatible. (Remember, Order or Progress.)  Rules freeze companies inside a glacier; innovation lets them ride sleighs over it.”  You may feel rules protect you but “a turtle may live for hundreds of years because it is protected by its shell, but it only moves forward when it sticks out its head.”

This common sense approach to Business may sound like heresy or lunacy to some, but a local innovative and progressive Australian company is trying a new approach based on learnings from SEMCO and other places. That company is Cogent Consulting.

At the Agile 2009 conference in August 2009, Steve Hayes from Cogent Consulting will hopefully be presenting Creating an Agile Company (link requires registration). The following is the synopsis of the proposed talk, and if you can make the conference and Steve is presenting then you will find Steve a really good presenter:

Many agile practitioners feel dissatisfied with traditional organisational structures. This report describes a consulting and development company created specifically for a group of experienced agile developers, and whose values and principles:

• Transparency
• Equality
• Flexibility
• Shared Rewards
• Get the Right People on the Bus
• Leverage time
• Maintain control

This experience report will cover the motivations that led to the formation of the company and the practices used day-to-day.

 Process/Mechanics

 Keynote presentation covering the following points:

• How traditional companies are anything but transparent
• The existence of alternative approaches - Semco, open book companies, Alfie Kohn (“Punished By Rewards”)
• Why you need to walk the walk, not just talk the talk
• How different people have different needs, financially and emotionally
• Why systems to reward people are part of your core business
• How we handle our money
• How we set salaries
• How we did staff reviews
• How we hire people
• The downsides of all this

 Learning outcomes

• Understanding how companies like this differ from more traditional companies
• Understanding of the motivation for creating a different sort of company
• Appreciating whether or not the company’s values and principles are consistent with agile values and principles
• New ideas on how to establish a company consistent with agile principles

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 ?

Have you ever wanted to hear ‘Yes’ rather than ‘No’ to a question you have asked ? I’m guessing you just said ‘Yes’, which shows me that reading the book “The Science Of Influence, How to Get Anyone to Say “YES” in 8 Minutes or Less“, by Kevin Hogan was worth reading, and it probably is for you too.

The book helps you to communicate more effectively by helping you understand the many complexities of communicating. Complexities like verbal, non-verbal, time, place, tone, pace and peoples behavioral patterns are all taken into account and explained. The book also covers what to do when someone has said ‘No’ before or the equally disappointing ‘Ill think about it’.

I read this book because I want to be a more effective communicator in my role as a change agent, introducing Agile development practices in new organizations, but I could use these techniques everyday, wherever I want to get a ‘Yes’. However, I believe the techniques not assist me in winning and argument with my wife, not even after reading Chapter 10.

he book was an easy read for me, with an appealing size type and what felt like a logical sequence of chapters. Here is the Table Of Contents:

1. Influencing Others to change
2. The First Four Seconds
3. The Delta Model of Influence
4. Credibility: The Pivot Point of Persuasion
5. The New Principles Of Influence
6. Introduction to Omega Strategies
7. Framing Principles, Persuasion Techniques, and Influential Strategies
8. Applying the Laws of Influence
9. The Influential Secret of Oscillation
10. Mind Reading: How to Know What They Are Thinking
11. I’ll Think About It
12. How Their Brain Buys …You!

The book has key questions and call outs to throughout the book which serve to drive home a point and I found myself making a list for quick reference later. Here are a few as an example:

Nothing persuades like credibility in people’s decision-making process.

When faced with too many choices, most people can become paralyzed and do nothing at all.

The brain makes stuff up out of thin air to fill in the blank spots.

What people say and think they will do bears little relationship to their actual actions.

How we dress in large part determines how much people will trust and like us.

Recently I have been reading a lot of books about interaction design, prototyping and negotiations and one book in particular Designing Interactions, by Bill Moggridge is a absorbing read, especially if you want to read about the pioneers of User Interfaces and devices as well as the various techniques they use. You name a pivotal person in the field of Computer interaction and the book covers them and their crowning achievements. There are also a lot of places where Smalltalk is mentioned. Oh how much we owe to that time and that language.

To give you a taste I’ll quote the section that interviews Bill Verplank who drove interaction design to new levels during his work at Xerox from 1978 to 1986 on the Xerox Star graphical user interface. I like this section in particular because it draws out what an interaction designer is all about. Even if you have a passing interest in interaction design, I think this book is worth getting.

From the book:

Bill says that the interaction designer has three questions to answer; they are all “How do you…?” questions.

1. “How do you do?”

How do you affect the world? A human, a person that we are designing for, does something, and we provide affordances. We either present handles that they can continuously control, or we give them buttons for discrete control, pressing the button and giving up control to the machine. When you are designing the way people act, there is a choice between handles and buttons. You can grab hold of a handle and manipulate it, keeping control as you do it. Alternatively you can push a button, or click one, delegating control to the machine.

2. “How do you feel?”

How do you get feedback? McLuhan made the distinction between what he called “fuzzy,” or “cool,” media and “distinct,” or “hot,” media. Early TV was a cool medium, with its fuzzy images. Cool media draw you in. A book with careful printing or a gravestone with carved lettering is hot, or immutable–you cannot touch or change it. We design the way that the machine, or system, gives feedback to the user, or the book looks to the user, or the sign communicates. That’s where a lot of feelings come from; a lot of our emotions about the world come from sensory qualities of those media that we present things with.

3. “How do you know?”

As we design products with computers in them, it is very difficult for a user to know exactly what they are going to do. A map gives the knowledge that you may need if you are designing complex systems. A path offers a kind of understanding that is more about skill and doing the right thing at the right moment. It is the responsibility if the designer to help people understand what is happening by showing them a map or a path. The map shows the user an overview of how everything works, and the path shows them what to do, what they need to know moment by moment.

This section continues to build upon this by talking about Interaction Design Paradigms and Process and ends with a good example of applying these.

This is just one of many inspiring sections that let you get into the mind of the people who created the tools and interfaces we use today.

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.

A friend asked to borrow some books on Smalltalk and I went to the shelf to get them and found this …

Daisy, the naughty pug, had taken a like to Smalltalk, which is understandable, since it is a simple and marvellous language and environment. However, her method of consuming the information is not one I hope she continues.

Below is a picture of Daisy (top), resting after a belly of Smalltalk information. I asked her if she ate the book and she just twisted her head in a “not me” motion. Gretel her sister is much better behaved, but if she were to eat books, I think she would be more of a Lisp girl.