Milestone

Yesterday was kind of milestone in my life. And even bigger, than I thought, it will be.

It was the last day working in bank. After we had a small party at the end of the day, I noticed that my old sim stopped working (it was planned, if you change the company, you have to change sim also). When I started replacing it, my mobile also stopped working. My old notebook (the oldest one) not booting up any more. Changes are in the air :)

To plan or not to plan

There has been a lot of posts about planning: BuildingaCity, Conformance to plan, About planning, in last few days. I feel uncomfortably not touching this topic myself.

While thinking about writing this blog, I came to the understanding, what the planning is. Planning is a process of designing a path to the final result. This path consists of tasks to be completed, resources that can be used, priorities and risks to be considered. But the most important is the understanding, that plan is not a “private static final Plan PLAN”, but rather “public Plan getPlan(Date planDate) {}” and should be used as “currentPlan = getPlan(new Date())”, if you understand what I mean :)

People want to know, what will happen next; otherwise, they get very uncomfortable and while being stressed by uncertainty, start to behave badly. Plans are used to create agreement and some certainty in the teams members, that is why it s very important to have a plan created according to our best knowledge and agreed by all team members. If plan has been created this way (we sometimes don’t have even those conditions fulfilled), why it can’t be static? Our knowledge increases constantly, thus plan, created yesterday, today does not contain our best knowledge anymore. So, plans should be changed constantly to fulfill the requirement: created according to the best knowledge. But it is not wise to change plan very frequently (every hour or day), this will lead to uncertainty. Plans should be changed regularly after some constant period, in XP those periods called Iterations, in Scrum – Sprints. Note that in XP during iteration you should follow agreed plan very strictly.

Conclusion

By making plans, human beings are trying to cooperate with uncertainty of the world. Although it is efficient to stick with the plan for some period of time, it is advisable to change plan regularly according the best knowledge, otherwise one can run against the wall if he does not look ahead and change his direction according to what he sees.

Language Oriented Programming: The Next Programming Paradigm

Our beloved Uncle Bob (Robert C. Martin), author of the book with the picture of Supernova is talking about The Next Big Thing in software development.

He hopes, that there will be no next big technological thing and he also hopes, that the major shift will be in our heads and we decide, as an industry, that we will not ship shit.

On the other side other our beloved person, Sergey Dmitriev (we love him for starting the development of Idea IntelliJ) believes, that the next big thing will be Language Oriented Programming or LOP. This term he proposes to use for the new programming paradigm which can be composed on the basis of different existing parts: intentional programming, MDA, generative programming, DSL's, etc.

The main idea of the LOP is about shortening the period of programming the designed solution by giving the programmers the language that would fit the problem domain in a most appropriate way. There are already existing DSL's for certain domains, but the main problem is, that there is no possibility to design your own language, that would fit exactly your problem domain. Sergey decided to solve this problem and currently is working on the software, that will allow to design new languages easily and according to him, not only designing possibilities matters: developers, who will use newly developed languages, will need an efficient editor for those languages, there must be also translator to some of already existing languages.

Having in mind, how appreciated Idea development environment is by Java developers community, we can hope, that Sergey will manage to give us next extraordinary thing.

Martin Fowler also believes, that it is the area to keep eye on.

Back to coding

In order to go forward, you sometimes have to look back. Now I am trying to remind myself, what was the coding about :).

I decided to implement example of very simple asynchronous messaging. My user story was: "message producer sends message to queue and message receiver gets it".

First you have to decide what implementation of JMS to use. My choice was ActiveMQ, mainly for the possibility to use it inside JVM. I just wanted to start as simple, as possible.

The first thing I understood, that I forgot how to write code. Not completely, I was pairing with our guys, but being alone in front of the code now is frightening me. Maybe I just need a teddy bear :)

Any way, I managed to create an example which uses TCP transportation. It have a BrokerAndConsumer class, which starts a BrokerContainer for queuing and then connects to this container as a MessageConsumer. MessageProducer class connects to the same container and sends a message, which is recieved by consumer class succesfully.

I also created a very simple messaging example using in-VM transportation option. Here it is:

package ee.icefire.simplemessaging; 
 
import org.codehaus.activemq.ActiveMQConnectionFactory; 
import javax.jms.*; 
import java.util.Date; 
 
