Two last days I’ve spent on the conference about Agile in
business. Conference was very interesting despite that it wasn’t
much about business. My general observation is that most discussions
about agile is missing the point. I’ve realized that after great talk
of Arie van Bennekum. His definition of Agile is:
Serving the business by being adaptive
Most of time people are fighting lightweight vs. traditional methods
of project management. Scrum or Kanban like those are the only way to do
projects in agile. The true is that those
people are totally wrong. If you’re doing Scrum, you’re doing
Scrum. If you are doing PRINCE2 it doesn’t mean that you’re not doing
it agile. You’re agile only if you are capable of delivering business
value, or achieving business goals in a adaptive way. Scrum, PRINCE2
are just a tools that properly used can help you achieving this goal.
The true is that there are no agile or non-agile methodologies by
definition. It is the people that make those methodologies agile. In
fact I’m able to prove everybody that PRINCE2 is no less agile than
Scrum or Kanban (and I’ve heard the same about PMBOK or RUP). If people
define processes and procedures that prevent them from delivering business
values and responding to changes, it is the problem of procedures not
the methodology itself.
I would say that there are no methodologies that prevent you from being
agile. You can be agile even in waterfall. Being agile doesn’t mean
doing Scrum or Kanban. In fact not always you can use those
methodologies. In some cases more formal approach is
required (or you apply some formalisms on top of Scrum or Kanban). Everything depends on certain context. If you can deliver
business value in a adaptive way you are agile no matter the
methodology or approach you use.
Lately I’ve experienced following problem while creating new rails
The problem seems to be caused by some bug in OpenSSL while it happens
on Ubuntu 12.04 and not on OSX (don’t know how about windows). If the same
happens to you change source 'https://rubygems.org' to source
'http://rubygems.org' in your Gemfile.
Simon Brown did a great talk about the
role of a software architect. Having
a bunch of architects that do the design which is further implemented
by team of developers is really not the way software should be
developed. Simon says:
Architecture should be coded, not managed.
If architect isn’t at
least interested how his architecture is being implemented, how he can
prove that his architecture is implementable at all? If at the end software
do not meet requirements, do not scale enough is it because of the bad design, or developers
improperly implemented it?
Unfortunately it is very common that developers are treated as
brainless machines that just type code. Those who gains certain level of
experience became software architects, and since then create diagrams
and designs which is implemented by less experienced
(and less paid) developers. The problem with this model is that such
architects do not evaluate if their design actually works. If it doesn’t work
they blame developers (those idiots cannot implemented thing that was
given and fully documented in the design). They also miss the feedback
from the developers.
Software architect should be a role in a project rather just a
position in the company. Architect should be a part of a team and
shouldn’t be responsible only for design. He should be
responsible for proper implementation of a design together with other
team members which plays other roles in a project. It doesn’t mean
that architects must code though they should be able and at least
should be interested how their architecture is being implemented. Close
collaboration with team members that play architect and other roles
is a must in order to guarantee the implementability of an architecture. It
also supports principle of ubiquitous language.
Collaboration also guarantees quick feedback about the
correctness of an architecture and sharing knowledge and experience
across all team members (so after a while we have a whole team of architects).
Continuing thoughts from my last post
I follow with another overused bad practice. It is
more precisely how singletons are created and instantiated.
Firstly notice that I’m saying stop writing singletons not stop
using it. What does it mean? It is nothing bad to have class which only
one instance can exist. However this behavior shouldn’t be achieved
programmatically, it should be managed either by the JVM or by the
container. You should tell the container to create just one instance
of a given class and share it across all objects within the
container. What you shouldn’t do is to implement singleton like this:
It is wrong because you retrieve instance via a static method, and if
you read my last post you know why you shouldn’t write static
methods. Retrieving singleton instance using static method creates
tight coupling while we should design loose coupling. Also class using
the singleton cannot be tested in isolation. We cannot provide mock
implementation of a singleton and verify if it is correctly
used. Lastly singleton is a form of global state which in general
should be avoided unless you have very good reason to have it.
Singletons should be instantiated and managed by the containers. Use
Guice to create singletons
for you and inject them to your classes. This way you will have code
with loose coupling, open for modifications and most important classes
will be testable.
Object Oriented Programming is very popular for quite a time, however
still lot of developers have problems with understanding it. One of
the most common problems is overuse of static methods. While it is a
quick and easy way to implement some functionality, it also the
quickest way to create untestable and unmaintainable code. So next
time you want to create static method - don’t do it! Try to apply some basic
OOP rules, and if those fails you can implement method as static.
So why static methods are so dreadful? As I said it is a quickest way
to create untestable code. Static method itself is testable, however
code using static methods is not. Try to write test to method which
relies on current time, and retrieves current time like this:
You cannot mock the result of calling static method therefore you
cannot predict the result of such method so you cannot write a
test. Ok there is a PowerMock
that can stub static method, but this is a rather hack than a
So how we can avoid writing static methods? Let’s assume that we want
to create method that draws some shape, say a rectangle, on a
bitmap, but we do not want to create an rectangle object when we want to draw
it. What we can do? First write a signature of a static method, that you want to create:
In order to make a non-static method from a static method you need to
find an object on which you will invoke the method. This object you will
find in a parameter list of a static method (most certainly it will
be the first parameter). So to make this method non-static you can
But then you realize that drawing a rectangle is not really a
responsibility of a bitmap. You want the bitmap object to be a wrapper
for pixels. How to solve this? Think again about what you want to do. You
want to draw a rectangle on a bitmap which is in fact your drawing
surface. So you can create an abstraction Surface (sometimes it is
called Canvas) like this:
This design works, but it is still not a perfect solution. It is bad
because inheritance shouldn’t be used in this situation. Why? Because
code is still untestable! How you will write a test for drawRect()
method? You will need to add int getPixels() method, to check if
rectangle was correctly drawn, but in cost of breaking encapsulation and
exposing Surface internal implementation. Remember:
Whenever you need to add a method to a class to make it testable you’re
doing it wrong. Think again about your design.
And another thing to remember:
Favor aggregation over inheritance.
So applying this rule we have:
This class is perfectly testable because you can inject some mock
implementation of a Bitmap class and verify that it is correctly
used when invoking drawRect().
But what if we cannot rewrite static method to a non-static version?
Eg. we want to get current time using System.currentTimeMillis()?
We can wrap static call with an object providing non-static implementation
You can inject this object to your classes and for tests you can use
implementation that will return fixed time, therefore you can predict
the result of a time-dependent method. Note that this also applies
whenever you retrieving current date like this:
Doing above you’re creating untestable code! Add getCurrentDate()
method to SystemTime and inject this object wherever you need to
retrieve current date. For tests you can return fixed date and results
of your methods may be predicted and tested.
You may ask if there is any valid case to implement static method? The answer
is yes for Java language, because in Java you cannot extend core
classes like String (what can be done eg. in Ruby). Following is a
valid static method:
This method should exist in String class (as this is a first
parameter in static method signature), however you cannot extend
it in Java so static method is your only option in this case.
If we are in this point. Please, for heaven’s sake, do not mark
classes with final keyword. Really, there is no valid excuse to do
so, and it cause more problems than it solves, especially if you’re
creating a library. And follow OOP rules. They were created not
because OO is cool, but to solve problems that developers had.
If you’re experiencing significant performance loss when running Java 2D
based application on Linux platform try enabling XRender-Based
Rendering Pipeline. You can do this in Java 7 by setting system
In one of the applications I’m currently working on the new pipeline
gave about 20x performance boost. Rendering that used to take about 20ms now
After about 5 years of development in Java I’ve decided to take OCPJP
exam. I even attend to special training just to prepare myself for
exam gotchas and remind things that I normally do not use during
development. Here are some funny and mostly useless facts about Java
that most developers probably don’t know.
Enum package-private constructor
Ok, so everybody knows that enums can have private constructors. But
not everybody knows that we can define constructor of an enum without
Don’t be fooled however. It doesn’t mean that enum has
package-private constructor which can be invoked from other classes
within the same package. Java specification states clearly:
If no access modifier is specified for the constructor of an enum
type, the constructor is private.
So in enum case constructor is always private either it is declared
explicitly or implicitly.
Array is an Object that’s a fact. So if array is an object than it
must have a class while it must respond to object’s getClass()
method (even though there is no java.lang.Array class defined in
Java library). Have you ever wondered if array’s class has constructors, which
can be retrieved via reflection and used to instantiate new array?
So consider following code:
This code produces following output:
So despite array has some class (int) this class doesn’t have any
constructors. Haven’t we been told that every class has a constructor
even if we do not declare any? Well not in case arrays, they are
special kind of classes.
If you want to create new instance of an array you should use
There is another case where array’s are treated specially, this time
by the compiler. Did you know that following expression doesn’t
Despite that following compiles fine:
Similarly following expression doesn’t compile:
While this does:
In case of regular classes it is fine to create object and drop it in
the same expression. In case of arrays compiler check if we really do
something with this array. It even doesn’t gets fooled with accessing
array’s length field. Compiler checks if we at least assign it to