General Java

Geecon 2014

GeeCon logo

Thanks to my employer – Sabre,  I was able to attend GeeCon conference, which was taking place in Krakow, 14-16th May 2014. This event was organized in big cinema with multiple different rooms. Usually there were 5 speeches at the same time.  I think that this conference is getting too big. It was very crowded specially during coffee brakes, when everybody was going from one room to another. Also eating lunch on your knees is not nice thing. I know that it is hard to put in one place tables for 1000+ people, but maybe organizers should consider choosing different place for next year. The good thing was that, as in good cinema, chairs were very comfortable.

Besides that I enjoyed it. It was great pleasure to meet other developers form different parts of the world and also to meet my colleges from previous company.

Some of presentation I attended:

Day 1

Jurgen Appelo – The 7 Duties of Great Software Developer

Very interesting speech about things we should thing about in order to make our careers move forward. Jurgen is a person with experience in management and he wrote book “Management 3.0”. During his speech he mentioned following key points, for each he added most important question every developer should answer.

  • Motivate yourself – Are you aligning your work with your intrinsic motivators?
  • Direct yourself – What do you see in your future?
  • Educate yourself – How have you decided to learn?
  • Measure yourself – How do you track your growth as a professional?
  • Connect yourself – How do you diversify your personal network?
  • Brand yourself – How are you developing your personal brand?
  • Improve yourself – Are you improving by adapting, anticipating and experimenting?

Whole slideshow is available here.

Marek Matczak – AngularJS: Java developer’s real-life experiences

Very well prepared introduction to AngularJS, specially for Java developer’s point of view. Marek described basics and showed how to use directives and templates, how to create simple widget and extends html with own tags.

Ken Sipe – Go – The Language of the Cloud

Ken described Go language by comparing its features with Java. For me it appears that this language is step backward. For people used to Java it is less readable and more complicated. Unfortunately it allows programmer to do simple things in many different ways (like for example returning multiple values from function can be achieved by assigning value in the middle of the function and it the end). In my opinion in can be very error prone.

Gleb Smirnov – Mutation Analysis or What Code Coverage Doesn’t Test

Very interesting speech about using PIT – mutation coverage tool to improve quality of unit tests. Gleb was showing example of Apache commons-math analysis and time needed to run mutation tests for that library. Results are very promising, I hope I will be able to use PIT in my projects.


Tim Boudreau – Everything You Were Taught About Java Is Wrong

First speech of day 2. Tim Boudreau was talking about few issues which he finds problematic in Java world.

  • Inheritance is evil
  • JavaBeans are an antipattern
  • ORM tools are solving the wrong problem
  • Threads for managing I/O are a mistake

Very interesting presentation, but I feel that some ideas are not applicable for big, enterprise solution. There are really cool for small projects.

Peter Lawrey – GC Free Coding

GC is always a very interesting subject. This time speech was about dealing with GC in system for which latency is main concern. Peter has shown few tricks (two of them were easy, one was hardcore – override String class). Basically I think it was good presentation by subject is much wider and can be explored more.

Kevlin Henney – Seven Ineffective Coding Habits of Many Java Programmers

Kevlin Henney is an author of book “97 Things Every Programmer Should Know” and he had some interesting ideas about habits, that we have. Just to show some examples

  • IllegalStateException – why do we need Exception in name of this class – we know it is exception by its inheritance tree.
  • UserEntity – if this is entity we should name it User, that should be enough.

Kevlin also focused on layout of code, because he thinks that it has big influence of perception. Good look and feel of code can highlight important things to person reading it.

 Kevlin Henney – Worse Is Better, for Better or for Worse

Worse Is Better is really bad name for quite good idea. This idea was defined before agile started its race to glory. There is a point where less functionality (“worse”) is a preferable option (“better”) in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse. (wikipedia).

Day 3

Jakub Kubryński – Spring Boot – and it is lightly again

