Couple of book reviews

Last few months has been very busy for me - at work as well as at home. I've read couple of interesting books (still more to come) and I wanted to write very short and shallow review for each of them. Here we go:


Random pick from the library. Not quite memorable book but still contains some wise pieces of advice how to be leader and enable people to be innovative (appropriate offices, relevant people, good competitive atmosphere, wise budgeting, etc.). Nothing new, nothing to be discovered but put in a very tangible way. Writer's style is very nice and easy and the book can be "swallowed" in couple of hours.



Very very short yet constructive book with many pieces of advice regarding leadership. If you are (or want to be) the leader you should definitely read this small guide and take to heart most of the hints.
The most valuable for me was the part saying that leader works for the team, not the opposite. Leader is the team's servant! And leader should lead people not manage them (i.e. managers usually show the way to achieve the goal, they drive people - leaders don't) - difference between manager and leader.



Reading this book I was feeling like this guy:
Not because of the contents but layout. Yes - Microsoft is not even able to publish correctly a book. I have an excellent sight, I don't use glasses (although I read a lot), but I was hardly able to read this book because the letters are too small. Generally book is also too wide i.e. there are too many words in one row. You may think that this is unimportant? Try to read this book then!
About the contents. Author tries to answer the question "How to introduce and implement Scrum in the enterprise?". He gives a lot of examples which are very interesting and save the book. In general the book is boring and over intellectualized (IMHO). Yet I think that if you work in big enterprise and would like to implement Scrum you should read this position.



Absolutely brilliant book! If you don't know what Scrum is and would like to get to know it quickly, this book is for you. Great style, a lot of pictures ;) easy to understand with real-life examples. This book also gives you insight into doing Scrum with XP - it really works. This book rocks! Couple of hours reading, btw.



I have to read this book again because during many of its pages I was sleeping. It is somewhat boring, however it contains invaluable and timeless knowledge on how to keep your team/company productive and what can limit the team's efficiency. It focuses many aspects of development team's life and gives a lot of real-life examples. This book made me thinking for a long time.



Another brilliant book on leadership and team management subject. Author gives us excellent book in which he tells a story (it is not a user's guide book). This book is letters in 90%. While reading it you identify with characters given in this book which makes it much easier to understand and put oneself into presented problematic situation - this was the intention of the author, of course. This book is really really great and everyone who is in position of power (or wants to be :) has to read it. It is probably classic management book by now.



Boring, boring, boring (2nd edition)! Only examples save this book. I'm really disappointed with this book. It is a classic one! If I didn't know what was XP about it would be hard to learn about it from this book.
Besides that I really love the last chapter (or last but one) when Kent describes how they "invented"/discovered XP.



The best book I've read recently. More so, Mike Cohn is my favorite author after reading this book and the next one (see below). If you want to have productive development team that collect requirements in an effective way, write User Stories. If you want to learn how to write User Stories - buy this book! The style is genial, the contents is awesome and the examples (including case study) are just amazingly easy to implement in practice. After reading this book you can immediately start implementing Scrum and writing excellent User Stories.



A bit over intellectualized book. Mike Cohn put a lot of effort into making this book credible, thus you can find many references to scientific works on estimating and planning subjects. Sometimes I was thinking I'm reading a scientific book which was hard ;) but the author uses brilliant examples that keep you focused on reading. Again the case study is just genial - you read, you think and you can implement it in your project. This is definitely the book you should at least read.

Quality doesn't suck

I disagree with this post written by my friend regarding quality. This is my response - maybe not direct and not to all objections but still valuable ;)

- Quality? - all right, but if time permits...

How often do you hear that? If you hear that often it means that probably your product's quality sucks.