public class SimpleMessage implements MessageListener { 
  public static void main(String[] args) { 
    ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("vm://localhost"); 
    try { 
      Connection connection = factory.createConnection(); 
      connection.start(); 
 
      Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 
      Destination destination = session.createQueue("BROKER.SIMPLE_QUEUE"); 
      MessageConsumer consumer = session.createConsumer(destination); 
 
      consumer.setMessageListener(new SimpleMessage()); 
 
      TextMessage message = session.createTextMessage("Message sent at " + new Date()); 
      MessageProducer producer = session.createProducer(destination); 
 
      producer.send(message); 
 
      session.close(); 
      connection.close(); 
    } 
    catch (JMSException e) { 
      e.printStackTrace(); 
    } 
  } 
 
  public void onMessage(Message message) { 
    try { 
      TextMessage textMessage = (TextMessage)message; 
      System.out.println(textMessage.getText()); 
    } 
    catch (JMSException e) { 
      e.printStackTrace(); 
    } 
  } 
} 

Decision to go forward

I decided to go forward in my life and leave my current employer. I have been paid very well, but the job itself does not satisfy nor develop me at all. I took this decision without any guarantee, that I will be paid at the same level after I quit. Experience tells that while trying to find guaranties, it is always possible to find obstacles, which can be later used as excuses for not taking actions. And your closest family members will be the first, who tries to convince you not to take risky decisions. Here is the message to my colleagues:

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

"One never notices what has been done; one can only see what remains to be done." - Marie Curie, letter (1894).

My journey in Hansabank was like a stair with very high steps, it lasted for more than 7 years. Now it's time to look back and thank all those people, who helped me climb these stairs easefully.

I came to our company 1998 January; the same day joining with Savings bank has been announced. I was lucky enough to be assigned to Internet bank development project, it influenced my career much; this area has been always in focus of management.

During joining with Savings bank it was decided to create a web based application for tellers: "Light". That time it was an innovative decision with high potential of failure. Development of this software was my first step in a row. I would like to thank a very special person, Piret Oja, who has been very professional, inspiring and a true partner during this project, also the rest of our team: Toomas Rand, Marko Randrüüt, Aadu Adok and Guido Püvi.

Next significant step was IS migration project in Latvia. This time I will remember, as one of the most exciting in my life. We had a great team: Tarmo Pajumets, Vilve Vene, Tea Trahov, Heiki Kübbar, Toomas Rand, Jaak Niit, Marek Läll and Egils Jakovels. By the end of the project I felt, that our team can accomplish any, I mean ANY, kind of project.

I haven't participated in Lithuanian IS migration much; I was dealing with new technologies in Electronic channels area, developing telehanza.net and hanza.net.

Then I moved to managerial position in branches area.

Then I additionally took responsibility for Electronic channels development, and now I would like to thank those people, how supported me very much that time. We started to learn how to become true professionals all together: Erik Jõgi, Aadu Adok, Aho Augasmägi, Maksim Säkki, Maksim Panov, Alvar Lumberg, Sven Tressum and Tauno Siitam.

Last of my favorites is "B4B" project. We created vision and formalized it together with Evelyn Paltmann. Currently it is in the development and I really believe that it will be the next very popular service, as hanza.net currently is, but I will see it already from outside the company. I decided to leave our organization.

There are two major reasons, which influenced my decision: I am not enjoying my work and I feel, that for my further personal development I need organization, were changes can be done more easily, in other words, I need more agile environment.

Anyway, big thanks to all my colleagues for teaching, supporting and appreciating me.

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

Recruitment and Retention

Tim Bacon is writing about recruitment and retention practices for Agile teams.

There are very familiar issues to me. Especially "diaspora" effect problem - we have such kind of diaspora here also, we call it "IceFire" ;-)

Programming language popularity

Popularity ranking on programming languages.

Methogologies

Katie Lucas is writing about methodology for running the 100m:

"Step 1: write about running really fast. Step 2: Go and draw a plan of the race track. Step 3: go and buy really tight lycra shorts. Step4: run really, really, really fast. Step 5: cross line first"

She has a point about RUP methogology also. Read it.

One good thing about VCS

