Mocking up your objects with EasyMock #test #junit #xp #tdd

I’ve recently been using EasyMock to create mock objects to pass in my JUnit tests, and I often find that I often mock up objects for private members which are auto-wired or injected by the platform, and in some cases are unrelated to the code I unit testing. Usually it is too expensive to run a full environment of middleware for testing, and it is also necessary to test the exception handling code which will most likely not be called unless it is specifically mocked.

So I wrote the following function to insert a mock object into a private member:

public <T> T insertPrivateField(Object instance, Class<?> targetClass,

        String targetFieldName,

        Class<T> mockedClass) {

    T mockedObject = null;

     try {

        Class<?> clazz = Class.forName(targetClass.getCanonicalName());

        Field field = clazz.getDeclaredField(targetFieldName);

        field.setAccessible(true);

        mockedObject = EasyMock.createMock(mockedClass);

        field.set(instance, mockedObject);

        } catch (Exception e) {

         log.error(e.getMessage(), e); // logs exception with log4j

        fail(e.getMessage()); // junit failure generated

    }

     return mockedObject;

}

Have fun with it.

    

Continuing Our Solitary Existence #xp #agile #scrum #programming

It’s thought that programmers have a solitary existence, in hacker movies they are often depicted as being behind a screen in the dark working on their own. Even the popular media images of programmers that are loners. As any programmer knows this is far for the truth, collaboration mostly benefits development. Sharing tasks and bouncing ideas of other developers makes the end products better. Yet with the exception of discussions the actual development task is performed by one person behind one computer.

There are many studies which show that there are even better ways to work, collaboratively create and discuss. Taking all the benefits of working as a team and sharing knowledge reduced to one continuous process rather than incremental tasks. It’s called pair programming, and studies have shown pairs can deliver 127% of what they deliver working on their own.

Meetings and more meetings #scrum #agile #xp

In a recent Popular Science article Science Confirms the Obvious a number of studies are examined on some seemingly obvious subject. I’ll leave the discussion on the value of the studies to the article and focus on the result of a study on Group Dynamics: Too Many Meetings Make You Grumpy.

Meetings are usually seen as an interruption in to the work which needs to be done. Meetings can often be complementary to the work which needs to be done, whether it is in defining the tasks, the path or the result. Meetings can be a good way of getting the team aligned, and days chock-full of meetings cuts into time which can be more effectively directed at tasks. They are sometimes seen as a team building exercise, and although brainstorming no holds barred meetings are part of a creative process they are also few and far between.

While brainstorming on this I realized that this is also an example of role-based actions, as I discussed in my review of the Lucifer Effect. The system here is not a prison, as in the Stanford Prison Experiment, but the office environment. The roles are directors, manager and staff. Is holding meetings what is expected from these roles?

What’s the solution?

“Organizations [should] be sensitive to the number of meetings employees are required to attend,” is a suggestion from the researchers and “formal guidelines” for meetings. Which means setting a agenda before the start of the meeting and sticking to it. Time boxing is another effective way of reducing the time spend, time box the agenda items and the whole meeting. When there is a need for a longer meeting – > 1 hour – allow for coffee and/or smoking breaks.

Information Overload #scrum #xp #agile #risk

After reading the Newsweek article “I Can’t Think!” I started wondering what the consequences are in SCRUM and XP teams of information overload. In my experience of SCRUM and XP there is a lot of information exchange, including Pair Programming and Test Driven Development even more possible information sources are forming a threat to the developers.

One of the best examples of my own experience is when I was working with ESB platform and Java Messaging (JMS). I had had no experience with the former and a reasonable amount of experience with the latter. I was asked to explain the inner workings of the software package I had had little experience with. The answer: “It does some magic, with a secret sauce!” was not enough to counter the fears of the PO who had made the choice to use the software. This caused me to need to get far more information about a subject to be able to explain in layman’s terms what was occurring.

The additional information I needed to collect was a stone around my neck for the initial introduction and understanding of the platform. And with the benefit of hindsight I should have said that I needed to get a basic understanding of the platform before committing to the demands of the PO. The downside was that we needed to be able to estimate the User Stories, and an estimation of 100 was a little excessive.

