jamesladdcode.com

Said the Test Driven Tortoise one day to the Hackey Hare:
“I’ll run you a code race if you dare.
I’ll bet you cannot
Arrive at that production spot
As quickly as I can get there.”

Quoth the Hackey Hare: “You are surely insane.
Pray, what has affected your brain?
You seem pretty sick.
Call a doctor in–quick,
And let him prescribe for your pain.”

“Never mind,” said the Test Driven Tortoise. “Let’s run!
Will you bet me?” “Why, certainly.” “Done!”
While the Test Driven Tortoise creeps,
with Tests, Continuous Integration and
customer speaks, Hackey Hare makes four leaps,
And then tells all how soon he’ll be done.

It seemed such a one-sided race,
To win was almost a disgrace.
So he hackily coded about
until the bugs inevitably came out –
As the Tortoise was nearing the place.

Too late! Though he sped like a dart,
the bugs hard to start
The Tortoise was first. She was smart:
“You can surely code fast,”
She remarked. “Yet you’re last.
It is better to get a good start.”

Adapted from Jean de La Fontaine’s poem: Hare And The Tortoise

A corollary to this fable is another version http://www.jobcyclone.com/articles/haretortoise.php related more to business that sees the hare winning, however, the key to this version is “fast and consistent”. It is rare to find someone that is both fast and consistent without using techniques like Test Driven Development and Continuous Integration which support going as fast as you can as consistently as you can.

If you want to win the race you should start with TDD and CI.

 I’m sitting at a cafe at 8am sipping a nice coffee while I write this. You may not find this very exciting but for me is it quite out of the ordinary as I usually spend this time with my wife and twin sons. Would you find it exciting if I was to tell you that I would reveal a single little thing you can do to your code that will improve it for you and for everyone else that uses it?

With the one piece of advice I’m going to tell you how to reduce the amount of code you write so you can keep your code dry’er , do things quicker because you are doing less, and make  your code more readable and a better match for your domain. Does this sound too good to be true?

The advice is to never use a primitive collection as a domain object. To be clear this advice also means that a primitive collection cannot be exposed outside of the containing Class.

What I usually see in code is the use of a primitive collection to represent a domain model concept or in place of a proper class. I guess this is usually done because it is thought to save time or that this is what these types are for. The code looks like this (in Java for the masses):

List<Account> accounts;

for (Account account : accounts) { do something with account } 

The key point of the advice is the use of “List<Account>” should only appear in the definition of a Class called Accounts. Try this advice and see positive benefits for yourself.

After this advice is applied the Accounts class then represents a concrete concept in the domain which was missing before, although it was implied. Accounts can now have methods that represent domain concepts and they will exist in a single place, not scattered or duplicated throughout the code.  Want to know what business happens with a collection of Accounts, just look at Accounts.

The advice applies to more than just primitive collections but I thought I would start there as they represent a common usage. The advice can also be applied to less obvious collection types like File. For example, don’t just use a File object but subclass it and name the class to represent what is in the file, giving more meaning to “File” and the things that you want to do with that file.

This advice is not just for Java programmers, although most of the code examples around promote this primitive approach. Many non-Java languages like Ruby have great support for collections but these too should not be used in place of a concrete class.

When I apply this advice to my own code (in Ruby, Smalltalk and Java) the result is more meaning in the model and less code.  Please give it a try and let me know your experiences.

Imagine that we have discovered a new planet and the world has called upon you to make a plan for visiting this new planet with a probe to gather data about it. Where do you start?

This thinking about a problem is called Analysis and it is a very hard skill to master even with experience but it is essential when learning how to program. Every requirement you uncover requires analysis to further understand it, validate it and quantify it before you start to think about a solution.

Sometimes this analysis can reach a road block where you don’t have enough information to know something for certain. To get through these road blocks you need to get the information or make a choice to enable you to move forward. This choice is called an assumption and these are ok but you need to track them so you can validate them at some later point. An assumption that is not valid may invalidate your entire analysis and you may be in big trouble.

