Java Developers! You Should Learn Groovy

November 5, 2013 § 5 Comments

A couple of years ago, I started playing  with Python, Scala,  Ruby and Groovy time to time. The very first thing that really impressed me was their expressiveness.

java-groovy[1]I really like all of these languages,  but here in this post I’d like to emphasize the benefits of Groovy for Java developers since Groovy is the easiest to learn and  to make transition to a “” language for them. 

Groovy is Expressive

Groovy is a very expressive language compared to Java. You can do more by less code. Expressions and syntax are very similar to Java, but they are shorter. Actually, some of them are like shortcuts for corresponding Java expressions.

Flat Learning Curve

It has a flat learning curve. It is very easy to understand the code and easy to write for a Java developer.

You can start with Java style coding in groovy  (removing semicolons from java code:) ), and make a smooth transition to groovy style by simply removed redundant keywords, and using shorter (Groovy) version of the expressions.

 “A Java developer embarking on a Groovy adventure will always have Java in mind, and will progressively learn Groovy, one feature at a time, becoming more productive and writing more idiomatic Groovy code. ” [2]

Similar to Java and Also Different from Java

Groovy compiles to Java classes and byte code therefore it can use all of Java platform.

Yes, Java developers, it is like Java you know, it is on JVM. You dont need to learn new environment, and new dynamics of a language.

It extends the JDK. You have all libraries and features from Java, and in addition it provides a number of features from languages such as Python and Ruby. Closures, metaprogramming and dynamic typing are just a few examples of those features.

It also supports DSLs, mini-languages aiming to represent constructs for a given domain.  It helps to make code easy to read and more maintainable.

Groovy has also nice collection processing features. It  eases the creation of collection proving a more natural way. Also,the code is definitely more readable.

Groovy is dynamic and optionally typed language. You can keep types if you want, and also can use dynamic typing. It is nice that you don’t have to worry about typing. I find it very powerful in scripting and writing some quick codes. However, in bigger and enterprise applications you should be careful. It is great that you can write very succinct code but the cost of not knowing what it is being passed back and forth can be sometimes not so nice.

More Productive

By doing more in smaller peice of code, it really feels more productive. For example, let’s say you have an idea and/or design and you just want to write code to implement it quickly. Instead of dealing with syntax of the language, you can concentrate more on the stuff that you are trying to solve.

Scripting Language

It can be used as a scripting language for the Java Platform, and it can be used to have some small hacks on the daily development.  It  is a nice alternative to shell scripting for developers with a Java background.

Warning: Power comes with responsibility

It is true that it is flexible and powerful language with many new feature such as dynamic typing, closures,etc… It can easily go in wrong direction, and you may end up with unmaintainable and messy code.

Although Groovy is supported by IDEs such as Eclipse, and IntelliJ , it provides less information for IDE since it is dynamic. The compile time checking, code completion, and refactorings are limited compared to Java.


As conclusion, I strongly recommend Java developers to learn Groovy and start using it somewhere, either as scripting language to do some daily small hacks or in some part of your projects. You will really feel more productive and see the benefits.

Even if you don’t use it anywhere, it will give you a perspective and widen your vision.

And also please keep as a general rule in mind that all languages are like tools in your toolbox. Just use the most suitable one, which is not necessarily the most popular one, not necessarily the one you like most and not necessarily the one you know most. In short, as I said in this blog: No language fanatism!

Happy coding!


[1] (image)


A software myth: Behind schedule, add more people

April 21, 2011 § 1 Comment

You may have already experienced several times that when a project is late or seems to be late, the first solution mostly applied is to add more people. But mostly, it makes the project later. It does not solve the problem but ironicaly creates more problems.

Even with adding more people, sometimes,  the project can be delivered as working somehow. However, the team later has to deal with some bugs introduced by these people added. In this case, the problem is just delayed a little bit, and making it more time consuming. Because it always takes more time to fix an issue on an already delivered release.

You may find it hard to believe but Fred Brooks, in 1975, stated it clearly :  “adding people to a late software project makes it later” [1], and added that “Nine women can’t make a baby in one month”. (Brooks’ Law)

