Agile Development Lab

Have you ever seen a developer who’s good at what they do but would never really spread the knowledge to others? Well I have, plenty of them during my short career time. Some would argue that why they do what they do is to save their job since no one else knows what they do. Really, no one appreciates that. If I were the manager, I would let those kind go first. Knowledge is one thing that multiplies when you spread it. Help those around you who don’t know what you do. That’s the kind of attitude that contributes to rise of a team and eventually rise of the organization.

Learn, apply, spread/teach, make sure others apply too, and then repeat the cycle. That is the key to an efficient individual and collective development of a team.

Lean is not just for the manufacturing industry. Software industry has much to gain from it too. If applied smartly, it can improve processes and speed up the development time.

One of the principles in lean is to organize your tools to save you time. Place your tools and equipment at smaller distances to improve efficiency. Can that be applied to application development? Of course it can. As a matter of fact, to a great extent, it already is. If you have used eclipse before and are familiar with its shortcuts, isn’t that the same principle? Imagine refactoring in a notepad versus in eclipse. It’s like 10 minutes versus 10 seconds.

What else? Too many times, I have seen build processes being long and painful. Why not spend some effort up front and improve them? At the very least, why not put all the steps in a single script that every one can run before they go out to get their next mug of coffee? If you can save just 10 seconds of your daily process time, you can save up to about 40 hours the whole year. That means you can take a whole extra week off

There are countless other things that beg you every day for improvement. So go ahead, and do it!

As a test driven developer, how do you start writing tests for a class you’re about to write? Do you start with a top down approach and start with the behavioral kind of a test or do you drill down to smaller methods first and start there? That’s always a good debate. However, most often, there isn’t a single right answer.

For instance, let’s assume that you are writing a class for receiving payment information for a transaction. A pure top down approach would be to write a test for a simple transaction data and start coding. Any smaller methods that come out of your work should automatically be covered under you one test. And if your methods do not have a lot of decision points, you can get the class under test coverage with a small number of tests.

On the other hand, you may also break the class down into smaller chunks, whether in your mind or on a piece of paper, and start by testing the smaller methods first. You may come to the conclusion that to receive payment, the class needs to validate the date of birth. So you write the test and then implement the method. Next you may decide that receiving payment may also need credit card validation. Next, the reception of payment should also be logged and so forth. You write these lower level tests and methods first, and then use them at a higher level to achieve the class goal.

I personally do not like to stick to a single approach. Each class is different and should be treated differently. So for example, if there is a class without many decision points and seems like relatively smaller, I would always go with a top down approach to save some extra time spent on lower level testing.

However, for more complex kind of classes, I would do exactly the opposite since higher level testing in that case may easily cause you to miss a scenario.

Join Software Craftsmanship North America 2010 (SCNA) as a forerunner to the Craftsmanship movement!

CHICAGO, IL
OCTOBER 15-16, 2010

http://scna.softwarecraftsmanship.org/

Can agile principles be applied to a development team whose members are scattered geographically? Although its better to have all the team members in the same room, its still possible to be agile while being remote. Let us discuss and compare a few agile principles in the two kinds of teams.

Pairing is best done while being in the same room. However, there are technologies out there that help you to pair while working from different locations. You can always use the old school net meeting. But there are some other nice tools also available, such as SAROS. Also, cheap web cams and applications like skype make it easier for a team to be virtually together.

Having a conference line together with web cams at each location also makes stand ups and other meetings done in a more efficient manner. Many of us are used to having meetings over the phone but the experience is totally different when a web cam is involved. When a person knows that the whole team is watching them, there’s a better chance that they’d be at their best attention.

Finally, how do we deal with writing story cards and displaying them in a “big and visible” manner on a board in the team room while some members are not even there. Have a web cam always show the board to the team? Better yet, switch to a tool like version one that lets you write, edit, and view all story cards online. And if your team can afford one, get a big flat screen monitor and always display the story card view to the whole team.