Read more articles on Agile, SCRUM or XP…

This is an example of information overload caused by not able to put the learned information into a context. And there are a number of cases which of Information Overload which can occur in Agile methodologies that may cause teams to temporarily derail, as the article notes:

The brain is wired to notice change over stasis. An arriving email that pops to the top of your BlackBerry qualifies as a change; so does a new Facebook post. We are conditioned to give greater weight in our decision-making machinery to what is latest, not what is more important or more interesting.

Which in practice means:

• incoming mail, text or instant messages
• meetings
• too many search results
• other interruptions

As the article further notes:

Experts advise dealing with emails and texts in batches, rather than in real time; that should let your unconscious decision-making system kick in. Avoid the trap of thinking that a decision requiring you to assess a lot of complex information is best made methodically and consciously; you will do better, and regret less, if you let your unconscious turn it over by removing yourself from the info influx.

These are issues where the SCRUM Master is the gatekeeper to the team, and should factor in time in the day when these interruptions can take place.

Image source: Jerry Wong

Thinking of problems that don’t exist, and fixing them #agile #scrum #xp

Currently I’m developing something which has a learning curve, not so much because it is difficult to understand it, more because there are portions of it which seem illogical. I could delve into the issues I have, and this may become a more technical article, and that’s not what I want to discuss here.

The current project I’m working on has a reasonably complex business logic which it implements, adding to that a untried and unknown technology and it’s a receipt for a difficult sprint – meaning it’s difficult to correctly estimate the complexity of tasks within the User Stories. This makes it ideal for applying Test Driven Development. The advantage of TDD in this case is that an assumption is made when writing code, expressing this assumption in a test before writing the code makes it easier to verify this assumption.

Programmers, including me, are very good at “thinking of problems that don’t exist, and fixing them.” Test Driven Development gives me the advantage that I can express my expectations in a test, and assert the requirements which need to be met for a test to pass or fail. In this way I can postpone the fixing of this fictitious problem until the time that an issue occurs.

Read more articles on Agile, SCRUM or XP…

An added advantage is when issues occur. Programmers – like me – are often focused on the details of the implementation, which means that we will see potential issues and blame side-effects of the current code rather than focussing on the issue which is occurring. Creating incremental tests as evidence that the code is working correctly can help bolster your position and support your argument that the error is outside your code, it also has the advantage that other developers will immediately see that their changes are causing side effects. This is far more effective than creating a one-time proof.

Image source: Jerry Wong

Bad Sprint: What next? #scrum #agile #xp

I’m sure you’ve had the feeling on the last day of the Sprint that the way it went was awful:

• build environments broken for
• User Stories were badly estimates
• team members who had troubles
• team members were stressed about completing their User Stories
• new team member
• Project Owner wasn’t available
• not enough story points completed
• User Stories left uncompleted
• etc.

Let me put you out of your misery, it was worse than you think. 😉 As the Scrum Master you probably feel bad, just think how your team feels. Like you they are now possibly demotivated and doubting themselves, and however much it was their and your fault it is now your task as Scrum Master to help get your team back on track.

Who’s going to motivate me?
—Anonymous Scrum Master

To answer that question you must realize that only you can motivate you, and that goes for your team too. Your task is not to motivate them, but to facilitate them to motivate and trust themselves and each other. There are many methods which can be used to achieve this, and I invite to to explore these to motivate yourself so you can motivate your team to become the best Scrum team.

Read more articles on Agile, SCRUM or XP…

Now it’s up to you and the team to align the team to the next Sprint, and complete the next Sprint with a win.

Basics About Employee Motivation (Including Steps You Can Take)

Image source: Jerry Wong

Scrum: Story Points for Bugs #agile #xp

As I mentioned before I mostly work in an Agile Scrum environment, with a little eXtreme Programming thrown in. This week I saw some messages go on the Scrum Development list by asking about assigning Story Points to bugs. There were some good opinions going by, and I hold to the idea that bugs fall into two categories:

