0

The psychology of physical agile boards

28

 

Is now widely accepted the usage of online collaborative tools to manage a team’s tasks and progress. Is common to see teams fully taking advantage of Jira, Trello, etc. As someone asked here in stackoverflow :http://stackoverflow.com/questions/20090309/a-completely-free-agile-software-process-tool, if you also want to know which tools exists for managing agile teams, the this is not the place, search in google :)

While I think this is a great way to manage a agile projects and the work a team need to complete, especially when remote team members are involved, I also believe that we are loosing some of the most important benefits of the agile practices, the sense of urgency, commitment and motion. If you can’t see what’s going on all the time, then you have to force yourself to focus your attention to what’s going by constantly using your brain.

Using physical visual boards, forces the team to focus on what is important and they are reminded constantly where they need to focus. Who want’s to know what is going on? Just walk the room and you will have an immediate feeling of the progress.

Doing these kind of boards, with the post its, is the best way to promote communication between the team and the organisation.

When a team member walks the room, even if he/she don’t want, the unconscious mind will take pictures of these boards and he/she will carry these pictures around, ever without being aware of that.

 

 

10

Hey, did you know Java is a typed language…?

Hi,

Java is a typed language (Duuhh!!!), it means that we can create new types like:

public class User {
    private final string name;

     public User(String aName) {
         this.name = aName;
     }
}

And we can later on bring Users live into our virtual world, that is our app. If our app deal with objects and their interactions, we should care that those objects are of a given type, that’s why we define our app’s blueprint (java code, for that matter).

If my app has two users, somewhere in my code I’ll find something similar to this:

User userJon = new User("Jon");
...
User userDoe = new User("Doe");

I’m bringing those two Users live and hold a reference to them, so I can control their behaviour :). These references are of a given type, and I can figure out what I can do with them when in my hands.

Knowing object’s type is pretty nice because it expresses better the thoughts in code, easier to read, indeed. For me that have bad a memory is great to remember :)

Now, my model evolves and my customer is telling me that a user has many friends, that are also players in the virtual world!! I start to model something like:

public class User {
    private final string name;
    private List<User> friendsList = new ArrayList<>();

     public User(String aName) {
         this.name = aName;
     }
     ...
     public List<User> getFriendsList() {
         return Collections.unmodifiableList(frinedsList);
     }
}

Clients of the User type can interact with the reference like:


   List<Users> userFriends = user.getFriendsList();

P.S. – Java 7!

Pretty straight forward! User’s clients know that when they send a message to a user object they will receive a list of users, and the client code defines meaning for that list of users as being the friends of the user, using the name userFriends for the reference, for that matter. Later in the code, the client may use this reference, and when it uses it knows the context of that list of users, it’s a list of friends, duhh!!

Now, other guy may write this code:


   List<Users> user = user.getFriendsList();

It’s still ok, but… later in the code the only context I would infer immediately from this reference is that is a list of users but and it represents??? oops, I lost my self in a loads of complex code, give an help for the maintainer please!! :)

Getting things worst, in pre generics era, I would model something like:

public class User {
    private final string name;
    private List friendsList;

     public User(String aName) {
         this.name = aName;
     }

     public List getFriendsList() {
         return Collections.unmodifiableList(friendsList);
     }

}

And later in my code, getting the user’s friends would look something like:

   List users = user.getFriendsList();

Now, I completely lost. So, have a list of objects but hey, their type may be users, since the name of the reference is trying to give a hint, but it may be wrong…who knows? This code knows:

   Object obj = users.get(0);
   if (obj instanceof User) {
       User = (User)Object;
   }

Getting back in time!!!

The point here is that the Java language has evolved it’s type system, so will I!

I would prefer to model something like this:

public class User {
    private final string name;
    private FriendsList friendsList = new FriendsList();
    public User(String aName) {
         this.name = aName;
     }
     ...
     public FriendsList getFriendsList() {
         return friendsList
     }
}

public class FriendsList {
    private final string name;
    private List<User> = new ArrayList<User>();

     public FriendsList() {
     }
     ...
     public Iterator<User> getFriendsListIterator() {
         return friendsList.iterator();
     }
}