Suppose that your team has to implement some stories in the fixed period of time (let's also suppose you are not using Scrum and you are not iteration-oriented). Then the customer pushes the higher management to move the deadline - of course for the earlier date. Team lead will not throw away any stories (what she should do) because the higher management would fire her. What she will do? Tell the developers to implement the same amount of features in shorter time. Developers subsequently will also have to sacrifice something - most probably they will not sacrifice their family life and free weekends. They will sacrifice QUALITY.

According to "Peopleware" book your product requires much higher quality than your customers need. Why? Because Quality, far beyond that required by the end user, is a means to higher productivity.

Reading the same book further there is an excellent example. I will try to rephrase it here. If you think of high quality (either company, nation, culture, etc.), what pops to your mind in the first place? For me it would be Japan. Again, if you think of high productivity (either company, nation, culture, etc.), what pops to your mind in the first place? Japan? This phenomenon can be explained this way:

The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

But this post complains that there is no need to think on the design, architecture, etc. for too long - just do it. Yes - you're right. That's the XP idea of simplicity - design what you need today - tomorrow you will refactor your code, design and architecture, but if only you will need to do it.

That's the quality for me. More so if you utilize Scrum framework and follow XP guidelines you incorporate relevant (i.e. high) quality into your estimates. And there is no way higher management could impose the team to deliver the product faster with the same set of features. Your team velocity does not lie - you will not deliver more user stories because the number of story points is too big. The team can deliver the product faster but they will implement less features.

Agile development somehow imposes on you high quality (but if you are agile it doesn't automagically ensure that your product's quality is high). More so agile teams show to be more productive than "waterfall-like" ones. And here we meet high quality with high productivity. What you think about this version of the original quotation?

The trade-off between price and quality does not exist in Agile Development. Rather, the idea that high quality brings on cost reduction is widely accepted.

Who am I?

If you want to check what is the current method name in Java you have two ugly possibilities to do it:

package com.bielu;

public class MethodName {
 
 public String methodOne() {
  return new Exception().getStackTrace()[0].toString();
 }
 
 public String methodTwo() {
  return Thread.currentThread().getStackTrace()[2].toString();
 }

 public static void main(String[] args) {
  MethodName name = new MethodName();
  
  long start = System.currentTimeMillis();
  for (int i = 0; i < 100000; i++) {
   name.methodOne();
  }
  System.out.printf("First method - new Exception() - in %d millis\n", System.currentTimeMillis() - start);
  
  start = System.currentTimeMillis();
  for (int i = 0; i < 100000; i++) {
   name.methodTwo();
  }
  
  System.out.printf("Second method - Thread.currentThread() - in %d millis\n", System.currentTimeMillis() - start);
 }
}

Results from my machine:

First method - new Exception() - in 8141 millis
Second method - Thread.currentThread() - in 80561 millis

As you can see the second method is ten times slower.

In any case I do not recommend using either of the shown techniques in the production code. You should consider using AspectJ in a pure form (don't like it) or Spring Framework AOP capabilities (most preferable way).

Anyway - why should you want to know where you are? :-)

How to start with SCRUM

The best way to start SCRUM is to hire someone who worked in such environment - likely SCRUM Master. But if you want to learn about SCRUM from the Internet and books here is my checklist.

The best book I've ever read on SCRUM is Henrik Kniberg's ebook:
SCRUM and XP from Trenches

Quite short and comprehensive introduction to SCRUM by Pete Deemer and Gabrielle Benefield:
SCRUM Primer

The shortest encyclopedic description available on Wikipedia:
SCRUM (Development)

Good way to learn is to take good examples. One of them is Atlassian - you can learn how they do SCRUM with XP from their blog:
SCRUM and XP in Atlassian

If you want to have up-to-date news about SCRUM and agile world in general you should subscribe to some RSS feeds:
http://agilesoftwaredevelopment.com/taxonomy/term/7/0/feed
http://www.scrumalliance.org/rss

I also have to mention Ken Schwaber's book (their are probably absolutely MUST):
Agile Project Management with Scrum
The Enterprise and Scrum

The reason why I didn't mention them before is that I'm still reading them so I don't know whether they are worth a while or not :-) But you could read reviews on Amazon.com and then you will know.

I hope that helps to some of you.

Image taken from Henrik Kniberg's e-book

eXtreme Programming is WRONG!

Yes - it is very much wrong. How can you convince serious, old-school, close-brained president of your company (or even high level manager) to use agile methodologies if they have Extreme word in their name? I find it difficult, almost impossible.

It may be funny but I'm dead serious - many people are afraid of XP because it's extreme. Personally I see nothing extreme in XP besides the name.

eXtreme Programming is wrong!

It should be Smart Programming instead.

Apache -> Tomcat (mod_proxy_ajp)

Another hard developer's day... I developed an application under Tomcat and used session to store some of my data there (sounds quite normal, right?). Everything works on my box ;)

The application was then deployed on some production-like environment with Apache server as a front end. So far, so good... Not exactly.

I discovered that I have no session! The problem lies in my webapp (I could rewrite jsessionid in the URLs) as well as in the Apache configuration (the latter is more annoying). The problem was that the cookies were not forwarded to and from the Tomcat server - but why?! It should be the default behavior but it is not, unfortunately.

Solution is quite simple but requires some non-zero knowledge of the Apache server configuration - that sucks! I'm not an Apache admin but a software developer. Anyway here is the solution: link

REMEMBER: Always check whether session ID is stored in a cookie or you need to rewrite jsessionid in the URL - see encodeURL

Coding horror...

I've just check-outed project from CVS (shit!) and try to build it - it's not so easy, although project is not so big. Ant script which is stuffed with tons of system properties dependencies is a little too big for me. It's only 67 125 bytes (yes - about 65KB !!!) long but it's too much for me...

Let's hope it works at least - more about this story some other time - I'm too depressed now to write.

BTW. Maven2 - I LOVE YOU!!!

Recursion sucks?

After writing yesterday's post I thought that many people don't like (I mean understand) recursion. Because of this I decided to modify my "algorithm" ;) and make it iterative.