Now I keep all my documents in version control system (Subversion). Thanks to Martin. Previously I doubted for a while before pressing delete button, now I feel much comfortable while removing things from my documents. If I don't need them now, I have no mercy, I just remove them, this helps to keep things clean and simple and there is no difference, will I need something in the future or not, it is always possible to reverse changes.

One good thing about VCS is possibility to feel yourself more confident on a journey to genius simplicity.

I have changed template for this blog

My collegue asked me to change the look and feel of this blog. Those, who started to read it from the very first post, may remember, that I had a white text on a black background. I read somewhere, that it is more friendly for your eyes.

Now you have to thank Maksim for being so cruel to your eyes :)

Functional tests automatisation

I have been asked to describe the value we can get from functional tests automatisation.

Systems with feedback loop.

System with feedback loop usually adapts its behavior according to the outer conditions, for that system needs sensors to catch outside changes. The most trivial example can be the system of traffic light. The most simple traffic lights have certain interval for switching lights. They don't have feedback loop. Now imagine, that you are standing at such kind of light and waiting for 5 minutes, although it is late night and there is no cars on the crossing road :( To improve your customer experience ;) this system should be upgraded with sensors, which will check for cars on the road and switch lights according to that. Now it is the system with feedback loop, it changes its behavior according to traffic conditions.

Feedback loop is needed to be able to react to changes faster.

Tests are sensors of software development system.

Tests in general can be treated as sensors for software development system. As soon as tests find unexpected behavior, developers react and fix them or alter changes made to the system. Now it comes to reasons, why we have to automate tests.

Fast sensors

Everybody agrees, that we should find bugs as fast and early as possible. Ideally the next second after developer introduced a bug into software it should be found out. Unfortunately we don't live in that ideal world, but automatisation can bring us much closer to it. Having automated functional tests, we can use them to check, did developer changes affected existing functionality or not.

Continuous integration

Continuous integration is used for assuring, that developed system is constantly in a good shape, every peace of software written by different developers, pairs or teams integrates with each other successfully and behaves according to expectations. Currently our continuous integration process includes source code automatic analysis, software building, automated unit testing. Unfortunately it is not enough to assure, that accepted business functionality behaves the same way, as it has been behaving before changes. Those kind of tests currently is done manually only during final release test, which may happen even months after changes has been done. Our sensors are so sloooow.

Good system design

Good system design can be achieved only through constant process of design improvement. You can not make good design well once and then relax. Constant improvement of design means, that parts of the system, where some bad design smells are found, refactored to better structure. Refactoring means changes which does not affect behavior but improve internal structure of the system. Refactoring requires a lot of courage from developers: while changing structure it is always possible to break something. Automated tests give that courage to developers.

Our system

Our system is full of bad design smells. Developers afraid to change it, because something can broke. There are two options to improve situation:
1. We can start from scratch, but we will run into the same problems after some time without automated functional tests.
2. We can create automated functional tests for existing system and then start to refactor it, getting its design better and better.

In conclusion I can say, that need for functional tests automatisation is obvious, and I can not understand those people, who is still doubting in that.

2 ways of management

I have recently recognized two different ways of management:
- management through processes
- management through empowered teams

In fact I knew them for a long time already, but just recently I recognized, that those are two controversial ways of management and according to my personal core values I support management through empowered teams.

Processes are good

I have heard the statement, that "The big number of people can be managed only through processes". Nice, we have tried that. It came out, that bright people don't want to be managed through processes, at least processes, which has been established by so-so colleagues. But still, processes are good. They help to organize our work. After process has been agreed, it should be reviewed regularly to understand existing shortcomings and find more effective ways of getting things done. Note that in order to be able to fix a process quickly, it should be very lightweight.

Processes weights

If you have a big bunch of rules, papers, positions and regulations signed by CIO, you will not be able to optimize this kind of process easily. I suppose, that having such heavyweight process supposes that you also have a process manager. Oh, I love those guys, they know, how to create blanks for documents, describe processes by activity diagrams and prepare regulations for CIO signing, useful, isn't it? How we can measure, is this particular process light- or heavyweight? I would measure it by the time and effort spent to introduce changes into a process.

Changes