Now I have context everywhere. Since Java is a Strongly typed language, let’s use types. What you think?

1

Scrum talks with Mike Cohn

Mike Cohn, from Mountain Goat Software, gave a series of talks on Norwegian Developers Conference 2012 about Scrum and Agile. I’m sharing the videos here. It’s worth to take a closer look for anyone taking agile and SCRUM seriously.

Getting Agile with Scrum

Leading a Self Organizing Team

Agile estimating

Advanced Topics in Agile Planning

Scaling Agile to work with a Distributed Team

User Stories for Agile Requirements

2

I’m dropping Camel Case convention

I was watching a video about BDD and decided to try the technique with an exercise. What is happening is that I’m starting to question the Camel Case convention. After a couple of lines of code I have something like:

public void shouldHaveFirstTransitivePropertyOfInequality() {
		assertTrue(valueUnderTest.compareTo(valueExpectedToBeBiggerThanExpected) < 0);
		assertTrue(valueExpectedToBeBiggerThanExpected.compareTo(anotherValueExpectedToBeEvenBiggerThanExpected) < 0);
		assertTrue(valueUnderTest.compareTo(anotherValueExpectedToBeEvenBiggerThanExpected) < 0);
	}

Full sentences in the method names. Yeah, it specifies the expected behaviour of the unit under test, but the question is about readability now.

I tried to remove the camel case to see if the readability improves, and also because I’m not a Lazzy Programmer

public void should_have_first_transitive_property_of_inequality() {
	assertTrue(value_under_test.compareTo(value_expected_to_be_bigger) < 0);
	assertTrue(value_expected_to_be_bigger.compareTo(value_expected_to_be_even_bigger) < 0);
	assertTrue(value_under_test.compareTo(value_expected_to_be_even_bigger) < 0);
}

I’m feeling good with the readability improvement, so I will drop Camel Case in my BDD exercises.

One concern I had, when started this BDD exercise, was about the length of the name for objects, fields and methods. Yes, it may look a little odd at first (ohh, the guilty of breaking conventions!!), but like everything else in life, also this code may turn to be better than what I have today. My goal is to improve readability and not follow a convention.

The video is from Dave Astels (http://techblog.daveastels.com/) and is here: http://www.youtube.com/watch?v=XOkHh8zF33o

3

Inheritance in JPA Entities

“..but equals should usually compare state, not identity. This is particularly true for “data-centric” classes which map to database records. […] If you extend a concrete class, and add a new field which contributes to equals, then it is not possible to write a perfectly correct equals method for the new class. Instead, you should use composition instead of inheritance. (See Effective Java by Joshua Bloch for more information.) ”

From http://www.javapractices.com/topic/TopicAction.do?Id=17

This can be interpreted as “It’s not a good idea to use inheritance in, for example, JPA Entities. It’s better to use composition”.  I tend to agree. Deep hierarchies of JPA entities,  can be a daunting task to understand, maintain and extends. Having small hierarchies, I think it’s ok. If a JPA model, most of the time models real world concepts, and if real world concepts are better described in terms of composition, instead of inheritance, why complicate things? Take the typical Car exercise, would you model most of your car using inheritance or composition?

But if  you’re  modelling your JPA entities with object oriented principles , not caring about the mapping stuff, for now, everything that you will need to store in a DB are value types, like Integer, Long, String, byte[], or some composition of these and other value types, so there’s no point to inherit just to add values to an object, it’s better to create a new value type that represents the concept.

2

Mutation Testing with PITest and JUnit

What? More testing? This time are the tests for your tests. Mutation Testing analyses your code, and based on some heuristics change it to try to “kill” your tests. If if can kill all your tests, then your tests are probably fine, otherwise maybe your coverage it’s not as good as you may think. PIT is a framework worth looking, since it integrates with maven and seems to be maintained. http://pitest.org/

Just use the maven plugin to try with your maven projects and see the results.

There are other tools for mutation Testing with Java and JUnit, but did not try:

http://jester.sourceforge.net/
http://jmute.sourceforge.net/
http://jumble.sourceforge.net/