Teaching analysis is hard and I’m not sure that I have a good approach since it is about thinking and thinking deeply about a subject. The more experience you have with the subject the wider and deeper your thought can be. This is why experience is such a valuable asset. I’m not sure that I even have a ‘method’ of analysis but I do have what I think is a good exercise in doing analysis.

Most of you reading this post will have at some point boiled an egg, and if you haven’t don’t worry you can still do this exercise.  Without going through the process or searching a recipe book or the internet, write down each step you would take to make a boiled egg, and I mean every step. Along the way you may make assumptions about things and you should write down these assumptions to. I’ll give you one assumption to start off with, “You are boiling a chicken egg.”.  So make your list of steps and your list of assumptions.

I did this exercise and here is my list but please do the exercise yourself before looking at my list. After you have made your lists then look at mine and compare the two. Did you have the same steps? Did you have more or less steps? Did your assumptions  match mine? Did you find yourself thinking, “I didn’t think of that?” or “Wow, I’m not winning Masterchef.”.  I’d like to hear about your experience with this exercise so please send me an email.

The best part of this exercise is that we can test it by going through the steps we have outlined in order, one by one and seeing if we end up with a boiled egg. Often in the Business of software we don’t have this luxury and therefore we need to do analysis. The better your analysis the more confidence you can have that you understand the problem. Notice I talk about the problem and haven’t talked about the solution? It is very important to analyse the problem and requirements before thinking of a solution.

How’s your egg?

This is the second in a series of posts about how to program, and before I begin I should say that this series is probably more about how to be a Software Developer but I used the tag line ‘How To Program’ to catch the interest of the intended audience, School or University Students.

This post is about what is arguably the most important part of being a Software Developer, Requirements. A good Developer helps solve the problems that the Customer is trying to solve and gives you an experience-based opinion of all the risks along the way so the Customer can make informed choices, and none of this is possible if you don’t know what the Customer wants. After you know what the Customer wants you can then go through a process of getting as close to that as possible. When I say Customer, I mean anyone who interacts with you, as how well you interact with a Customer will shape your work life.

Whole careers are built around obtaining and understanding Customer requirements and I don’t profess to be the best person to provide information on how to get requirements, but I can tell you the techniques I have used with success.

Keep in mind that almost always a Customer will say what they want in terms of a solution they have in mind. For example, the School Teacher Customer may say “I want a web application that allows me to take attendance/roll-call.”, but do they really need a web application? Do they really need to take attendance/roll-call? How would you know, how would they know? Your task is to get to the bottom or most basic needs and problems of the Customer. Maybe they have the right solution in mind, but you won’t know if you don’t know the problems they are trying to solve. Maybe a barcode on each students forehead that is automatically scanned when they walk through the school gates is the solution? To make things more complicated the initial Customer may not be the only Customer and the solution may need to take others into account as well.

Ask “Why?” until you get to what is the root problem or need that is to be addressed. This is usually about five (5) Whys or when the Customer can’t reduce the need any further. Asking “why” needs to be done with tact and sympathy or asking why repeatedly could cause friction and then getting to the real need may become impossible.

Ask “How will having the requirement benefit them?” to find out what is required from another angle, the angle of satisfaction. This will help you understand the scope of the requirement and possibly the quality required in the solution. Sometimes finding out the benefit the Customer perceives they will get from a requirement can also bring out the real requirement or need. For example, a Customer who wants a faster Web Site might actually want a faster graphics card or faster Internet connection. The other advantage of asking how the Customer will be benefit from the requirement is that it can also bring out that the Customer isn’t the actual Customer for the requirement, in which case you need to find the other Customer. For example, we had the School Teacher who wanted a Web Application to take attendance/roll-call but it probably didn’t benefit them directly but is required as part of the process the School follows. So maybe the School Teacher isn’t the Customer, but the School Administrators?