“If we get behind scehulde, we can add more programmers and catch up.”[2].Unfourtunately, adding people to a late software is a software myth  and even worse it is commonly used.  Basically, software development is not like building a wall and software developers are not mason. You cannot add more manpower to increase the amount of the work done in a certain time.

But why?

Adding new resource makes others slower. Because they need to help/teach new ones. And you also cannot count them as efficient as the others. They need some time to understand and get used to the project.

Another reason is the increased communication overhead. For N developers, the communication channel number is N *(N-1)/2. As N increases, the number of communication channels increases and the amount of work done decreases.

How to deal with the situation?

Honest promises : Be honest and don’t promise more than what is possible. This is important and applies to whole team including project managers.

Reduce the scope : If possible, meet with the key stakeholders and check if  any of  functionalities can be dropped, or added in a later phase.

Root cause analyze and fix : Find the root causes of the delay, not blaming anyone, and if possible, fix it. Sometimes it is the motivation of the team, and in this case, the factors which decrease the motivation should be carefully indetified and  solution to increase the motivation should be based on it.

Realistic plan: Revise the project plan with delay and/or create a realistic project plan with more realistic revised estimations.

When is it useful?

Adding manpower can be useful if the current team has trouble with  some difficulties and they cannot easily overcome and the new members are experts for that kind of problems.

[1] The Mythical Man-Month: Essays on Software Engineering, Fred Brooks

[2] Software Engineering – A practitioner’s Approach,  Roger S. Pressman

A Collection of Lessons Learned From My Last Decade on Software Development.

December 29, 2010 § 7 Comments

    1. No language fanatism : All languages are like tools in your toolbox. Just use the most suitable one, which is not necessarily the most popular one.
    2. Measure progress and make it visible, even when you are doing it yourself. Use board and charts.
    3. Code base is like your house. Always keep clean, otherwise after a while, you can find yourself in a mess. Refactor.
    4. Always be very humble. There is always someone better than yourself. The greatness is hidden in being small.
    5. Continuous learning. There is no stop in learning, learn until death. Read beatiful codes, designs, books, blogs, etc. Improve your skills.
    6. No frozen well defined requirements. Change is part of life like time, it is in nature of things. So is in development, then always be prepared for it. It is not a thing that bites you, it is something to tackle.
    7. Help others. Always be open to help others, especially juniors. This is kind of being thankful of having knowledge. The best way to learn is to teach others.
    8. Unit test. The more unit test, the less debug. Skipping unit test to gain time is an illusion.
    9. Keep being on the mid-way. Never overuse anything. Never overuse design patterns, never overrefactor, never overdesign, etc.
    10. Developers always underestimate. Most of “2-min work”s are not 2-min. Be aware of that and always add a little slack on estimations.
    11. There is no end in development. Stop developing at some point.
    12. Simplicity, simplicity, simplicity. Simplicity, simplicity, simplicity.
    13. No gossips : Never gossip. Never listen gossips. Never let them decrease your energy. Be smart and aware and observe environment to know what is going on, but no gossips. If you have a problem, talk to related people.
    14. Use version control.
    15. YAGNI :“Always implement things when you actually need them, never when you just foresee that you need them.” (Ron Jeffries). Developers always tend to develop things more generic, for possible future use purpose. However, most of this possible future never happens. So, even if we are very sure that we will need a feature in future, we should not implement it now, we should implement it when the expected future comes.
    16. Stabilize pursit of perfection with pragmatism.
    17. Continuous integration
    18. Communication is important. One of the most important and difficult thing is software development is communication. Clear communication in the team and clear communication with clients. And be very specific to unprofessional people.
    19. Focus on delivering working software and deliver frequently.
    20. Remember the big picture.

Arrogance, humility and software development

January 23, 2010 § 4 Comments

One’s true greatness is inversly proportional to behaving as if one were great, just as one’s true smallness is inversly proportioanl to behaving as if one were small. (Anonymous)

The more I learn, the more I realize I don’t know. (Albert Einstein)

You should have heard about how arrogant developers are terrible in communication with team members and client or you should have met an arrogant developer who never listens anyone else, thinks he knows everything and who is also very rude.