Have you heard, that people usually want to improve very much, but they don't want to change. How it is possible to improve without going through change, I don't know. Changes are hard to accept, hard to get everybody's commitment, hard to plan, hard to manage. Kent Beck has been saying, if it is hard to do something for you, you have to do it more frequently. By the way, this is the reason, why I am writing this blog ;)

Comments in source code

Today I have been asked again, why we don't require comments in source code. We have discussed this issue a lot of times. Right now I feel, that I have to write my thoughts down, not to repeat myself in further discussions, kind of reuse, you know ; )

By the way, we do require comments on version revisions and you have to bring a beer, if you have commited changes without a comment.

Comments are part of documentation and that is why I would like to refer to very good essay on documentation by Scott W. Ambler. He is one of the few persons in software development community whom I respect very much.

One of his critical points says, that you can not trust documentation. Comments neither.

Here is an example:

// this method sums first and second parameters and returns the result
public static int sumTwoNumbers(int a, int b) {
    return a*b;
}

This creates a very serious implications on developing and maintaining documentation (source code comments in our case).

Here are reasonable arguments, why we should document(comment) our code?

1. Our stakeholders require that. Lets think, who is our stakeholders in case of source code comments? Mainly they are other developers and managers. They think, that after you leave the company, it will be easier for others to understand your code and your design decisions. I assure you, that if we follow simple rules: don't develop alone, practice test driven development and use meaningfull names, we will achieve even more, than only through commenting our code.

2. To define a contract model. This mostly is needed, then external organisations or groups are involved. Source code is so intimate thing, that we will not publish it to external organisations. If we need to invest into contract model development and maintainance, we'd better keep it separate from source code, thus comments should not be used for contract model describtion.

3. To support communication with an external group. The are other good ways to communicate your decisions through source code: unit tests and meaningfull naming. You should understand, that commenting is your option of last resourt and you should use it only if you feel, that source code does not communicate all details properly.

4. To think something through. Well, to use comments for thinking something through is kind of noncence for me, but use it, if you know how. Don't forget to delete it, after source code is ready.

Please, read Scott's paper through to get aquanted with questionable reasons for creating documentation and other important issues concerning effectivness of paperwork.

Computing as a commodity

I have listened to some guy from Sun on Gartner Symposium. While talking about Sun’s new pricing policy, he also mentioned that Sun believs, computing becoming a commodity, as it happened to electricity. You will not buy computers, but a computing power/hours. Here is the story.

How it will influence us, software developers? For me the picture is more than attractive.Then the computing power will become a commodity, our organization will not maintaine its own servers, but will buy computing power, standardized by all means, from suppliers. And there will be no need to overcome on daily basis operation guy's bad mood, unwritten requirements and wishes to teach developers, how to develop software :) I am eager to see it happens.

Patterns share

Patterns is intended to help us in solving similar problems without inventing a bicycle, although helpfulness depends very much on the author and the way pattern has been created.

Well known software development community pattern writers are Martin Fowler, GoF, Gregor Hohpe, Eric Evans.

Microsoft took an initiative to bring software development patterns together to show relationships and increase pattern usage by software developers and architects. Many thanks to them!

Blogs review

Decided to make a review of blogs I have visited. For history and reference. Those are important and interesting for me. I will also contribute some comments to express my opinion on issues. Here you are:

Jon Eaves (ThoughtWorks in Australia) blog
Reviewed from today till the start of October

Very good explanation, why we have to care about Organisation Goal Alignment

Some thoughts about investments into test automation. I liked the section about non-test infected developers, who are frustrating co-workers by ignoring written tests. We have such kind of people in our organisation also.

Jon is talking why poor developers are resisting Agile processes. Having the fact, that 70% of all IT projects fail, which means, that we have almost the same percentage of poor developers, it is a tough challenge for agile movement to become a mainstream :(

It reminds me something: The Bulimic Domain Model. Don't you see a recognizable curves? There are only two options, to give up or clean up, what is you choise?

Something for managers. By measuring individuals only for THEIR work being done is counter-productive. It also scales up to the level of departmens, if department as a whole cares only about its own duties, we don't have any chance to succeed as an organisation.

Read carefully through, this is serious: development environment smells

Everybody's code sucks. Yours also, for different reasons: here and here