Thursday, November 27, 2008

Video Tutorial on "Java Stack Traces with jps and jstack"

In one of the previous tutorials named "Java concurrency is easy: Video Tutorial on >>Detecting and debugging deadlocks<<" I made a little mistake but thanks to "Anonymous" user who commented that post I'm publishing small appendix to it. This short extension shows how to use jps and jstack tools together. Using these tools you don't have to have an access to your program's console in order to see the stack traces.

Enjoy the video!

If you want more information about jps and jstack applications refer to their home pages:

Wednesday, November 26, 2008

Customer Team Member - a way to winning together

Used by permission.
Copyright by Paweł Niewiadomski
One of the core XP practices is having a Customer Team Member. It means that development teams have access to the newest information from the customer's side and they know about all changes in the requirements very quickly. Having on-site customer (or customer proxy for commercial products with lots of potential customers) ensures that requests change informally, the process becomes flexible, and saves the cost of formal overhead.

In this post I would like to take another look at this practice. I would like to share with you my thoughts why having a Customer Team Member can help the development team win together with their customer. And I would like to take a "social" view on this practice.

Customer knows better
Some developers say "It would be better if the software wasn't made for the customers - we wouldn't have any change requests then and we wouldn't have to reimplement once delivered features". Good point, however in this case we wouldn't earn any money because no customer = no money.

XP is very clear about customers - customer should be a team member. XP says that the development team is able to consult with them all unknowns just-in-time and they don't have to assume anything or wait for their response (sometimes quite long which can result in development blockage).

Customer as a team member is very helpful - as I wrote earlier, communication is much faster and efficient as it is mostly informal. If a developer, or tester or someone else from the development team has some questions he/she goes directly to the Customer and gets the first-hand information instantly. No waiting - no wasting - no assumptions - Customer knows better.

"Social" aspect
My colleague who I worked with for last couple of years used to tell his best experience with Customer Team Member from his previous job. The project's goal was to deliver some software for the civil aircraft cockpit and the main users of this software were airline pilots. Airline pilots were the Customers.

My colleague worked for the whole project closely with Customer according to the XP practices and always says that this project was the most successful in this company. And I have to mention that the company was quite big - actually it was one of the biggest airlines in the World.

When I ask him why it was such a big success one of his main points is that when the team worked together with pilots they felt responsible for the project. They felt responsible for project's successes and failures - they were involved in the development process thus it was their product. They couldn't blame the team - they were the team!
More so, they saw how hard developers worked and that they weren't spending their time on drinking coffee and talking to each other. Pilots really appreciated the work developers were doing - they saw it, they were co-builders of the product. Customer Team Member = involvement, ownership and trust.