Once upon a time, you might have had at arrogant aggressive collages, who cover their frustrations with aggression, finding yourself in feeling of “never be part of anything which they are in”.

What is arrogance?

Arrogance is an offensive display of superiority and self-importance. It destroys professionalism by reducing the individual’s ability to think for himself or herself, making empathy for others difficult and removing the checks and balances of self-doubt.[1]

Arrogance is the reason for many failures. It could kill any company in any stage of its life. It could kill any work in any stage of its life. If you analyze the failures of the giants, you will see that most of their failures come from their arrogance.[2]

So why are people are arrogant? It is a mask hiding various types of states: It is a way to fill the inner emptiness with a big ego, actually, which makes them a slave of their own ego. Also, it is a way to cover up insecurity and frustration.

Personally, I don’t know anyone who likes arrogant people. They are not being more appreciated, not more admired, on the contrary, peoples dislike them.

I believe that it is one of the worst thing in business to have arrogants. They cause a tremendous amout of discord in the workplace. They ignore others and separate themselves from others, and pull down the energy level of the people.

Lets consider developers’ arrogance, generally they cannot learn from others, they reject it. They even don’t listen others. They are very rude in discussions, which they make it go nowhere. So, in this situation, who is the looser? In the team, they hurt the team spirit. They are a kind of obstacle slowing down the team to reach the goal. To put it short, their damage is to both themselves and the team.

How to deal with arrogant

The belief of that you have to be arrogant  to survive  in an arrogant world is nothing but adding fuel to the fire. Considering it is more likely related with inner problems of the arrogant, responding with arrogance only makes you another arrogant, nothing more. It doesn’t help solving the problem with only exception that the arrogant may feel seeing himself in the mirror. But it is very hard to see it in negative response. Being cool and sedate or being confident in silence help more.

If you feel arrogant

When you feel arrogant,  here is the motto : Treat others as you would wish to be treated yourself. Think you’re just human, ordinary mortal human. Be sure , somewhere, there is a better professional than you, and also he/she is smarter and more genios than you.

Breaking of arrogance starts with seeing it, and knowing it. The people around you and feeling of something is wrong with you somewhere inside you may be hints. Accepting and seeing the truth of that we are at the same level of importance as others is a cure for arrogance.

The feeling you have when you see the greatness of your work and your thought should not lead to arrogance, you should be thankful to have that gift, keeping in mind that it is given to you to use in benefit of humans.

If you look at life, you can also easily see every extraordinary thing given to the human is supposed to be used in benefit of others and if he uses it for himself, like arrogance, he pays a lot for it. So, even if you are gifted, there is no excuse for being arrogant.

Arrogants are knocked out sooner or later, without any exception. One day, they find themselves brought down to the floor. This is how it works. You can easily find many instances of this situtaiton in the history. A lot of giants vanished because of thier unwarranted arrogance.

Cofidence vs Arrogance

Confidence and arrogance are different. Arroagance goes beyond healty confidence. Confidence is being aware that you know something, whereas arrogance is being overly concerned with aware that you know something.


Humility, or being humble, is the defining characteristic of an unpretentious and modest person, someone who does not think that he or she is better or more important than others. Because the concept of humility addresses intrinsic self-worth, it is emphasized in the realm of religious practice and ethics where the notion is often made more precise and extensive.[3]

Dignity of the knowledge and wisdom requires humility, which is one of the greater virtues one of the most appreciated personal qualities.Its absence is a direct obstacle to comunication; and can generate enemies, so it’s a necessary social behavior and part of being professional.

Humility comes with being aware of your strenghts, weaknesses and abilities. This also gives you the ability to approach situations in a superior way. Extreme humility [4] is a nice example for it.

Humility is more useful in problem solving; you don’t trust your self blindly and fail and blame other people or other things for failure. To put in another way, you will find that you are much more open to opportunities to learn and improve the project you are working on.

And software development

Humble people are a lot more pleasant and easy to work with. They don’t make their superiority an issue, they don’t always know better, they listen and respect and value others’ ideas.