In short, it is easier to be agile with a team that is present at the same location, but doing it with a remote team is NOT impossible at all. If you have the agility in you, you can make it happen!

How do you isolate static method calls if you are not into using mock libraries like Mockito or Power Mock? There are a few hacks to do that. In each of the hacks, you have to pull out the static call one way or the other and then test the rest of the method.

1. Extract the static method call into a method and override it in the test. This would be the easiest way to stub it out. However, if you have a bunch of static calls in your method, then your test class will have to have a lot of ugly overrides. For example:
   public void myMethod(){
Object1 obj1 = StaticClass.method();
Object2 obj2 = calculate(obj1);
}
becomes:
   public void myMethod(){
Object1 obj1 = getObject1();
Object2 obj2 = calculate(obj1);
}
Object1 getObject1(){
return StaticClass.method();
}
   And then override getObject1 in your test class.
2. Extract the rest of the code into a new method and test the extracted method instead. This way, if the static call returns an important object, the extracted method will have it as an argument which makes it easier to deal with in the test. This method, however, is useful only if the static call(s) is towards the beginning of the method you’re testing. For example:
   public void myMethod(){
Object1 obj1 = StaticClass.method();
calculate(obj1);
doSomethingElse();
andSomeMore();
}
becomes:
   public void myMethod(){
Object1 obj1 = StaticClass.method;
myMethod(obj1);
}
void myMethod(Object1 obj1){
calculate(obj1);
doSomethingElse();
andSomeMore();
}
   And then you only test myMethod(Object1).
3. Extract the static call into a Facade class that in turn offers your class a non static call. This works out really well because now since you don’t have any statics, you can create a dynamic mock of the method instead of a static mock. For example:
   public void myMethod(){
Object1 obj1 = StaticClass.method();
Object2 obj2 = calculate(obj1);
}
becomes:
   public void myMethod(){
MyFacade myFacade = new MyFacade();
Object1 obj1 = myFacade.method();
Object2 obj2 = calculate(obj1);
}

class MyFacade {
public Object1 method(){
return StaticClass.method();
}
}

Voice over IP together with JAVA programming can do wonders. I personally believe that the smart phone buzz in the industry has suppressed the fame VOIP could have received. Sky is the limit when it comes to VOIP programming but it has not really received the attention that it deserves.

Adding a VOIP layer to a project can allow the end users to use their regular phone to do things that they would have otherwise done online. As an example, if you add VOIP to an email application, users can use their phone (through a phone call) to check their emails, compose, delete, etc.

How is this exciting? Think about making a call from your phone to automatically switch on the air conditioner at home an hour before reaching back from a long vacation in a summer day!

How is this useful? What percentage of people have cell phones today? Now from among the people who do, how many have smart phones? By using VOIP, you can reach out to a large number of audience that smart phone apps (or event web apps) do not currently have access to.

As a developer, you often come across a situation where you have to update a legacy system. And if you have been a developer for long enough, you’d know that its not uncommon to come across “monster” methods and “monster” classes. A small change in such methods and classes can take forever for various reasons. First you have to understand, at least at a higher level, what the the piece of code does, then write tests around it, if they do not already exist, and then finally make the change. A 5 minutes change can very well become a 5 days change.

I came across a similar situation when I was expected to make a change in about 4 hours. It took me 2 days to try to understand what the methods and class were actually trying to accomplish. After failing to understand the code for 2 days of trying, I gathered some courage and started doing some refactoring. Safe refactoring. There are numerous kinds of refactorings that can be considered safe but what I used was the pretty basic kind. I extracted methods out of big chunks that seemed to relate to each other. When I was done extracting all the methods that made sense to me, the purpose of the chunk of code became so clear that it was hard to believe. Even though the names I gave to the extracted methods were from my own perception, when everything was put together, the pieces started falling into the puzzle and I was done with my task within a couple hours.

In brief, safe refactoring together with meaningful names to methods and classes can do wonders.