1. Programmer Errors
2. Missed Requirements

The first is unavoidable, although they can be reduced with automated testing based on the User Story and Unit Testing of the underlying code.

As a users I want to move relations to a company

The second is an issue for the Project Owner, when the PO describes the User Story and leaves out certain requirements I believe that those are out of scope for the User Story. I’ll give an example of a User Story right.

The PO might neglect to add that the user might want to create a new company or a new relation in this flow and actually meant to word the User Story below. And naturally a User Story as in the example is still acceptable when the PO adds the requirements to the User Story description.

As a users I want to add or move a new or existing relations to a new or existing company

It’s also a task of the Scrum Team Members to ask the questions which will uncover these deficiencies in the User Story, so that deficiencies in the requirements are avoided.

Read more articles on Agile, SCRUM or XP…

Image source: Jerry Wong

A catalog of this year’s risky articles #2010

Risk is something which can be difficult to evaluate for the average person, there is a lot of work which goes in to learning not to do the two things that people usually do when they are confronted with risk:

1. Ignore
2. Overreact

Facebook is the new Portal for Insurers and Banks #social #finance

It looks like every man and his dog needs to have a Facebook page, even banks…

@Google and @FaceBook battle over the back of @FriendFeed? #social #feedburner

It has been almost 1.5 weeks since Google’s FeedBurner removed the Frie…

Prosper allows loans to fund Kiva projects #microfinance

Some days ago I tweeted to Prosper, a personal loan marketplace, whether they…

Social Revolution – Do You Get It?

I don’t really think most people get “it” when it comes to …

Secret Google campaign against Hyves? #social #networking

Just noticed that Google Translate translates the name of the Dutch social ne…

Company Policy or People #hr

I find a 400 plus page manual of office policies and job descriptions for eac…

Social Media Syndication – Feedback Loop

In the last two days I’ve not been posting so much, and focussing on up…

Google Scribe – Ye Shall Know Them By Their Fruits #google

I started playing with Google Scribe and wanted to see if patterns emerged so…

@Google, please stop with the language! #google

I have my Google account set up with English as the preferred language, my br…

Did The LinkedIn Certificate Expire Again? #linkedin

For the last 2 years LinkedIn has been running a bad poor IT management depar…

Advert: Reserve your Agile/SCRUM Pack #scrum #agile

When I just started I too had trouble with getting all the items I required t…

GMail Quota and Statistics (follow-up) #google #gmail #dashboard

On August 11th 2007 I exceeded my GMail quota, I blogged about it here. At th…

More SMS banking by M&T #sms #bank #risk

Brian Szymanski send a reply to me concerning another bank implementing SMS b…

Solving the URL shortening problem #twitter #tweet

I don’t understand why url expansion after url shortening is such an is…

Is RevTrax violating FaceBook privacy policy? #facebook @RevTrax #privacy

I just read an article Web Coupons Know Lots About You, and They Tell in the …

China acquires more than China… #hacks

This morning/night China’s networks were sending rerouting messages to …

Implementation of Security #risk

The lack of trained and experienced computer security people working in small…

ING reveals names using account numbers #bank #risk

Last week I saw an episode of a popular Dutch Ombudsman program Kassa, they r…

Musing: Why can I fly solo?

After seeing a program about a lifecoach trying to find the time to get his p…

Image source Radio Nederland Wereldomroep

This year’s book reviews #2010

As always I read far more in 2010 than I blogged about, and most of the books I did blog about were treasures. I hope I inspired you to read at least one of them. And you have certainly noticed that I have added them all to the bookstore to make it easier for you to find out more about them.

Twipping Point #twitter

I’ve had this title in my head for about a week now, the title is natur…

Just Finished Reading: “Islands in the Net” #wikileaks #books #datahaven

I’m reading Bruce Sterling‘s Islands in the Net – Amazon de…

xkcd: Online Communities

As followers of mine will know I love xkcd, and he has some gems such as this…

Just Finished Reading “Amsterdam: The Brief Life of a City” #books