Enjoy!

private static String convertIter(int decimal) {
 StringBuilder sb = new StringBuilder();
 int number = decimal;

 while (number > 0) {
  for (int i = 0; i < NUMBERS.length; i++) {
   if (number >= NUMBERS[i]) {
    sb.append(LETTERS[i]);
    number -= NUMBERS[i];
    break;
   }
  }
 }

 return sb.toString();
}

Funny coding test

Today I received an email from an Irish company (that probably found my CV somewhere in the outer space) with the following content:


-----------------------------------------------------------------------------------------------------------------------------

Test #1 - "Roman numerals"

Implement a program which can take an integer and convert it into a Roman Numeral string.
e.g.

1 = "I"
5 = "V"
19 = "XIX"
101 = "CI"

The function should be capable of converting every number between 1 and 3999.

A file is included for reference (roman.txt).
-----------------------------------------------------------------------------------------------------------------------------

Test #2 - "Hangman"

Implement a version of the "Hangman" game. A word is given, and the user tries to guess the word before the little stick figure is fully drawn.

e.g.

o
/|\
/ \
-----------------------------------------------------------------------------------------------------------------------------

Notes:

- You may use any of the following languages in implementing your solution: Java 1.5, C, C++ or C#
- Extra credit given for elegance and neatness in code, acceptance tests, etc.
- Comments are not necessary.
- Please provide instructions on how to run the code


That was pretty funny because it seemed like at least second part of the interview ;) and I haven't sent any email to this company before.
More so there was no "Hi", "Hello", "Regards", etc. - what a rudeness ;)

Anyway - I decided to solve the first task during my coffee break and here it is:

public static final int[] NUMBERS = new int[] { 1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1 };
public static final String[] LETTERS = new String[] { "M", "CM", "D", "CD", "C", "XC", "L", "XL", "X", "IX", "V", "IV", "I" };

public static String convert(int number) {
 for (int i = 0; i < NUMBERS.length; i++) {
  if (number >= NUMBERS[i]) {
   return LETTERS[i] + convert(number - NUMBERS[i]);
  }
 }
  
 return "";
}

Funny... :D

10 ways to screw up with SCRUM

Excellent (and short :) presentation from Henrik Kniberg's Blog.

Enjoy!

PS. I personally find it very very useful to know what can go wrong but ONLY when I know the framework enough to know what to do in order to make it WORK.