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?

There is a job add for a Smalltalk Developer to work on Pharo here and more here

Below is a rough translation by a friend, for those who don’t French.

INRIA is a Research Institute specializing in science and information technology (ICST) around communication.
It employs 3600 people in research centres spreads across seven regions.
The research centre in Lille (North of France) employs 260 people, spread across a dozen research and research support teams
The RMOD research team specializes in the development of dynamic object languages.

The chosen engineer will work on development and scientific experiments in one of the research teams.
He/she will work on the following: new infrastructure around a new compiler, improving network support, interfacing with C, improving the performance of virtual machines, improving object-runtime, improving code, improving the IDE.

The chosen engineer will participate in development and experimentation in a research team, leading to:
• software development: design, coding, testing, documentation
• participating in writing tutorials
• mailing-list animations (?!);
• integration of bugs (bug fixes?)

Skills and profile
• training in information technology and knowledge of software development and related bug tools (version management, compilation, documentation, testing, debugging,…);
• programming languages: Smalltalk, C;
• good knowledge of a dynamic language and in reflective (?) programming
• fluent technical and scientific English
• good writing skills;
• good-to-have skills: network, system, reflexive kernels

For more information, apply online through http://www.inria.fr/travailler/opportunites/ingenieurs/specialistes.fr.html
For more information on the role, contact stephane.ducasse@inria.fr
For information of an administrative nature, contact magali.lesaffre@inria.fr

I think this blog post should be mandatory reading for all developers: The Power Of Names by Glenn Vanderburg.

I want to work …

• with people who want to be great and do great things.
• on products or services that engender a positive value and experience for the user.
• in an environment that supports and promotes the exploration of individual and team potential.
• where success or failure are shared equally.
• in an environment where the above comes before profit.

I wrote this list because I’m looking for a good job and I want to be clear on what it is I want.  Does such a place exist?

(I’ll write about what I would give for such a role later).

UPDATE: 07/03/2010

‘before profit’ as a blanket statement is unrealistic as we all need to make profit, to take care of the things that are planned and those that are unplanned. The profit I am referring to is a push to continually make more money than the previous year in such a way that the people in the Company feel like labour rather than part of the Company.

I have been working on Redline Smalltalk (a Smalltalk for the Java Virtual Machine) for more than 4 months now and it really should be ready for people to try but it isn’t, and this post is to let you know where it is at.

When I started developing Redline Smalltalk I was creating a compiler from scratch and by hand and it was going to be really good. After several failed attempts I came to a realization that the approach I had taken was not going to work, essentially writing a bottom up parser by hand, rather than a top down recursive decent.  I even gave it a few redos and clean slate goes before coming to this conclusion. About the same time I got an offer of some code to help and waited for this to eventuate but I got ants-in-my-pants and wanted stuff happening so I wrote a translator to help Redline on its way. The translator is just about finished, with tests of edge cases the only thing that remains.

My plan now is to translate the Pharo Smalltalk source code into Java source code to form a base Smalltalk runtime, compiled to bytecode using the Java Compiler. This runtime which contains the Pharo Smalltalk Compiler will be modified to output Java Virtual Machine bytecodes rather than Smalltalk Virtual Machine bytecodes.  From here I will be able to keep the Runtime in step with the Pharo sources as well as advances in the Java Compiler and continue forward to make Redline something great.

This is not all talk and below is an example of a method from the Compiler class from the Pharo  sources before and after translation into Java by my translator:

Redline is still moving along and I appreciate all the interest and support and I will continue to keep at it until people can write Seaside Web Apps and deploy then with ease on the Java Virtual Machine, and more. Stay tuned for an announcement of the availability of the Redline Smalltalk Runtime.

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