Customer proxy works well too
Leaving my colleague's example I have my own. I'm now working on the web GUI application for the XML-based backend and my "customer proxy" is a product definition (PD) team (my customer should be marketing directly but I don't set the rules here). They are supposed to know everything about the project - I mean requirements. To be honest it should be transparent for us as a development team who they are - they act as the Customer for us and they are on-site.

I noticed that we are the first team that works so closely with PD team but I see huge advantages. Actually I see the same advantages I was told about with airline pilots. PD sees how we work, they are involved in the development process, they know about our problems and we can adjust some requirements to the technical constraints on the fly without the overkill process of changing the documentation first.
PD team really appreciates work we do and they feel responsible for the project - it's not like "We give you the specification and now it's your business to make it work". They are helping us in adjusting the specification - but this is because we communicate them all our problems and we involve them in our development process.

It really works!

Just do it!
I hope I expressed the main points in just few words - it is very very important aspect of Customer Team Member (IMO).

And what should you do when you have problems in having an on-site customer? Robert C. Martin in his book "Agile Software Development, Principles, Patterns, and Practices" answers this question - just have one.

In practice it can be more difficult than that but it will pay off - you will win this together. Try to convince your Customer to work with you - if you succeed you will not regret it (will you?).

Do you have any experiences with Customer Team Member? Do you find it useful or useless? How do you manage to work with your customers?
Please share your opinions here.

Originally published on AgileSoftwareDevelopment.com

Wednesday, November 19, 2008

Seven Principles of Lean Software Development - Defer Commitment

Picture courtesy of _fabrizio_@flickr
No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?

This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.

In this post I will try to explain "Defer Commitment" principle from "Implementing Lean Software Development - from Concept to Cash" book.

Schedule Irreversible Decisions at the Last Responsible Moment


You have to "abolish the notion that it is a good practice to start development with a complete specification" - basically They Aren't Gonna Read It.

I will give you a non-technical example (I think it's very popular but I will refactor it for my needs). Last year I was on my honeymoon in Spain - before going there I and my wife made a "big picture" plan what we want to see. We knew we were going there for three weeks and we were able to roughly assess how many places we are able to visit (in a decent pace - not travel-agency-rush-style). But we didn't have a full specification like: on Monday we are in Barcelona, Tuesday in Teruel, Wednesday in Madrid, etc. We just knew when we arrive to Spain, that we start visiting from Barcelona, when we have our flight back and what we want to see.

After few days in Barcelona we took a car and drove along the Spain to visit the rest of this amazing country. And we were planning our trip day after day - sometimes it was a bit stressful but we did it. We saw more than we planned and we had a really GREAT fun doing it. We were not attached to the plan - and I know we would have many problems with the plan because I made one just in case :) We wouldn't be able to see some places because we didn't know about many Spanish specifics - we learned them during the trip and we were able to adapt in an agile way.

The same is with software: "concurrent development saves money, it saves time, it produces the best results, it allows you to make decisions based on the most current data". You should know where you want to go but you don't know the road very well. You will be discovering it day after day - the most important thing is to keep the right direction. You don't necessarily have to drive highways all the time - maybe you should sometimes go with rutted roads - it can be faster and you may "see" and learn more things.

Break Dependencies


If you are worried about the dependencies of different components of your software - break them. Your components should be coupled as loosely as possible to enable implementation in any order. Of course some components will depend on other but it is often useful to rethink the architecture and accept dependencies only when there is no other sensible option.

Sometimes it would be useful to move some pieces of software from one component to another in order to remove dependencies. It's a very instructive exercise - you will merge few components in one or split one big component into smaller ones removing number of dependencies. Don't be afraid of doing this - you have REFACTORING (watch out - there are two links), right? But do it only when you arrive to the point you are sure you need it.

Loosely coupled components will pay off - you will be able to implement them simultaneously, thus you will deliver the whole product faster and your components will be probably reusable and ready to use in other projects.

Maintain Options


Good (but not always cheap) thing is to develop multiple solutions for all critical decisions and see which one works best. It can be sometimes hard, expensive and time consuming but you should decide what is cheaper in the long run. Robert Harris in his novel "Pompeii" wrote this: "What was leadership, after all, but the blind choice of one route over another and the confident pretence that the decision was based on reason". Do you want your decisions to be blind choices? If not you should invest some time and money in understanding the impact of each critical decision you have to make.

For all other (non-critical) decisions you should keep your code change tolerant. Remember that "change is the only constant". Make your code ready for changes - easy changes, and don't hesitate to change it.

Defer Commitment


I hope pieces of advice given above will make it easy to understand "Defer Commitment" principle. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.

PS. Three principles described earlier can be found here:
  1. Respect People

  2. Deliver Fast

  3. Optimize the Whole



Originally published on AgileSoftwareDevelopment.com

Monday, November 17, 2008

Combining Callable or Runnable with Future and FutureTask

Picture courtesy of markhillary@flickr
In this part of the Java concurrency tutorial I will present differences between Runnable and Callable interfaces as well as when and how to use Future interface and FutureTask class. As a side-effect of this "lesson" I will present how to use ExecutorService.

I will present all of this on a real example where I "parallelize" a sequential algorithm in order to utilize more resources and to get better performance.

To make it as simple as possible I'm using very basic requirements. I'm implementing a Java class that goes through the predefined list of web pages (URLs) and counts the number of bytes for each resource - primitive crawler (without analysing the content). This class has to sum up all the results and display total number of bytes read. It also has to display total time spent on this task. Here is the code for the test class that uses Callable as a worker that reads the web page:

package futures;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class Test {

public static void main(String[] args)
throws InterruptedException, ExecutionException {

@SuppressWarnings("serial")
List<String> urls = new ArrayList<String>() {{
add("http://www.java2jee.blogspot.com");
add("http://www.yahoo.com");
add("http://www.msdn.com");
add("http://c2.com/xp/ExtremeProgrammingRoadmap.html");
add("http://apache.org/");
add("http://sourceforge.net/");
}};
List<Future<Integer>> futures =
new ArrayList<Future<Integer>>(urls.size());

final ExecutorService service =
Executors.newFixedThreadPool(1);

try {
long start = System.nanoTime();
for (String url : urls) {
futures.add(service.submit(new CallableExample(url)));
}

long result = 0;
for (Future<Integer> future : futures) {
result += future.get();
}
System.out.println("\nTotal bytes: " + result);
System.out.println("Total time: "
+ (System.nanoTime() - start) / 1000000
+ "ms");
} finally {
service.shutdown();
}
}
}

and the "worker" class follows:

package futures;

import java.io.InputStreamReader;
import java.io.LineNumberReader;
import java.net.URL;
import java.util.concurrent.Callable;

class CallableExample implements Callable<Integer> {
private final String currentUrl;

CallableExample(String currentUrl) {
this.currentUrl = currentUrl;
}

public Integer call() throws Exception {
int result = 0;
URL url = new URL(currentUrl);
LineNumberReader in =
new LineNumberReader(
new InputStreamReader(url.openStream()));

try {
String line = null;
while ((line = in.readLine()) != null) {
result += line.length();
}
} finally {
in.close();
}

System.out.println(currentUrl + " has " + result + " bytes");
return result;
}
}

And now a bit of explanation. Following line service.submit(new CallableExample(url)) submits new task to the Executor Service (created earlier) that will be invoked as soon as any thread in the pool is available. The submit(...) method returns a Future which in turn is added to the task list futures. After submitting all the tasks this program iterates over each previously submitted Future, gets the result and adds it the overall result variable result one by one. Future's get() method blocks execution of the program until the result is available and then returns the value (Integer in this example). Eventually this program shows the summary. Simple :)

As you can see in the Test class there is this line final ExecutorService service = Executors.newFixedThreadPool(1); that creates tread pool of size 1. It means that all the web pages will be visited sequentially one by one. Try to experiment with this parameter and see with what value you get the best results (on my machine thread pool of size 3 works pretty good and increasing this number more does not help).

With 3 threads each thread takes one web page, loads it and checks the number of bytes. As you can see we gained a lot by "parallelizing" such simple application. And this is the power of concurrent programming. Using simple mechanisms brought in Java 5 your applications can be more efficient.

Below I presented the same "worker" functionality as above but this time I'm implementing Runnable interface

package futures;

import java.io.IOException;
import java.io.InputStreamReader;
import java.io.LineNumberReader;
import java.net.MalformedURLException;
import java.net.URL;

class RunnableExample implements Runnable {

private String currentUrl;
private int result = -1;

RunnableExample(String currentUrl) {
this.currentUrl = currentUrl;
}

public void run() {
int result = 0;
URL url = null;
LineNumberReader in = null;
try {
url = new URL(currentUrl);
in = new LineNumberReader(
new InputStreamReader(url.openStream()));

String line = null;
while ((line = in.readLine()) != null) {
result += line.length();
}
} catch (MalformedURLException e) {
throw new IllegalArgumentException(e);
} catch (IOException e) {
throw new IllegalStateException(e);
} finally {
if (in != null) {
try {
in.close();
} catch (IOException e) {
// ignore
}
}
}

System.out.println(currentUrl + " has " + result + " bytes");
this.result = result;
}

int getResult() {
return result;
}
}

In order to change the "worker" class you have to modify this line of code: futures.add(service.submit(new CallableExample(url))) into this one: futures.add(service.submit(new RunnableExample(url)), 0). It will not work as the previous example i.e. get() method will always return 0 instead of the number of bytes read by the task. I will leave the solution to this problem as an exercise for you dear readers. You will see that using Runnable interface is somewhat obsolete and can be pain in the a**.

I postponed the subject of FutureTask to the end. This class is considered by me as a helper class and will help you in many situations where you want to use Java 5 facilities, namely Future and your legacy Java code (or 3rd party components) accepts only Runnable interface. FutureTask implements both interfaces in question and you can treat is as a Runnable or Callable depending on the context or library capabilities. For more information plese refer to JDK documentation.

I hope this article helps you in understanding core Java concurrency components described above. If you find it interesting and useful or you have some ideas how it could be improved your feedback is more than welcome.

Friday, November 14, 2008

Video tutorial: Remote debugging of Java web applications in Apache Tomcat and JBoss

In this four minute tutorial I'm presenting how to remotely debug Java web applications in Apache Tomcat and JBoss containers. This tutorial may be useful if you deployed your application on the remote server and want to debug it in this particular environment. IMPORTANT: remember that your Java application HAS to be compiled with enabled debug information, otherwise you will not be able to debug it.
Remember: to start Apache Tomcat in the debug mode type this (on Windows):
set JPDA_ADDRESS=8000
set JPDA_TRANSPORT=dt_socket
catalina jpda run
on Linux you have to set environment variables using export command.
To enable remote debugging on JBoss server type this:
set JAVA_OPTS=-Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8001,suspend=n
run <options>

More information on this subject can be found here:

Do you find this tutorial useful, interesting, fantastic or maybe boring and crappy? Please share your opinions in the comments zone.

Wednesday, November 12, 2008

Video tutorial: Test Driven Development with Mock Objects

In this eleven minute tutorial I'm presenting TDD with mocking technique using JUnit 4.x and EasyMock library. This is more advanced example of Test Driven Development - video tutorial on basics can be downloaded from here: Test Driven Development in practice.

Source code for this tutorial can be downloaded here (you can find also Eclipse project files in this bundle, so it's easy to import the project directly to your IDE - NetBeans users have to create a new project and add relevant classpath changes). Note that external.jar was built with Java 6 and thus you have to use at least JDK version 6 to be able to compile and run the example.



Enjoy and comment the video if you find it useful or useless. I'm really curious what you think about the video as well as about the mocking technique in general.

Originally published on AgileSoftwareDevelopment.com

Monday, November 10, 2008

Couple of book reviews (part 3)

It's been some time since I published my previous books review but I've been reading - that's for sure. Here is the list of books I've read since August:



I's been some time since I finished this book, therefore my short review is based on quite stale memory :) This book is great and if you want to familiarize yourself with the "Lean" theory you should definitely read it. This book will help you understand why lean and agile methods work and how pioneers in this field implemented them in the real projects. You will learn about Seven Principles of Lean Software Development an get to know how to put them into practice in your company.

This book is full of great examples and pieces of advice you should take seriously. Sometimes it becomes boring but all in all it is a great position you should have in your library.



AFAB - Absolutely Fu**ing Amazing Book! I loved the first edition of this book and I really really waited for the second edition covering Java 5 features. I am not disappointed - this book is ABSOLUTELY FU**ING GREAT! And I'm not exaggerating. Every Java developer has to have this book at hand. If you don't use "items" presented in this book you cannot call yourself good Java developer.

Joshua Bloch presents Java language in a fantastic way, he shows common problems and easy (not always) ways to solve them.
I use many of his pieces of advice every day and I see my Java code is simpler, cleaner and works better. And recently I find myself referring to this book when I encounter a wall and I cannot jump over it - this book helps me in, say 80% of the time.
An finally if you want to prepare yourself to the Sun Certified Java Programmer exam you will be prepared in 90% after reading this book. You will just need to cover some examination tricks with other resources (BTW. it took me two days).

AFAB!



This book disappointed me - it is my first and very important statement about this book. It starts with the "big bang" - no introduction, no description - just FIT. This is a really good definite guide to the FIT Framework and FitNesse but it lacks simple and concise "big picture" description. FIT seems to be very complicated to both developers and business people but in fact it is not (at least I believe it is not).
I see a big big potential in FIT but this book doesn't sell it very well. And from the developer's point of view FIT tests are not object oriented and it hurts (for example tests of many tables in one when you have to "store" one fixture in the static field and access this static field from another class - ugly!). Also creating custom forms is a nightmare (the invoice example) - if you move some fields or modify simple layout of your invoice (it happens, right?) you will break everything - maybe this is the expected result?

Anyway - if you want to know what FIT is and then use it, this book is for you. But don't expect clear and concise explanation of what FIT is. This is rather too technical book for business analysts and too "null" (I used "null" because I can't even find relevant adjective) book for developers.

To finish with a good accent - if you want to use FIT and need details, this book will work fine. This is a definite guide for FIT.

PS. You may find all the previous reviews here.

Friday, November 07, 2008

Happy Birthday...

Picture courtesy of chidorian@flickr
... to the "From Java to Java EE" blog.

It's been two years since I started blogging and I find this period quite successful. I posted almost one hundred posts to this blog (some of them were longer, some shorter, some more interesting some not so much) and I'm pretty proud of it. And this year 2008 is the most successful ever as I already "produced" more posts than in 2006 and 2007 summed together. FeedBurner also shows increasing number of permanent readers - it's very nice.

Let's hope I will keep the decent pace of at least one interesting post per week.

Thank you readers and let's hope to the bright future of this blog!

Happy Birthday to the "From Java to Java EE"!

Wednesday, November 05, 2008

Agile Success Story: interview on how Agile movement helps company to grow and succeed

Picture courtesy of M. Keefe@flickr
Last week I had a great fun and honour to interview Janusz Gorycki who is a partner and a team manager in an Agile Software Development company - Spartez. Janusz is also the author of the open-source screen capture and painting utility for Windows named Mazio.

In this interview I'm asking Janusz about how they founded their company and how agile movement helped them achieve success. I'm also asking how they see their agility, what problems they have and how they deal with them. Janusz also answers why you can be CMMI-compliant using agile methodologies and recommends steps by which you can start applying Agile practices in your company.

Is this interview about yet another agile company? Not really - Spartez is an extraordinary company composed of ordinary engineers who were not afraid of making their dreams come true. Their determination, team work, a bit of luck and an extreme agile spirit helped them be and work together and become successful. This is a real-life example how cross-functional team, where each member is an expert in some areas, is able to deliver any software to any customer. And how do I know this? I used to be a part of this team at Intel and know this team as well as each member pretty well, however I'm not affiliated with them anymore in any way.

If you are interested in getting to know how they started, what and how they do now, this article is for you. Maybe you will follow their dreams and ideas - I think it's worth.

List of questions:


  1. As far as I know you worked together as a team at Intel which is huge corporation. I also know that you were not using Agile from the beginning. So, how did this all start?

  2. What are you working on now and how Agile methodology helps you?

  3. What Agile techniques you use (Scrum, XP, etc.)? What principles and activities you utilize and which one you abandon? Why? Don't they work for you or you consider them obsolete/unnecessary/unimportant?

  4. What tools do you use? Can you be Agile without them? What do you gain/lose using tools?

  5. Do you want to tell our readers something more about your development process? What makes you successful, what would you like to recommend trying?

  6. What are, in your opinion, three most important things that make Agile methodologies successful?

  7. What are three most important problems you encounter with Agile techniques? I won't believe it's always cool and problemless. How do you cope with them?

  8. You are familiar with CMMI as well and worked in huge corporations. Can you accommodate CMMI and Agile?

  9. Was it good decision to start thinking Agile? What did you gain as people, engineers and team?

  10. How would you encourage other companies and teams to start investing their time in Agile methodologies?

Przemysław Bielicki: As far as I know you worked together as a team at Intel which is huge corporation. I also know that you were not using Agile from the beginning. So, how did this all start?


Janusz Gorycki (Spartez): Yes, we have started our work together as a team at Intel's IT. The team consisted mostly of Intel newcomers and I was a long-time Intel employee (more than 10 years in one company, but in a different division), so I got appointed as their manager. Very soon after the team was formed, it became apparent that traditional software development methods, which I was used to while working at my former team, and which more-less worked acceptably well there, were hopelessly inefficient, unpredictable and very costly when applied to the internal IT environment. It was not uncommon for a software project at that organization to be more than a year late, and during that time deliver hardly any business value at all.

So we have started, at first in the "stealth mode" (without telling any higher-ups), to look for more efficient alternatives. Agile methods were, at least partially, known to some members of the team, so we decided to try them out. The productivity boost just from time-boxing our development and defining exactly what we will work on during each iteration was immediate and obvious. And as far as I remember, we have initially decided on a three-month iteration cycle - unbelievably long by normal agile standards. Encouraged by this success, we tried more and more practices.

But the real, no holds barred, use of agile methods, started after we all left Intel and created our own company - Spartez. We basically established the company as a place with agile spirit from the very beginning.

Back to list of questions

PB: What are you working on now and how Agile methodology helps you?


JG: We were able to launch Spartez, because we have managed to find a strategic partner - a company from Sydney, called Atlassian - the makers of excellent software such as JIRA and Confluence. Most of the software we develop is written for them and we are also resellers of their products. The main software product we are working on, and actually 100% own its development, is an open-source IDE Connector, integrating Atlassian web-based software into IDEs such as IntelliJ IDEA and Eclipse.

The development of this tool is done as a series of 2-week-long Scrum sprints, with almost each sprint's results actually released publicly, with downloadable and installable binaries. Each sprint delivers an increment of value to users of the Connector. I don't think we would be able to successfully launch Spartez and remain in operation for a year, without any initial funding whatsoever, were it not for agile methods - Atlassian folks were astonished that we were actually able to release a usable piece of software after just two weeks of work. Obviously, compared to where we are now, the functionality of the release was extremely limited and primitive, but the point was - we were able to prove to our customers from the very beginning that their investment was justified, because we are able to deliver on our promises.

Back to list of questions

PB: What Agile techniques you use (Scrum, XP, etc.)? What principles and activities you utilize and which one you abandon? Why? Don't they work for you or you consider them obsolete/unnecessary/unimportant?


JG: Sometimes we do get tired of this or that practice, becuase the downside of these practices is that they require quite a lot of discipline. The funny thing is, we get in trouble each and every time we abandon or do too little of some practice.

An example: we have agreed to release (internally) the new version of the software every second Thursday, dogfood it for a bit and launch a public version the next Monday morning. It so happened a couple of times, that we told ourselves "let's not release on Thursday because we need to finish this or that story". That proved to be a mistake every time we did this. By breaking the release cycle, we were forced to shorten a subsequent iteration and not only we delivered less functionality the next time around, but we broke our velocity measurement and lost control over one of the most vital metrics we had at our disposal.


Another example - unfortunately we don't unit test enough. Sometimes unit testing some functionality is prohibitively difficult when you write a plugin for some other software (like IDE), because there is no way to properly mock or stub some piece of code that you depend on. Well, we could probably try to mock them, but we decided that we would not, as we would have to rewrite half of the IDE. This has immediate negative consequence on the quality of the code. There is no doubt that the pieces of code that are unit tested (because they are not tied to the IDE), are of much better quality and easier to extend and maintain, than the pieces of code that are not unit tested. We are aware of this problem and we are long overdue addressing it adequately.

I can honestly say that all of the agile practices are important and they represent a coherent system. Abandoning some XP or Scrum practice may sometimes be necessary due to unforeseen circumstances, but I would recommend sticking to them as much as possible. Therefore I will not try to list the ones that are of more or less use.

Back to list of questions

PB: What tools do you use? Can you be Agile without them? What do you gain/lose using tools?


JG: This is the beauty of it - you don't really need sophisticated tools to successfully do agile development. At Intel, we have started with a cork board, sticky notes, scissors and pencil. And it turns out, these remain to be our most important tools to this day. This, a version control system (I would recommend SVN in most cases), a bug tracker and a continuous integration server are the only crucial tools you will need.

You should use other software tools only after you know which aspect of the agile software development you want to optimize in your particular situation. We are in a very lucky situation, where Atlassian has supplied us with an excellent software tools that nicely compliment each other. We use JIRA bug tracker for planning, tracking and bug reporting, Bamboo build server for continuous integration, Confluence Wiki for knowledge sharing, and Crucible for source code reviews.

Other tools? I would recommend getting the largest LCD screen you can buy (and they are dirt-cheap these days), computer with enough juice in its CPU to not frustrate you, plenty of RAM and a comfortable chair.

Some folks also like IDEs - like the IntelliJ IDEA that we happen to use. And I would agree that they do help, but I am tempted to also say that they sometimes help you too much - and instead of spending your time thinking about your design - you Control-space through your code, often times making it overly bloated and unnecessarily spaghetti-like. I sort of long for the days when you were limited to just bash and emacs (vi users - I am sorry, your way is wrong, but you will see the light some day). Not because I am a ludditte, but because in the absence of the powerful IDE, you have to stretch your mind more to make the code simple, elegant and concise.

Back to list of questions

PB: Do you want to tell our readers something more about your development process? What makes you successful, what would you like to recommend trying?


JG: Before I try to describe what we do, it is important to understand that these days, the eight of us work on at least four different projects. This means that some teams are actually one-person teams. And such small teams actually do not need any formal process - after all, the only reason for the existence of a process is communication - and if you are alone in what you do, you don't need much communicating. Except of course with your customers.

For the bigger projects, we start with a release planning session, during which we size all user stories that we have been able to gather from the customer. The stories are already prioritized by the product owner in some way - unfortunately sometimes only roughly. We play planning poker for each story and after the session we enter the results into JIRA.

After that, every two weeks (on Monday) comes an iteration planning session. During this session we commit to a subset of stories, trying to pick the ones from the top of the backlog, but sometimes for architectural or other reasons we also pick stories form the middle. Obviously, we also have bugs - and they tend to be quite hard to properly size, so in their case there is a lot of guessing involved sometimes. So what we do is try to have at least a 50-50 distribution of bugs and user stories for every iteration.

Then, every day we do daily stand-up - 10am sharp. We try hard to make it no longer than 15 minutes, but sometimes we fail (and this is all my fault as I lead these meetings).

Sprint demos are quite problematic in our case - our customer is in Australia and it is not realistic to actually do live presentation. What happens instead is we try to educate our product owner (who is in Sydney) what we delivered - he just looks into JIRA and he can monitor what's going on. He would then do demos for the end users (who are at this moment mostly developers in the Sydney office).

How we do actual development? That sort of depends on the task at hand. Sometimes we pair-program. Actually we should do much more of it than we do now, but this is a pretty intensive activity and therefore not everybody naturally chooses it. We have a Bamboo continuous integration server checking our code, so all of our commits get sanity checks, the code is always compilable and unit tested. For the more problematic, tricky and complicated code we do code reviews - using the Crucible tool. We do try to "dogfood" our own product as much as possible - if the required functionality is available (even if it has bugs), we try to do as much interactions with the tools using the IDE Connector that we are developing. That way, we know if we like the UI that we have just created and we are able to detect bugs before they hit the customer.

Would I recommend our ways to everybody? The elements of it - yes, all of them. The whole process? Not necessarily. In reality, you should use a process and methods that suits your team. Ours attempts to be optimal for us. It will probably not be optimal for you.

Back to list of questions

PB: What are, in your opinion, three most important things that make Agile methodologies successful?


JG: Let's tweak this question and answer this one: "Why are agile methods better than non-agile ones?" Let's try to answer that question. I would begin by this observation: software development is a chaotic process. By "chaotic" I mean "the one where slight modification of input parameters causes huge changes to the results" (I guess I could give a lot of examples here, but I don't want to make this interview even longer than it is now). The only way to control a chaotic process that we know of is by using empirical methods. Agile development give you means for empirical process control. You get your process checkpoints every day, every two weeks, every release. You can actually measure (as opposed to just guessing) how effective you are and what your real (as opposed to perceived) pace is. There is no "perpetual 80% done" syndrome in agile development. You can actually tell how much you have done so far and be certain that you are "done" working on something.

Second, agile software development give your customers better control over how they spend their money. They get results fast, they can check at any moment the health of the project they invested in, and they can stop the project at any moment when they determine that the investment does no longer brings expected results. Usually, 20% of the features give your customer 80% of satisfaction. With agile methods, you can deliver these 20% in 20% time, instead of being 2 years too late.

Third, agile methods give your team frequent and regular small successes - you release your software every second week or so, somebody is using it, giving you feedback, and the feedback is very likely to be positive, as you are building the software to exact specs of the ones you are working for. This builds confidence, enthusiasm and sense of working on something useful.

Back to list of questions

PB: What are three most important problems you encounter with Agile techniques? I won't believe it's always cool and problemless. How do you cope with them?



JG: The problem with agile methods is that they require much more discipline than "traditional" ones. The simplicity of the process definitions and "obviousness" of the practices is very deceptive. Agile methods require you to keep your pace day in and day out. There is no "quiet period" after a "death march". At first that may be problematic to some people. You will have to be effective as a developer, and your effectiveness is easily verifiable, every day of the year. The good news is that once you get accustomed to the routine, it becomes natural. Moreover, once you prove to yourself that you are able to deliver at an acceptable pace, your confidence improves. The question is - what if you _are not_ able to deliver at an acceptable pace? Well - XP has built-in mechanism for improving skills of team members, the best of which is without a doubt pair programming. But you have to be aware of the skills of everybody and react to people's deficiencies as you discover them. This is not always a pleasant exercise.

More dangerous than the first threat is lack of feedback from your users. This will surely cause you to get derailed, as user feedback is of paramount importance. Agile team has to do everything that is in their powers to get feedback. This is not only the responsibility of the ScrumMaster and the product owner - everybody on the team has to be aware that the feedback loop has to be maintained and supported by all means possible.

Third threat is lack of flexibility. Agile processes are meant to be improved. You are supposed to tweak, modify and fix them to your liking and to the precise needs of your team and its customers. There are sets of "best known methods" in Scrum or XP, but they are just that - "best known methods" and not a bible. It is important to understand that there are no "sacred cows". The process itself must not become a holy grail - it is just a means to achieve a goal and nothing more than that. If it makes sense to break the rules that you learned at your ScrumMaster training, go ahead and break them. Just be aware that you are breaking them and that you are doing it for a reason.

Back to list of questions

PB: You are familiar with CMMI as well and worked in huge corporations. Can you accommodate CMMI and Agile?



JG: I have somewhat mixed opinion about CMMI. On the one hand, the principles of CMMI are actually great - the central goal of striving for ordered, dynamic process, that has built-in mechanisms for self-improvement is something that I like, and which is also exactly what the agile methods are all about. On the the other hand, I am yet to see an implementation of CMMI that is not hopelessly heavyweight, overly complicated and and that is not making your life as developer miserable.

I suppose the reason for this is two-fold:

First, the only successful processes are ones that are built bottom-up, as a response of actual, painful needs development teams, designed and tailored by the teams themselves and modifiable by the actual users, without having to go through the huge bureaucratic hassles. CMMI however, is unfortunately usually introduced from top down, at the request of the higher management - more often than not quite isolated from, and unaware of, the gory details of day to day development work.

Second, the successful process has to be simple, intuitive and so natural that you would naturally resort to it when working under stress. Unfortunately, all CMMI implementations I have seen so far are heavy, complicated and impossible to fit in the head of a mere human. So what people tend to do is work around the complicated process in many cases, giving the false impression that they follow it, while in reality their real process is quite different from the "CMMI-defined" one. I have seen this evolution from "let's follow our CMMI process to the letter" to "let's pretend to follow it and get stuff done somehow, because our defined process does not actually work" happen a lot.

Having said that - I think agile methods can be basis of a complete CMMI implementation (up to level 5, no less). Just notice that some of the core agile principles are precise, empirical measurements (story size estimations, velocity), formal contracts between stakeholders (prioritized backlog) as well as built-in self-healing and self-improvement of the process (Scrum demos, retrospectives, daily stand-ups, pair programming).

Back to list of questions

PB: Was it good decision to start thinking Agile? What did you gain as people, engineers and team?


JG: I think it was the best decision that we as a team have ever made. The decision actually started us as an independent, and so far quite successful company - something that many of us dreamed of but before we met, had no guts to actually decide to do. Agile methods gave us discipline, they allowed us to easily share knowledge, improve ourselves, understand what we are capable of and what are our realistic and objectively measurable abilities. This is not to say that we are perfect - far from it, the team seems to be in a constant state of internal turmoil - and I think this is a good thing. But we seem to be, as a team and as a company, in control of our lives and we are able to "make our own luck" in stead of totally depending on the decision of others.

Back to list of questions

PB: How would you encourage other companies and teams to start investing their time in Agile methodologies?


JG: I would advise to start small. Don't make a "big bang jump" to an all-agile software shop. For example, it took us about three years of incremental improvements to get to where we are now, and we are still very far from perfect. Stay cool, stay calm, have guts and courage to try new things, pick and choose whatever seems to make natural sense.

Also - do not try to spend most of your money on fancy tools. Like I said - at first, paper, pencil and cork board will be all you need. After you understand what it is that you need, you will know what fancy tools to buy. And I hope you will turn to us to sell them to you, because we sell good stuff.

Back to list of questions

PB: Thank you very much for your time


Few facts about Spartez


Website: spartez.com
Location: Gdańsk, Poland
Operational range: global (currently working with customers in Australia, USA and Europe)
Areas of development: IT systems integration (B2B, SOA, middleware), aeronautics and GIS, telecommunication, low-level and embedded systems in the following technologies Java, C# (.NET), C++, C, assembler

Originally published on AgileSoftwareDevelopment.com

Monday, November 03, 2008

Video Tutorial on "Detecting and debugging deadlocks"

In this three minute tutorial I'm presenting how to detect and debug Java deadlocks in runtime while having access to the application console. Code for the example can be copy-pasted from the previous post. Remember: to dump the thread stack you have to press Ctrl+Break on Windows and Ctrl+\ on Linux.


More information on this subject can be found here:

Please share your opinions in the comments zone.

Sunday, November 02, 2008

Cisco's $100,000 Developer Contest

A Cisco's PR person contacted me to share the information about the developer contest and I found it interesting enough to share it with you - readers.

The point is to develop an application for the Cisco's router and the cool part is that it runs Linux and supports Java, Perl and even Python. If you are lucky to propose one of the most interesting concepts, you get 90 days for the actual implementation and can win up to $50 000. You can find more information at http://cisco.com/go/thinkinside and http://youtube.com/watch?v=RrqTv3MkIHI

Have fun!

P.S. I am not affiliated with Cisco in any monetary way

Saturday, November 01, 2008

I'm changing my given name

It is an era of UTF-8 and there is no reason for me to hide my real given name which is Przemysław not Przemyslaw. I'm proud of the polish letter ł in my name and from now on I'm changing my name in all Internet accounts I have to the original one.
I don't care if someone cannot pronounce my name - I have to learn french, german, spanish, italian, etc. names and I do it so you have to learn how to pronounce my name too (it's something like Pshemyswav).

Cheers!