I’m probably going to be a little controversial with this next statement, but it is something I feel strongly about and have had success by maintaining. If you can’t find a Customer who needs the requirement then it shouldn’t be a requirement. Every requirement should have a Customer who needs it and can define the satisfaction criteria for the requirement. You may have to look hard to find them but you know you have found them when you can say that requirement X benefits Customer Y directly because of Z.

In summary:

Ask why to uncover the real need or problem.

Identify the benefit(s) of meeting the requirement.

I recommend reading Jonathan Babcocks Blog http://practicalanalyst.com/ and Liz Keogh’s Blog http://lizkeogh.com/ for informative insights into Requirements.

The next instalment is Analysis.

Recently I worked on a Ruby On Rails Project using rake, rspec, cucumber and celerity and I really enjoyed this suite of tools. More recently I started a side-side Project that is Java based but I wanted a similar set of tools, especially Cucumber as this allows the other people involved to write scenarios that are then progressively implemented by others. Cucumber support for Java (and other languages) is available through the Cuke4Duke Project.

The out of the box examples from the Cuke4Duke project get you started but I wanted more, I wanted a Project that:

• Was automated, with unit-test, integration-tests and Web Based interaction tests.
• Was able to run against different Web Browsers through simple configuration.
• Was able to run without using a browser when this type of interaction took too long.
• Was able to be added simply and quickly to a Continuous Integration Server.
• Was a small initial download and didn’t require a lot of configuration or knowledge to get running.

I took the out of the box examples for spring and web driver from cuke4duke and combined them together with some Maven magic and produced a simple Hello World Web Application with almost all of the attributes I wanted.  I also added some placeholder classes, unit tests, integration tests and a cucumber scenario.  The Page Object pattern and the excellent PageFactory tools are also used to provide an example of driving the Web Application through Scenario Steps.

The goal of the Skeleton is to jump start my own and possibly your own projects using BDD and TDD and lots of automation to get you from A-to-B quicker and with more confidence in the result.

You can get the skeleton project from gitHub or download it here: maven-cuke4duke-jump-start
Or just do these commands:

git clone http://github.com/jamesladd/maven-cuke4duke-jump-start.git

cd maven-cuke4duke-jump-start

mvn -Dcucumber.installGems=true cuke4duke:cucumber

mvn clean integration-test

To start the project building and see it in action check the README file.

*NOTE* When building the maven project for the first time there is a *LOT* of cuke4duke dependencies downloaded, but just the first time. It takes a while, but only the first time.

And now the weird part, if on the first run the Cucumber steps fail, run mvn clean integration-test again. This also only has to be done once and from then on all work without error.

UPDATE: I have added maven profiles to the project so you can now choose which Web Browser to use to drive the web site, for example, -P chrome will use the Chrome browser. This is documented in the README.  With this feature you can configure your Continuous Integration server to run the build for each browser you support.

UPDATE: Added database setup and migration support using Liquibase and HSQL.

UPDATE: Added support for Cuke4Duke V0.3.0

I started my blog to capture solutions to development problems I encountered so I could get to them from anywhere,  and to share them with others.  I wanted a place to voice some opinions on software development, trumpet things I was doing, and to provide a place for people to learn. There have been a few posts in most all of the categories except maybe learning, until now.

Recently on twitter a person that I admire (Simon Harris) asked a question along the lines of “Who was taught programming in a way that didn’t start with writing code?” and I replied that I had.  I remember my Year 10 teacher Mr Frank Van-Den-Boom (forgive me if that isn’t the right spelling) started teaching us not by writing code but logic and analysis, then code.

This is the start of a series of blog posts is about how to program, and how to be a programmer. It will rarely touch on programming code - but don’t let that turn you off. There will be code but first there will be more important things which I hope you will grasp and take on board to assist you in becoming a programmer; or maybe if you are a working programmer it may assist you in seeing things differently.  Either way, I hope you follow this series and send me feedback.

I have received a lot of spam lately so if you want to email me comments you need to use my email and not this blog. The address is james underscore ladd at hotmail dot com and I’d be eager to get your comments.

Next instalment: Requirements

