Friday, August 26, 2011

Being agile and technical masturbation

I suggest a great term for those who cannot do without making it more complex than it should be: "technical masturbation". Some people may choose to call it "Over engineering"; however I choose technical masturbation since what they do is satisfy themselves.

This occurs most when people try to make a software too flexible then it should be. Those keep saying they may need to serve in an another format; serve in a different platform/technology; but these never happen.

Requirements and technology changes rapidly; it is our job to be synchronized with them. Business wants development teams to be agile. For this reason, we have been populated our code base with:

  •  interfaces (that has only one implementation and will never change),
  •  design patterns where we do not need them actually (strategy pattern with one strategy)
  •  aspects where actually a simple web filter was enough (debug became harder; great)
  •  targeting high unit test ratios caused unit tests testing only order of method calls with mock objects
  •  useless documents
  •  too many configuration files (that never change)
  •  pages of spring beans; every developer will debug again and again

In order to be agile for business requirements; we should not forget two things:

  •  the language should be agile in nature (see few words on ruby)
  •  the team should be agile which is more important. To make team agile we need to be sure that the code is easily read; understandable by new joiners (where in IT world; recruitment occur more). Sometime it is better to do copy&paste code then a series of design patterns if team says replace all is easier. (and I doubt if it will ever needed.)

Requirements and technology changes rapidly; perhaps a design / software done five years ago is nearly dead and you think it is time to build it again with different technologies. Follow technology and use it; but do not lost yourself inside it; do not be obsess with being too flexible, technology and patterns. Check your old projects; don't you have a great new plan/design for those?

Friday, August 19, 2011

Ruby; Language for Humans

I have been developing with java more than 8 years. I have had implemented many technologies with ejb, spring, struts, hibernate etc.. you name it; I have faced with many technologies in java domain.

It has been few months I have been working with ruby (and ruby on rails). I am surprised how everything is easy to do. I witnessed whoever start programming with Ruby first resisted with some enterprise buzz words but then all ended with same decision: "I will never touch to java". :)

It is really much much easier to achieve what is on your mind with ruby. Once you get used to flexibility of dynamic language; open classes and many other features (once you achieve to change your mindset) it will be very hard for you to go back to java domain.

It is not easy to start a new language; new set of frameworks and you may think that you are throwing away the experience of years with switching to ruby. But calm down; it is fun; do not afraid. You will enjoy it while discovering how it is easy to achieve things. And experience is not lost; it will transform with time.

Of course every language has a place to fit. Java is structural and ruby is a dynamical language. They have both advantages and disadvantages. You can google them. However what I believe is; Ruby is the way to go. It helps me too much to solve problems much more easier. I definitely recommend you to check Ruby; but do not forget; a simple hello world is not enough; you must spend time and a project at least.

Also please check this graph; ratios of languages on github:

Especially Ruby on Rails framework is very successful and I am believe it has a part for Ruby to get popularity. Do not afraid from the change :)

"Because things are the way they are, things will not stay the way they are."
-Bertolt Brecht