I read Amsterdam: The Brief Life of a City by Geert Mak in English rather tha…

Just Finished Reading “Star Wars” #books

I’ve seen the film more than a dozen times, but I had yet to read Star …

Just Finished Reading “Redwall: Outcast of Redwall”

Brian Jacques‘s book Outcast of Redwallfollows Veil the ferret who is r…

Just Finished Reading “The Odessa File” #books

The Odessa File, by Frederick Forsyth, is another of the books I am keeping s…

Just Finished Reading “Redwall: Martin the Warrior” #books

Brian Jacques‘s book Martin the Warrior is another book from the Redwal…

Just Finished Reading “The Moon’s a Balloon” #books

I found The Moon’s a Balloon, by David Niven, in a box of old books. I …

Just Finished Reading “Redwall: Mossflower” #books

Mossflower by Brian Jacques is probably my favourite of the Redwall series, t…

Turn on, tune in, drop out: Personalised Online Education – Introduction #school #education

Timothy Leary once told us to “Turn on, tune in, drop out“, and a…

Just Finished Reading “Rosalind Franklin: The Dark Lady of DNA” #books

For some reason I had the book Rosalind Franklin: The Dark Lady of DNA, by Br…

Just Finished Reading “Hitler: The Last Ten Days” #books

After having seen many films and read many books I expected that Hitler: The …

Thor the #Movie

One of my first real American comics was Thor, I really liked it. Sadly it re…

Just Finished Reading: “Wikinomics” #books #ontogenesis

I like Ontologies, Taxonomies and Folksonomies. I’m currently reading W…

Just Finished Reading “The Godfather” #books

I read Mario Puzo famed book The Godfather after having seen the movie a numb…

Just Finished Reading “Anathem” #books

As I previously said I bought Anathem at the same time I bought Cryptonomicon…

Just Finished Reading “Young Winston” #books

I borrowed a number of books from an aunt of mine, who reviewed these books f…

Just Finished Reading “The Big Yin” #books

I was standing in a secondhand book store with my father, and we wandered rou…

Just Finished Reading “Cryptonomicon” #books

As an early Christmas gift my father gave me vouchers he didn’t want to…

Just Finished Reading “The Snake”

The Snake is the first book I have read by John Godey, it was recommended to …

Just Finished Reading “Scrum and XP from the Trenches” #scrum #xp

In the company I work for they are introducing the Agile FrameWork, in the fo…

Image source: Honou

The Structure of a Daily Scrum #agile #scrum

The only questions that are asked in the Daily Scrum, aka Stand-Up, are:

What did you do yesterday?

What will you do today?

Are there any impediments in your way?

As a Daily Scrum lasts at absolute maximum 15 minutes and this rule is more important than answering any specific questions on any of the subjects or issues raised. The daily scrum is not for resolving problems, those three questions provide an update to everyone involved on the Sprint status: What is important for the next 24 hours as a team?

Any discussion should be done in a self organizing team in follow-up meetings to have these discussion with everyone involved in the task, it’s usually that people are working on separate tasks, so in this way anybody in the team who doesn’t need to be there can go about their business. Sticking to the specifics and having a team board to point at task cards and stories helps to keep the focus. The purpose of the Daily Scrum is to allow this self organization to take place, and the 15 minute timebox leaves 23 hours and 45 minutes per day.

One of the issues in not respecting the structure of the Daily Scrum is that it makes job of Scrum Master slighty harder, after all it’s up to Scrum Master to stop it on reasonable level of details. The Scrum Master should ask: “Why don’t you continue that discussion after the standup?” The structure also allows every person, the extrovert and introvert to speak without too much discussion.

Simply said the Daily Scrum should allow for quick statusing, and identification of need for more in-depth interaction. It’s not the perfect, sole venue for team interaction.

Read more articles on Agile, SCRUM or XP…

I saw a question posted on the ScrumDevelopment hosted by Yahoo! Groups: Does daily scrum has to have so rigid structure?. Above are a mash-up of the answers and thoughts I thought were relevant, with my own comments.

Image sources: Michael O’Connor, Jerry Wong