Arragont developers! You’re killing what you’ve done and your team’s work .You are not being more appriciated, not more admired, on the contrary, you are loosing them. Your ego keep you from being great developer. The more humble you are, the faster you’ll improve. So, why arogance?

Developers! Know your strenghts, your weeknesses, know what you know and what you don’t. Be open to communication, listen others, respect people. Be confident about yourself, but never ever be arrogant. Knowing yourself, your capabilities and inabilities leads you to a way for improving your skills.

Everybody can make mistakes, everybody can write code in poor quality, but the virtue is to admit it and learn from them.

Managers! Even you may be in a dazzling position, but it does not require to be arrogant. First of all, never ever be arrogant. And do not hire arrogant people. If you have any between your employees, give a bit time to them for recovering themselves from arrogance and also help them in doing that, if they still persists, get rid of them. Value confidence. Never forget your team is very important.


  1. Professionalism Initiative
  2. Success, Arrogance, Rise and Fall
  3. Humility
  4. Extreme Humility

Verify details of argument passed to the mocked object

January 22, 2010 § Leave a comment

Mockito,my favoritte mock library, introduced ArgumentCaptor with 1.8. ArgumentCaptor allows you to capture and store arguments passed the mocked methods.
The captured arguments are available with the methods like getValue and getValues.
So, the arguments can be easily verified by using standart JUnit assertions.

ArgumentCaptor argument = ArgumentCaptor.forClass(Person.class);
assertEquals("John", argument.getValue().getName())

Value Objects

December 27, 2009 § Leave a comment

The value objects are simple but very useful objects. Value object, one of the powerful concept from DDD, is an object that describes a characteristic of a thing.

According Eric Evans,

“An object that represents a descriptive aspect of the domain with no conceptual identity is called a value object. Value objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.” [Evans 2003]

Here a few characteristics of value object:

  • The key defining characteristic of a value object is that it has no identity. In other words, the intention of a value object is to represent a concept by it’s attributes only.
  • They should probably be immutable, once created they cannot be changed or altered.
  • They are not DTOs, not Java beans and not objects with public fields, they encapsulate data with some behavior. DTOs are bunch of data, which are not necessarily coherent, VOs contains high-chorent data with behavior. The purpose of DTOs is data transfer but the purpose of the VOs is domain representation.
  • They are mostly very simple objects.
  • They “swallow computational complexity”.
  • More extensible
  • More testable
  • Some examples of value objects are money, addresss, phone number, product code, email address, etc..

A Concise solution for hashCode() and equals() implementations

June 23, 2009 § 3 Comments

Currently, I was working on improving code quality. Some of the violations were due to the code generated by eclipse for hashCode() and equals() methods in the domain model classes. I was thinking on writing a builder classes for these methods, later on I just came across the Apache Commons Lang builder classes. It was even better than I imagined:)

Actually, the Apache Commons org.apache.commons.lang.builder package contains builder classes to help implement methods like equals() , hashCode() , compareTo(), and toString().. They are implemented to follow rules from in Effective Java , by Joshua Bloch

Considering clarity, readability and maintainability of the code, they are very concise and consistent solution.

The EqualsBuilder
Here is the sample usage of EqualsBuilder from API docs.

public boolean equals(Object obj) {
if (this == obj) {
return true;
if (obj == null) {
return false;
if (!(obj instanceof MyClass)) {
return false;
MyClass other= (MyClass) obj;
return new EqualsBuilder()
.append(field1, other.field1)
.append(field2, other.field2)
.append(field3, other.field3)

It is good to be carefull with isEquals() method, it is a common mistake to use equals() of the EqualsBuilder instead of isEquals().

The HashCodeBuilder
Here is the sample usage of HashCodeBuilder:

public int hashCode() {
return new HashCodeBuilder().

It is good to be careful again with toHashCode() method, it is a common mistake to use hashCode() of the HashCodeBuilder instead of toHashCode().

Alternatively, you can use the reflection-based static methods:

public boolean equals(Object o) {
return EqualsBuilder.reflectionEquals(this, o);
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this);

However, I think reflection implementations are not good for a real project: They are potentially much slower and it is very important for domain model, the fields icluded in these methods should be carefully and intentionally selected considering the implication on the model.