Jakub presented Spring Boot – this tool can be called Spring Light, because it allows developers to create Spring based application really fast. It contains many predefined configurations and supports other Spring components out of the box. Great tool for starting new projects. I will describe details in future posts.

Tom Bujok – 33 things you want to do better

Tomek mentioned many different useful technics, to make our software better (like Lombok, Byteman, Guava, etc.) Most of them were used to reduce amount of boilerplate code. He also found practical usage of System.exit. When he finds //should never happen comment in code, he immediately adds it there, like on this example:

try {
} catch (Exception e) {
	//should never happen

Sam Newman – The Practical Implications Of Microservices

Microservices is very hot topic right now. Sam has given his 14 tips which can help everybody build, deploy and maintain microservices.

Michael Feathers – Beyond Error Handling

The final keynote of the conference was about error handling. Main point of this speech was that we should consider error handling as bad design. In some cases I agree with him, but there are situations where error handling is required. Few important notes:

  • Null passing is wrong – avoid it by using Optionals or NullObject pattern.
  • Having noticeable exception handling is wrong – basically error handling should be separated from business logic because in many cases it makes code less readable.


I think 2014 GeeCon was quite good conference. Of course there were some minor issues, but with event that big it is impossible to make everything perfect. Every such event is great opportunity to meet with other passionate developers (I don’t think others come to conferences). As organizers said at the end, GeeCon 2015 will also be placed in Krakow, so see you there next year.

Agile General

The three team phases – from Notes to a Software Team Leader: Growing Self Organizing Teams by Roy Osherove

In order to see team leadership from new perspective I decided to read “Notes to a Software Team Leader: Growing Self Organizing Teams” by Roy Osherove. It is very interesting book and I would like to share with you some of great citations.

As one of most important things Roy mentions three team phases. I totally agree that we always have to think about where we are as a team. Those phases are:

  1. Survival phase (no time to learn)

    “Survival” sounds dramatic and is as alarming as it sounds. It doesn’t necessarily mean coffee-stained carpets and a sleepless staff. I define survival as your team not having enough time to learn. In order to accomplish your goal as a leader (getting people to grow), you need to make time to learn, so your main strategy, or instinct during this phase is to get the team out of the survival phase by creating slack time. In order to slack time, you will most likely need to use a command and control style of leadership.

  2. Learning phase (learning to solve your own problems)

    You can tell you’re in the learning phase when your team has enough slack time to learn and experiment and you’re actually using that slack time. Slack time can be used for learning new skills, or removing some technical debt, or at best doing both at the same time, such as:

    • Learning and slowly implementing test-driven development, with people who have no
      experience with it
    • Enhancing or building a continuous integration cycle, with people who have no experience
      with it
    • Enhancing test coverage, with people who have no experience with it
    • Learning about and refactoring code, with people who have no experience with it

    In short, use slack time to do anything, and tack on the phrase “with people who have no experience
    with it” at the end of the sentence. Your main goal as a leader (in order to achieve your overall role of growing people) is to grow the team to be self-organizing by teaching and challenging them to solve their own problems. In order to achieve that, you need to become more of a coaching style leader, with the occasional intervention of the controlling leader, for those cases when you don’t have enough slack time to learn from a specific mistake.

  3. Self-organizing phase (facilitate, experiment)

    You can tell you’re in the self-organizing phase if you can leave work for a few days without being afraid to turn off your cell phone and laptop. If you can do that, come back, and things are going well, your team is in the quite unique position of solving their own problems without needing you to help them

    Your goal in the self-organizing phase is to keep things as they are by being a facilitator and keeping a close eye on the team’s ability to handle the current reality; When the team’s dynamics change, you can determine what leadership style you need to use next. The self-organizing phase is also a lot of fun because this is the phase where you have the most time to experiment and try different approaches, constraints, and team goals that will grow you and your team even more.

That was one of many great thoughts from Roy Osherove book. I will post some more soon. If you would like to read this book, please follow this link:


Stabilization and quality don’t go together

Recently my friend told me nice rule.

If you have stabilization period during your development and in the same time you are developing new features, than you cannot say anything about quality of your product.

At the beginning I didn’t agree. I thought that it is possible to work on new features and on old defects in the same time. But later I started to think about it. Now I’m sure that he was right, but my first understanding was wrong. I think this problem is more complicated that.

Let’s look at example of company Agile.


  1. They do Continuous Integration.
  2. They have automatic tests, but it is impossible to cover 100% of scenarios.
  3. They work with SVN and codebase is huge.
  4. Team is quite big.

Assume that they release working version of their product every 4 months and they spend one month in each release on bug fixing (in the same time they are starting development of next release).

What’s wrong with this approach?

Working on one code base with different goals – my first thought.

It can lead to big conflicts, when one team is working on defects and in the same time developing new features. Those who are responsible for current release don’t what to introduce any risky changes, refactor or reduce technical debt. Their main goal is to make product “stable” so it can be shipped. On the other hand, those who are developing new features are not afraid of making bigger changes, even architectural.

Moreover, looking from outside you are not able to say if some bug fixes don’t influence newly developed features and those features don’t introduce new defects. Some can say – let’s create branch for each release and then merge changes. That can work, but as always, we are only humans. Somebody can forget to merge his changes to some branch and whole team will lose time on investigating the same issues once again.

Stabilization – second thought

After some time I discovered that whole idea about having stabilization period is wrong. If you have big backlog of defects and you have to spend time to reduce it, than you are doing it WRONG. You should stop, rethink your approach, review process and decide where you want to go. If you want to be agile you have to provide shippable version of your product after each iteration. If you are not able to do so, stop where you are, clear your backlog, pay the debt. I know that sometimes it is hard – there is marketing, there are some contracts, etc. But without taking this step it will get only worse and worse.

Continuous Integration

As Uncle Bob said during one of his speeches: “If it is green, I ship it”. I think that this the most important change you should make in your process. You should be confident and trust your CI it the way that you can immediately ship your product when it passes all tests. Those tests should be fully automatic. Of course you don’t have to run all tests in one build. Your process can have some stages with for example only unit tests, than integration tests, than automated regression tests, etc. It is important to setup process and have full agreement among all team members and stakeholders.

There is one issue with this approach. Building that kind of solution and writing software with 100% coverage has to be top priority for whole team. If it is not, situation will not get better.

Moreover not having correct process makes feedback loop much longer. Without big test coverage you are not able to say when you break something until your user calls you at the middle of night.


In my opinion the ultimate goal is not to have stabilization period at all. There are multiple ways to achieve that, but the best is to stop what you are doing and redefine your whole process, approach and what’s most important – goals. This requires having strong team with strong leaders. I will talk about this in my next posts.


Code readability with FluentItarable and Java 8

Each and every developer has to think about code readability and review his habits when working with new technologies and solutions. As you probably know on 18 March 2014 Java 8 was released and changed a lot in Java world.

Just to name few main features introduced in Java 8:

  • Lambda Expressions
  • Default methods
  • Method parameter reflection.
  • etc.

Full list of features in available here.

In this article I would like to compare how usage of lambdas influence code readability on very simple examples. read more »


How NOT to write tests and improve coverage

Recently I’ve found nice way of writing tests and improving test coverage.

Check this example:

public enum Fields {

	public Fields[] getValues() {
		return Fields.values();

As you can see this is quite common enum. So how to improve test coverage?

Lets write some test! You can ask how to write tests for enums. Here it goes:

public class FieldsTest extends TestCase
    public void test()
        for (Fields type : Fields.values())
            assertEquals(type, type);

You can do this if you want to sell your source code to some company and show statistics about test coverage. Something like pig in a poke.

PS. Of course it’s a joke. Never ever do this!