I was inspired by this post by Kent Beck to write a fan letter to Redline Smalltalk, written in the voice of a deliriously satisfied user. This is an excellent way of articulating a vision.

Dear Redline Smalltalk,

I have been using Redline Smalltalk at work and in personal projects for a while now and I just had to let you know what a joy it is to use and how productive I am with it.

My work situation means I have to work on the Java Virtual Machine and I have been looking at alternatives to Java so I could be as productive as possible and stay away from those little Java annoyances and hurdles that slow me down. Having a background in Smalltalk I jumped at the chance to put your Redline Smalltalk through its paces and I have to say I couldn’t tell the difference between your Smalltalk and the others, in fact I think yours was a little faster.

At home I like to use IntelliJ and your plug-in support in the IDE is brilliant, the mix of old style Smalltalk-80 browser, refactoring and file based support is smooth and complete and just what I needed, especially the source level debugging and profiling which I could not live without.  At work we use Eclipse and I can’t tell the difference between the plug-ins so now I’m getting a few other developers to try it, and I think I made some converts.

One developer at work, Steve, keeps banging on about how Ruby On Rails is this and how Ruby On Rails is that, how we need rspec, gem, rake, and how awesome it is to script things and try stuff out with irb. You should have seen his jaw drop when I showed him how I can do all that in Redline and how quickly I could create, test and deploy my Seaside Web App and then push changes to different environments with a simple commit, even while they were running. You really did think of everything to make things complete and integrated with Smalltalk everywhere.

I wondered what you could add in the next release and I just can’t think of anything but if I do, Ill be sure to let you know.

Thanks for a wonderful product that has really changed the way I work and made it fun again.

Regards,

John Q. Geek.

I consider myself to be a software craftsman as I strive to deliver software that fulfills its purpose, is easy for others to understand and maintain, and is supported by tests but being a craftsman is not required to be successful as a software developer so should you care about being a craftsman?

For a while I have been becoming a little disenfranchised with the notion of software craftsmanship because around me there are some products that make it to market and are successful, even popular, and yet under the covers the code is in my opinion (and probably in the opinion of craftsman) very bad. I have been disenfranchised because around me there are some developers that “appear” to not know or possibly not care about code that is easy for others to understand or maintain or supported by tests, yet they are hired and paid roughly the same as me. Certainly the “gap” between developer and craftsman in pay is negligible. I have been disenfranchised because the majority of companies creating software that I have worked with “appear” solely focused on getting the product out regardless of the underlying implementation, even if the current implementation and practices slow that delivery down, or effect the quality of the resulting product and the cost of maintaining it.

Getting the product out to the customers is a number one priority and I certainly agree with that, I would not change this priority as that isn’t realistic. This reality is why I choose to do things using Agile XP practices. My conundrum about software craftsmanship is not about a Utopian ideal or a desire to stop the world while I make everything shinny and perfect.  I don’t think I am alone in wondering about this situation. My conundrum is both of a personal and a professional nature. Personal in that I wonder if I should I care about learning and improving my skills and professional in that I wonder if I should say or do anything to instill craftsmanship on the projects I am on, especially when craftsmanship isn’t a necessity for success.

The answer or the path to it is intent. What is my intent in wanting craftsmanship? On one level wanting craftsmanship is selfish because I want to work with code that is well crafted and because I have worked hard to be able to produce well crafted code and I want you to do the same. On another level I would like to help others understand what makes well crafted code and the benefits that come from it. While this is still selfish the outcome can benefit more than just me. When working on a project my intent with craftsmanship is to create the most value possible.

I really like to write code and I will always look to improve my skills, it’s a passion that hasn’t wavered for the last 25 years.  When on a project I will be a craftsman and when the needs of the project demand deviation from craftsman like practices then I will put out a quick hack with a clear conscience.  Should I say anything when I see code that could use a little craftsmanship? This depends on what the team consensus is about its practices and if craftsmanship is aligned with the customer’s expectations, after all the Customer and delivery must come first.

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.

Gregor Gramlich presents his view on East here.