Watch 'Crazy House', on Friday, after 3 pm, at your work.

If you are lucky, while working on an open space, sometimes, you may see people running back and forth, impinging each other and behaving exactly like headless chickens - especially after 3 pm on Friday ;) The reason why you may see that somewhat peculiar picture is because of either somebody's birthday (i.e. cookies and doughnuts) or production issue ;) Check your mailbox and if there is no email about doughnuts, it has to be an issue on prod!

Usually, managers refrain from communicating a problem to business, before getting some initial knowledge about it. However, do not be mislead by lack of email. That state would not last long. That is actually the time, when managers start to create an Asterix and Obelix 'Crazy House' cartoon atmosphere, harass developers, L3 or any other support team. Of course, they think they do their best to behave in a calm and professional way, but subconsciously they do what all people do, when they are jeopardized - they are clustering into harassment groups behind the back of (un)lucky developer, creating totally unnecessary pressure. 

Then, there is a time for usual questions cannonade: where are we, what we know, what is the risk, what is happening, what are our options etc. You may have an ironic answer for all of them, but you must keep a poker face.

In fact, calmness is your bless. The more clam and methodic your approach would be, the sooner you would be at your home sipping whisky. So calm down and follow below steps:

1. Ask for a little bit of context and clarification what they think is all that fuss about.
2. Do not easily believe what 'headless chickens' are saying ;) Check it yourself. If they knew what is going on, they would not harass you ;) Simply ask for evidence based on which they raised an alert. It might be a monitoring screen shoot, DB query, logs, whatever. You may see something, they may have skipped. Also, it is pretty common that people misinterpret what they see and hit 'panic alarm' straight away. It happens, you must live with that.
   You may also ask a couple of context enriching questions like 'who said that' and 'based on what premises you thing so'.
3. If you really can smell the issue, do an initial investigation and try to estimate:
   - impact
   - risk
   - also it would be marvelous, if you could apply some trends checking here.
   If possible, check whether same or similar situation was happening in the past. Perhaps, it is a regular behaviour.
4. If there was something similar happening in the past, try to dig out the knowledge about that issue and its remediation. JIRA ticket, conversation with other peers in the project, basically anybody or anything might be helpful.
5. If not, then it is a genuine issue, which has to be investigated.
6. If you finally come across the solution and it involves a fix on prod, try to mitigate its risk, by doing the smallest possible change. 
   Remember: small change = small impact (according to stable system definition).
   Assess minimal, optimal and maximal downtime of the system vs. you SLAs. Communicate it clearly to your business stakeholders, prod services and managers.
   Also do not let them suggest solution, unless it has reasonable base.
7. Test your solution on prod like environment (including starting and stopping your app) and write full sequence of steps. Do not let anybody add/change/remove any of steps, before agreeing it with devs, prod services and testing them properly.
   It's better to have a broken system, where you know what is going on, rather than possibly fixed one, where nobody is entirely sure, if and how it's gonna work.

Class naming convention and information theory

How many times have you seen classes named with one of these suffixes: manager, util, helper, common, impl etc.? How many times have you seen columns in same DB table called *_id? Probably far too many. 

Have you ever thought about informativeness of above suffixes? Isn't it loosing its point of passing a piece of information to other developers, when it is overused? To be frank, it looks like a noise, a message which is blurred by useless words. The more often those funny words occur in code base, the less information they carry. That is actually, what Shannon said when he was building keystones for information theory.

In fact, it is very important, to give a proper name for a class, DB column name etc. On the other hand, it is also very significant not to overuse same words all over again in names. It is not only getting less readable, but also adding a kind of boilerplate, giving no informativeness value, at all. There is of course a value in pissing other developers off, but I guess it is rather doubtful pleasure ;)

Real options come into being in real life

About two weeks ago, I came back from my holidays, where I, my brother and our friend spent time wandering in the mountains. We love hiking and we have many friends sharing our passion. Having such a hobby, it is almost obvious that there would be a constant, informal competition between all of us. When we meet with our friends, we often spend time discussing different tracks, unexplored routes and places, transition times between places etc.

We know that three of us create quite strong and reliable team, where everybody can count on each other in difficult situation. We have proven that plenty of times and we know, what we can expect from each other. That is why we decided to break out our friends' records. We were aspiring to establish three records in terms of: longest track, longest time spent in the mountains walking and the biggest total elevation crossed during entire trip.
We chose a track and prepared gear to go out, in the evening. We got up at midnight and went out. At 6 am, we were sitting at the highest peak on our route, delighting in the sunrise, at the crack of dawn. We took vast amount of photos, made a GoPro movie and went further chasing our records. Nothing was bidding fair our breakdown. 

We started to feel lack of physical power and motivation at about 16th hour of our wandering. All of us knew that feeling. We were trying not to talk about it, as it might have depressed others even more quickly. However, the truth was that we ate all our food, snacks, sweets, fruit and recovery gels. We also drunk entire water, isotonic drinks and tea we had with us. Each of us was motivating others to walk, being on a last legs same time. We were extremely suffering from lack of mental and physical power.

The interesting thing is that when you are fed up with everything and you hate your decision about breaking records, you miss your bed and glass of water, then you can transform that internal anger and find some more mental strength. It was helping us with keeping on pushing forward. 

Having one hour left to our stop, a shelter, we met very tall guy, standing on tracks cross and checking something in a map. He asked us how long would it take to go down following track he was pointing to.
We had just looked on each other, silently agreeing that the tall guy was completely lost in the mountains. However, he was talking so fast, and was so convinced that he is in a totally different location that we gave up. We did not have enough energy to argue with him. We waited, when he finished and told him: "You are in wrong valley, mate. You have about four hours to get to the place you would like to be and additional one and a half to come down". We were persuading him that the only choice he had was to follow the route we would be going down. The tall guy told us that he could have done that path in about three hours, as he is training ultra marathon running. We said okay, you might be right, however bear in mind that sunset would be in top thirty minutes, you have no food and water in a just one third of your camel bag and that is not all. The most dangerous thing was a bear, which was living in the neighborhood and approaching tracks from time to time. The tall guy admitted it was pointless to go to the location he wanted to be and bearing in mind sunset, lack of food and unwanted hand shake with bear, he decided to take our piece of advice. He decided to run down along route we pointed to him.

Before he left, we gave him an option of coming down with us through the forest, as we know that track very well and we had head lights. Also, we said that we had to stay for twenty minutes in hostel to buy some water and at least one Snickers per person.

Initially, he was reluctant and decided to run down himself. However, when we reached the hostel he was waiting for us with his mind changed.
He found our option useful and decided to exercise it. All of us went down chatting and laughing. At the end, he offered us a lift home, which we took as a miracle, as we were extremely exhausted.

It was the other day, when I realized that we had offered the tall guy a real option. It was having all option's properties like: 

• value
• expiry date
• event transforming an option to a commitment

Option's value is not that easy to estimate. But, when you spare a while, thinking about it, you would probably come to the conclusion that you do not need to know its exact value. Humans are good in comparing and prioritizing, but they tend not to give correct absolute values. Thus, comparing is very good technique of evaluation options. It was obvious that the only other choice the tall guy had was to spend a night in the mountains, hugging with the bear (if lucky enough). So, basic comparison of two options gave him a fairly good understanding of his priorities. He had chosen to go down safely.

Expiry date was actually determined by the last point he knew for sure we would be heading to - the hostel.

Transformation moment was a moment, when option stopped being something, which may happen in the future and became a commitment of following three, exhausted guys. He knew perfectly well, why he would exercised that option. It was better for the tall guy to go with us, instead of spending a night in the mountains.

The conclusion is simple: real options are everywhere. They surround us. The only thing we need to do is to start thinking about them and seeing them. 
The most important lesson learnt for me is fact that even in very difficult situation, in unfavorable conditions and being on a last legs, one can still come up with a real option, which might be exercised.

Definition of Decent Failure

Being software developer and failing seems to be inseparable. Is it right or wrong? Is it something we should worry about? Is it really inscribed into developers every day life? Does it affect only us, developers? What does failing mean? When is it good to fail? Can we always fail?

Well, one may say that my questions look more like existential considerations of philosophy students, rather than a topic for a blog post. By and large, it would be a correct statement, however there is a subtle thread connecting software development and failures, which is leading me to these questions.

Life means development
Eastern explanation style will definitely try to do two things:

• use outside-in approach (deduction)
• try to percept a life from the perspective of what it can bring to us.

There is one thing we constantly should try to do in life. It is a self development. One of the most expressive and direct examples of such a philosophy, were Japanese warriors. They were spending whole days mastering their skills, so that they were better prepared to serve their masters and for inevitable situations like life, fight or death.

Development means progress
Going further, that self-development clearly meant progress. It was progress not only in terms of physical skills, but also in terms of mental strength, world comprehension and the sense of life.

Progress means series of experiments
Samurais knew perfectly well that their progress was depending on their hard and tough training, topped with dealing with unusual and unpredictable situations. These peculiar situations were in fact devoted to testing and verifying theories, processes, phenomenons and hypothesis they were thought during their life. 
The most valuable warriors could shift all what they learnt into series of experiments, so that they could prove themselves and their knowledge. It means that most distinguished samurais were experimenters.

Series of experiments mean experience
However, not only that. Samurais were also experienced and educated people in many aspects. 
There is an interesting intuition related to experience, among people, namely old age and hoar. Aged warriors were considered as privileged people, following at least below rules: 

• there are many paths leading to the same place
• choose the right path (minimize the risk of loosing life, health, family etc.)

These two, rather obvious statements, are barely prerequisites to the most instructive parts of each experiment i.e. a path and a result. Therefore, from the very beginning samurai's were made sensitive to two observations:

• each valuable experiment has a result
• experiment without any result is a pure waste.

It means that every, single action should have an effect. An effort without any result is waste of time, energy and resources.

Experience means failures

Going further, every result can have one of two values: true or false. Incidentally, it is worth to think about experiment in terms of test. Test is a scenario, which exercises some idea, question or system and evaluates to a result. 

One may ask, which result value is better: true or false? Hmm ... that's actually a very good concern. Let's ponder on it for a while then. 

The result, which is true, shows you that hypothesis you have in mind, is correct. Also, it shows that path you have chosen was not too severe comparing to your current level of experience. It confirms your believes. On the other hand, result equal to false, is showing you much more. It tells you that your assumption was wrong. In the samurais' world, every situation in which they failed and were not causing too much damage to themselves, family and other people or things was invaluable. Why? Because, by failing they did a recon of area they were unsure, hopefully with low cost (e.g. few bruises or broken ribs). By failing in a relatively safe way, they lower the risk of entering unknown area in the future. 

Fail early, fail often, fail fast with decent failure

Samurais' were able to see a value in discovering limitations and risky areas. They greatly appreciated early intelligence and impact of actions they did. That is why, they were mastering their skills on a daily basis. Tough and repeatable training, body memory, permanent checks of their mental and physical limitations, fights with bokkens instead of katanas, self defense without weapon and against weapon etc. All of that were tests in isolated context, aiming to train and solve difficult and unusual situations, as well as common manoeuvres happening on a battle field. They were treating their body as system, which needs to be under constant test. By looking at that problem from different angles and considering many aspects of each perspective, they were hardening their minds, bodies and hearts for ultimate test - real life. 

All in all, failing seems to be a good thing. However, we have to bear in mind that we cannot just fail. It has to be a controlled failure, something which I call a decent failure. In fact, it is a regular failure holding three, below properties: 

• early - saving time, don't go through all process to get a feedback
• often - frequent feedback
• fast - short feedback loop

Be okay with the decent failure

Having a decent failures mechanism in place is actually great success!! Decent failure is the best thing you can experience, as it shows you all your limitations and pins down the problem in a safe and quick manner.

German General von Manstein about Agile

Fifth principle of Agile Manifesto says: 

"Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done."

Before you build a project or to be more specific a team, you have to choose 'motivated individuals'. Above rule is just a general guideline, not telling you anything how to do it. So the question, related to the way of choosing motivated people, remains open and is somewhat worrisome, as we still do not have a simple and clear protocol how to do it. 
To be fairly honest, it is always hard to give one, neat and concise rule describing what to do. However, instead of that I will quote German's general, von Manstein of the German Officer Corps, rule to be used as a tool for choosing motivated employees. 
Von Manstein used to divide his soliders into four groups:

1. Lazy and stupid - leave them alone, as they are doing no harm
2. Hardworking and intelligent - they would be an excellent staff officers, they can ensure that every detail is properly introduced and considered
3. Lazy and intelligent - these are people suited for the highest office
4. Hardworking and stupid - they are a menace, who should be fired at once, as they create and add irrelevant work for everybody aka "cannon fodder"

The rule is rigid and acute not living any space for people being in between.
It is not the most detailed approach, however we can leverage its features, anyway. It can be treated more like a filter, rather than just a simple rule. It gives us some view on who we should avoid. It also tells us about rough activities and positions people may hold.
It is not the best rule allowing you to choose 'motivated individuals' , but it is definitely the very first step on that path. 

The Pareto Principle
It's also worth to know Pareto Principle, which says: 

"80% of your results will come from 20% of your efforts".

It means that you need to work hard to identify 20% of things you do, which generate 80% of what you do. In other words, this principle teaches us how to be lazy and not to fall into the activity trap. Be honest with yourself, nobody cares how busy you are, they just do care what you produce. You don't have to work hard. It's better to decide, what NOT to do, so that you have more time for valuable 20% of your core activities, which gives you 80% of return of your time investment (ROI).

Self Assesment
So what you can do now, is to assess your position against von Manstein and Pareto principles and see where you are. Sometimes it might be very painful process, but definitely it's worth doing that. If you are finding yourself too low in hierarchy and you are willing to pull yourself up a bit try below clues:

• Don’t try to keep all people happy all the time
• Have a work plan managing your time
• Practice saying “no”
• Don't stuck in one square, say Smart and Hardworking. Try to improve yourself, change your character, so that you will be eligible for another square: Smart and Lazy. Train your laziness in an intelligent and smart way.

Manager in Agile team.

There is no manager in Agile team.

It might be hard to believe, but developers know what needs to be done, as they have backlog and their own brain!
They do not need another guy, who is cultivating seagull management. 

And now shit load of stuff is getting a new meaning :P

Which game are you playing ?

Few days back, I spoke with my friend about pretty "funny" situation. He told me that developers at his project are playing a game, which my friend called Pair Programming vs. Code Review. If developers like each other, they play Pair Programming. If they do not like each other, then they play Code Review.

As you can see those developers found a problem, where it was not even existing. That's a rare and undesired skill, which often manifest itself in pseudo pragmatic teams, who are probably not sticking to 5th Agile manifesto principle: 
"Build projects around motivated individuals. 
Give them the environment and support they need, and trust them to get the job done."
Generally, it is called over-engineering! But not only that, they are loosing time for guerrilla warfare, rather than focusing on helping each other. They also seem not to have any respect to each other. 

The question is: should it be this way? Of course, no!
I would like to be clear about Pair Programming and Code Review, so let's start from some definitions.

Scratching Tiger, Hidden Dragon - Pair Programming

One developer types in code at the keyboard. He works at the tactical level. The other one looks for mistakes and thinks strategically about whether the code is being written right and whether the right code is being written. 

You can also describe pair programming in a more holistic and tao oriented way, as a yin-yang or a unity and harmony arousing from diversity. There are many approaches explaining principles of pair programming like coder and observer, driver and navigator, however I am always keen on scratching tiger and hidden dragon parallel. 

In other words, it is a conjunction of opposite features like active and passive, linear and non-linear or specific and general in a collective action such as solving a problem - programming in this case.

To be fairly honest, one can extend and generalize this approach to any sort of task you have got to do. 

The overall idea is very easy to grasp and simple. Let's look at pair programming from two, different perspectives: tiger and dragon.

Scratching Tiger:

1. Active person writing the code, almost scratching it
2. Keeps on focusing on syntax and details
3. Uses his linear part of brain, logical (left) hemisphere to solve arousing problems

Hidden Dragon:

1. Passive person pays attention to code quality and acceptance criteria fulfillment, almost like dragon, flying in the sky and observing what tiger does
2. Can see whole solution, has an overall idea of subsequent tasks and steps
3. Uses his non-linear part of brain, abstract (right) hemisphere to imagine a flow and grasp the bigger picture

You would probably agree that above description is somewhat static and simply a bit boring. Frankly, you are right, but the key here is movement and synergy you can get from it.

How can we get the movement ?

Again, this is simple. You need a proper space. Comfortable desk, two chars and two keyboards. These things are really important, so do not neglect any of it, especially two keyboards. These prerequisites enable higher level of collaboration between developers. Apart from that they are not loosing time and ideas, while swapping keyboards.

And now comes the most important part. Developers are creating a collective mind, which is buzzing and boiling due to new, fresh ideas. The worst thing you can do, is not switching between Tiger and Dragon role. You have to do it frequently, without any hesitation and freely. You cannot be afraid of your partner saying leave that keyboard, etc. When you see Tiger did a typo, initialized a loop in a wrong way or did not do refactoring, which might be done - simply take over and use your own keyboard to fix it. You need to change perspectives very often and switch your brain from linear to non-linear mode and vice versa. That is the only way you can solve difficult problems. 

Why pairing on solving tasks?

Mainly because of four reasons:

• Readability - two people take care about readable code, both of them have to understand what was written

• Code quality - percentage of defects found 40% - 60% (Steve McConnell "Code Complete")

• Bus factor - knowledge sharing and mitigating the risk of single point of failure

• Pressure - group shields developers from external pressure much better than single developer can protect himself. What's more, in stressful situations people tend to cluster to face difficult situation.

Okay, so when it is worth to pair? 

It is definitely more expedient to pair on crucial and strategically important tasks. It is also useful to pair on both very hard, non-trivial implementations and medium level difficulty tasks. There is no use of pairing on relatively easy tasks, as they do not add so much value, comparing to effort.

Always remember about rotating pairs, not giving an opportunity to get used to your partner. The efficiency is decreasing then. Moreover, it is also good not to pair newbies, as there is not master-apprentice relation, which negatively affects pairing process. Definitely people need to like each other.

Code Review - No junk in a trunk

It is a sort of semi formal walkthrough the code aiming to:

1. share knowledge (mitigate bus factor)
2. check design from high level perspective
3. check at least SOLID rules appliance
4. check definition of done (DoD)
5. increase resilience before holidays

When can you perform code review?

Of course after development and testing, but before merging to master or trunk, so that there is no junk in a trunk.

The programmer or pair, who developed a solution, walks some other team member through new code. They start from telling the story and acceptance criteria, then they are explaining applied design and showing working, green, CI  system tests. There is also a place for Q&A and potentially some code review remarks or changes. Code review is able to discover between 20% to 40% of defects (Steve McConnell "Code Complete").

Summary

Code Review and Pair Programming are two, complementary techniques improving the general quality of the provided solution. Apart from that they mitigate the risk associated with bus factor, by knowledge sharing.

Both of them create a useful unity in development cycle. 

You may even use scratching tiger, hidden dragon parallel, in this case, as well. Pair Programming would be a tiger and code review a dragon looking at the solution from the distance. 

It is much cheaper (sic!) to let developers be tigers and dragons, rather than giving them a wigging that they loose time for crap.

Rarely you have to choose between these two approaches. Then do it wisely and choose pairing. If your management is trying to be clumsy lean oriented and tells you should not do pairing, as it is a pure waste, take at least code review. Remember, half pairing is still better than not paring at all. It is always good to discuss design, start doing the most tricky bit together and then split and finish what you started separately, if time is so valuable. 

However, in fact it does not hold true. You are writing robust and clean solutions faster while paring and reviewing, than not. 

Agile Manifesto Signatory

Few days ago, I have become an Agile Manifesto Signatory :)

What's so cool about OO?

When people start reading or talking about object oriented (OO) design, there is always a bunch of quite fundamental questions appearing, at some point.

1. What does OO design really mean?
2. Does writing in object oriented language mean I am creating OO design? 
3. Why some developers despite using OO language, they do not create OO code?
4. How is OO language different from functional one?
5. What is the first class citizen in OO and functional approaches?

Let's start from the top to the bottom and try to answer these burning questions.

Ad.1. What does OO design really mean?

Short answer:
It is all about dependency management.

Long answer:
It means breaking source code dependency and diverting it, so that we would get an independent deployability.

Ad.2. Does writing in object oriented language mean I am creating OO design? 

Short answer:
No.

Long answer:
OO language is providing you a mechanism, to grow an OO code. The trick is that OO language creates an opportunity of using that mechanism, but nobody is pushing you to do so. That is why you have to be aware of what you are doing and consciously use available language features.

Ad. 3. Why some developers despite using OO language, they do not create OO code?

Short answer:
They do not know what OO design is. 

Long answer:
Some developers assume that writing in Java, an OO language, means they are so cool that everything they touch is OO. It is not true. Even worse thing is they do not know how wrong they are. This is sad, but often it is true.

Ad.4. How is OO language different from functional one?

Short answer:
These two approaches are very different.

Long answer:
These are two, entirely different concepts. Each of them has its own strengths and limitations. We have to know both sides to choose wisely what we need. Same time, we have to be aware of the consequences of our choice. 
Object oriented languages have a very good dependency management mechanism. On the other hand, functional approach is much better in terms of:

• multithreading (immutability out of the box)
• lack of states, which means lack of side effects
• flow oriented applications.

Ad.5. What is the first class citizen in OO and functional approaches?

Short answer:
Object oriented languages: objects.
Functional languages: functions.

Long answer:
Functional languages: functions.
Object oriented languages: objects, but to be fairly honest the interface is the one, who is a major player. 
As I said previously, it is all about dependency management. To be more precise, it is all about how to invert source code dependency (aka compile time dependency) against flow of control (aka runtime dependency). To satisfy that idea, we have a set of techniques enabling us dealing with dependencies:

• SOLID principles - helps to manage dependencies in OO design
• Component cohesion principle - describes forces that cause classes to be grouped in the independently deployable components
• Component Coupling principle - describes forces that govern dependencies between components

Robert C. Martin pulled together above principles and formed a regim of dependency management.

Okay, so what is the beef ?

Again, it is all about dependency management. Let's crack down some simple, but not easy example. 
Imagine a car using an engine. The Car object is having a dependency to the SportEngine. 
We may crystalize that dependency by saying that Car has a start method, which uses SportEngine's run method. That is how our initial dependency may look like:

package com.korczak.oskar.blog;

import com.korczak.oskar.blog.engine.SportEngine;
            
public class Car {

 private SportEngine sportEngine;

 public Car(SportEngine aSportEngine) {
  this.sportEngine = aSportEngine;
 }

 public void start() {
  sportEngine.run();
 }
}

package com.korczak.oskar.blog.engine;

public class SportEngine {

 public void run() {
           // here goes some engine implementation
 }
}

As you can see, we have a source code dependency pointing exactly to the same direction as runtime dependency. Source code dependency is an import statement in Car class, which associates Car with SportEngine, in a direct way. Runtime dependency tells you that Car uses SportEngine, so that it can start properly.
The whole idea of solving above problem and many other, similar issues is:
TO BREAK A SOURCE CODE DEPENDENCY AND DIVERT IT. 

That is an extremely crucial thing to understand. However, there is one gotcha here. People may think that whole trick is about diverting the compile time dependency arrow from SportEngine to point directly to the Car. This is wrong! It needs to point towards Car, but not directly. 

How can we do it ?

Let's introduce a middle man called an Engine, which in fact is a polymorphic interface between Car and SportEngine. The Car class will be using Engine interface, which would have a run method. On the other hand, SportEngine class will be implementing Engine interface. 
From now on, we have the source code dependency diverted and pointing towards Car class, at least from SportEngine's perspective. That point of view is one of the most important assumptions, which we need to understand. Only embracing SportEngine's perspective and its source code dependencies allows us to see the bigger picture. 
From high level perspective, the whole idea looks easy, however it is only a superficial feeling. In fact, we have to see the problem from three, totally different perspectives (Car, Engine and SportEngine).

Summing up, SportEngine knows about Engine and so as Car class. The runtime dependency's direction remains the same and points through Engine's interface to SportEngine class.

package com.korczak.oskar.blog;

import com.korczak.oskar.blog.engine.Engine;

public class Car {

 private Engine engine;

 public Car(Engine anEngine) {
  this.engine = anEngine;
 }

 public void start() {
  engine.run();
 }
}

package com.korczak.oskar.blog.engine;

public interface Engine {

 public void run();

}

package com.korczak.oskar.blog.engine;

public class SportEngine implements Engine {

 public void run() {
           // here goes some engine implementation
 }
}

That is what we got:

• Car and SportEngine are separate classes
• Independent deployability
• We can have many different Engines deployed 
• Module SportEngine plugs in to Car

Real life example.

The almost obvious extension would be to apply above principle on different levels like: classes, modules, components, entire applications or DBs. 

Few days back, I found that principle very useful on a DB level. We got a very tight dependency between us and other project, who had a read only access to our DB. I know that letting even a read only access to other projects is something similar to ripping the application's skin and exposing our guts to the public, but let's not discuss the root cause of that situation. The issue was pretty substantial and causing a lot of annoyance, hurt feelings and other stuff. Every single alter operation on a table like changing the type of field, its length or adding a column was a massive pain for both sides. I will only mention that adding a new table or dropping it was even worse. On a top of that we found that we have different release cycles. Basically, we were required to slow down our process, so that we would conform to the slower project. Incidentally, it was very similar to situation almost all of us had at school. Teacher had always to work as fast as the slowest person in the group, causing others to be pissed off. On the other hand, the slowest guy was also annoyed as everybody was waiting for him. Typical loose-loose situation. 

We badly needed a clutch and we found one. The solution was to expose only those business data, the other project needed, via DB views. All the rest say technical data was hidden behind views. We built these views having a well defined interface between us and them. Interface was not changing almost at all and we were independent from the other project. We still could do releases in our pace, without any other external dependency. Other guys were also happy about still DB interface and maintaining their release cycle. Typical win-win situation.  

If we examine above case, we easily find that project exposing some data was an allegory of SportEngine and guys reading our DB were a reification of Car. We simply created an interface, which diverted a source code dependency.

Show Me the Value

Do you recall a well-known phrase uttered by characters in the 1996 film 'Jerry Maguire'?

If one would like to sum up Agile practices in a neatly tailored way: 
'Show Me the Value' is one of the best approaches I have ever heard about. 

Last samurai's scream of despair in bastard project

The rule of thumb is fact that legacy projects are definitely more common, than greenfield ones. People are saying there could not be anything worse, than legacy project. Hmm ... I strongly disagree. Let's have a quick look on definitions. 
Greenfield project menas there is lack of any constraints imposed by prior work and it is like a Saint Grail for all developers. The antonym to greenfield is brownfield, which basically means an abandoned area or underused facilities available for re-use. Between these two distant concepts, we can place legacy code, as an idea more close to brownfield. So as you can see, legacy project is not as bad as people are used to say. 

To my mind, the worst thing is a bastard project, which is a hybrid of legacy code and extremely high ignorance of almost all people involved in the project, in any way. This could be detected in couple of ways, but definitely by close observation. The most common symptoms are:

• PM is telling you your project is a great challenge in your life
• PM is telling you your project is an opportunity to work with (difficult) client
• There also might be a set of legacy projects, around you, in your company, done for same client
• Lack of tests or brittle tests (extreme example: "tests" exercising code without assertions, just to satisfy coverage)
• No leading concept visible though whole project
• Huge entropy in code base
• Design screams help me or delete me
• Scream of despair of the last samurai

I can only say that it is really nothing good happening with project that came to the point, when the last samurai screams due to distress. 'The Last Samurai' in the project is that sort of person, who serves his:

• shogun/emperor (Client/Lead/PM)
• co-brothers in clan (team members)
• code of conduct (bushido)

Last samurai is always fighting for all above points. It is not only a matter of honor, but also a matter of faith in what he believes, common sense and health and safety. He knows what he is capable of, as he is a software craft master. The last samurai takes care about both his and entire crew's safety, as he feels very attached and committed to the project. He effortlessly sees the bigger picture and embeds his actions in project's context. The last samurai has also developed the ability of anticipating the future. That kind of person serves in the best way he could to his master. His rules and principles are like katana: shiny, resilient and well defined. Samurai is always true to his convictions, he never gives them up. One of samurais' rules says: "Katana wa bushi no tamashi", which means that the sword is the warrior's soul. One samurai in project is rare, but two and more of them are a true gift. 

So when you can hear the last samurai's scream of despair? Hmm ... it is a pretty tricky question, as samurai is a warrior, who is not afraid of sudden cuts and acute attacks. He does what he was trained to. The scream of distress is heard, when he is left alone. Project's Shogun is not considering his pieces of advice and has his own sick and not possible to introduce, weed-like visions. It is even worse, when the company's great emperor is deaf to samurai's begs and blind to results of his own debatable actions. It is highly probable that emperor is beguiled by some unreal promises and is working in his own business. 

Samurai means "the one who serves in close attendance to the nobility", so the worst thing for samurai is not to have a master, nobody to serve to - to be a ronin. 'The Last Samurai' movie shows Katsumoto and his co-warriors dying in unequal struggle, just to enlighten young emperor and to make his eyes open to true problems. In current world, the last samurai, can actually do one of below things: 

• try to talk, enlighten and show the correct path, pointing same time to what was done in a wrong way, if it is not helping, than
• show his problem to a panel of experts, if it is not helping, than
• rotate out from that sort of project, if it is not helping or possible, than
• change the job

Legacy project could be helpful in terms of self-development, however the necessary condition is will and passions to change it.

If a top brass is playing games, using you as a puppet and very often demanding you not to comply to your "bushido", then your ideological fundaments will start to shake. Instead of being resilient as samurai's sword, you are feeling like a wobbling jelly. It is highly probable that you will collapse. Your team lead is asking you to stop testing, so that you can deliver more crappy code. 'Quality does not matter in the tool you develop as it is not used by many people' - they tend to say. You could be also asked to write brittle tests or test your code on production environment. The only relevant thing for them is to manage to deliver before deadline. It does not matter, if new changes work or not. All this strange ideas are being justified by bizarre explanations and of course everything is for sake of client.
If you are thinking what the heck, you are right! Do not let them break your attitude and morale by constant mantra: 'Do not refactor this code'. If your team is breaking your balls, whole environment is reluctant to refactor, add tests and follow proved and established practices, there is only one thing you can do - ask yourself a question: "Would you like to be the last samurai, who moans dying for his shogun?".
I would not. That is why, I would rather stick to Tomek Kaczanowski's piece of advice and at least rotate out from that doggy, bastard project.

Golden rule of readability

Golden Rule:
Readability on a first place. It is a general rule in software engineering. Of course, everything should be done with a dose of common sense.

Paraphrased by extremists:
It is better to have a readable and not working code, rather than non readable and working one. 

Explanation:
One is able to fix readable code easily. Although the second statement says the code works, it is still not readable!

Early and continuous customer's satisfaction in cyberspace

Let's consider first agile manifesto principle, i.e.: 

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

What it basically says is that there is nothing more important for us, than satisfying our business client through:

• early delivery
• continuous delivery
• delivery of valuable software

Ideally, we ought to start to deliver something valuable for our customer from the very first day, when the project starts. Apart from that we have to remember about delivering these valuable bits constantly.

Hmm ... one may say, in reality, it is quite hard to commence delivering valuable software from the beginning of the project. 

To my mind, an important question seems to be: what is the definition of valuable software from client's perspective? The thing that only matters for business is something that adds value for them. They are 100% right, however in my humble opinion, majority of business people have slightly twisted perception of that definition. In other words, they seem to consider value in places, which directly maps to money. Whereas, a deeper look from risk management angle reveals business value in operational readiness or continuity of deliveries. This also means money, but this time not direct one. The root cause might be lack of risk management skills and not being able to see the clear, bigger picture of what is going on. They seem not to appreciate value hidden in infrastructure almost at all. In contrary, in any army, especially during the war, infrastructure like robust roads and railways or fast and reliable communication channels etc. are fundamental factors. The Second World War proved that rail and roads might be a key to transfer military units between places in few hours. 

Infrastructure, especially CI infrastructure, is not a direct business value itself. Although in IT it is something invisible (all in all everything is a software), the quality of it is a clue and creates a reliable scaffold, where business values can be spread. For instance painters always prime their canvas before painting. They do it in a fairly detailed and decent way, as they know it is a "scaffold for their vision". Infrastructure in IT pays dividend when the project lasts and even after that when it operates. So the question remais: what is a business value? Is infrastructure an added value for business? Is being operational BAU 24/7 a fair point? Aren't these two adjectives (early and continuous) a deliberate game of words in agile's first principle? Apparently contradictory, but in fact complementary statements: early and continuous delivery. In economy, they tend to say the the best business is the one, which is operating all the time. Wait a second, isn't it what we just said that infrastructure is something allowing business to be run and produce value 24/7? Yes that is exactly what we were in mind!

From my perspective, every project starts to deliver a value for business, from the very first day, either in pure business stories taken from backlog or in terms of infrastructure being a skeleton for whole business we cater. 

Now, let's focus on cybernetics, an extremely relevant and transdisciplinary science, rooted in ancient Greece and even earlier. Basically, it is an approach for exploring and examining regulatory systems in terms of their structure, constraints and possibilites. Cybernetics is only applicable when the system being analysed is involved in a closed signal loop. It means that actions done by the system causes some change in its environment and that change is fed to the system via information (feedback) that enables the system to change its behavior. Above description has two, valid points. First of all, cybernetics is a transdisciplinary science, which connotes a research strategy crossing many disciplinary boundaries, to create a holistic approach. This might be compared to generalization rule in OO languages. Secondly, definition focuses on feedback loop, as a main source of information for changing its behavior. Every scientist and discoverer may and should ask, if there is any principle or rule we can take from Cybernetics and apply it in Software Engineering?

Having all above knowledge in mind and treating it as a prerequisites let's do some cybernetic analysis and try to answer above question. Given every member of agile team is a distinct cybernetic system, equipped with some sort of feedback loop. Let's further assume that environment, we are deriving information from, is code base. Then the only unknown remains feedback loop. A source control management (SCM) tool might be perceived as a sort of feedback loop. 

Let's put under examination two very well known SCMs: SVN and Git. 

Probably all of us know what 'painful merges' are. We are exposed to them as we are breaking at least one of below rules (I was discussing that topic here):

• Baby steps
• Small scope of changes
• Short living branches 

A rule of thumb is that SVN merges are not the most pleasant things we may do, in terms of development process. Because they are so, we do not tend to do them as frequent as we should. As a matter of fact, we end up with, say one merge per day, which is done in the morning, or even not that often. We are obviously breaking at least one of above rules and we might end up with something called a 'merge hell'!

On the other side, Git as an alternative SCM solution is having incorporated merging process (or rebasing if you like) into your day to day development cycle. Complying to rules allowing you to avoid painful merges and having Git on your side, enables you to commit more often, comparing to SVN. 

Let's come back to our cybernetic experiment and SCM as a parallel of feedback loop. How do you think, which SCM is better? Is it SVN with its clumsy funny merging process and rare synchronisation with remote repository or Git, which is pushing you to rebase frequently as a part of your development cycle? It is your choice, but remember about everyday pain of all people using strategy you have chosen!

Pig in the suit

I often hear people saying we do Agile in our company. Especially, HR, headhunters and recruiters are excelling and even abusing that term, but not only. Unfortunately, there are also some developers not paying attention to that game of words. 

To my mind, there is a fundamental difference between doing and being Agile. When somebody says his company is doing Agile, for me it basically means that Agile methodology was imposed to that company. There could be various reasons for that e.g. Agile is trendy or other competitors on the market are Agile, as well. 

Actually, this whole situation reminds me a story about pig in a suit. People were willing to transform pig into a gentleman. They dressed it in the suit and started to call it Sir. The thing was, it was still the pig eating potatoes from the feeding trough.

To be fairly honest, no one can do Agile. Basically, agile is an adjective so you simply can't do it. Instead, you can be agile and that matters, not only from linguistic point of view, but also from semantic one. Being Agile is like a culture, religion or something built-in into your mind and soul. It's a particular mindset you are applying to every decision in your project or life. It's something more than process or methodology. It's the way of life, a way of thinking and approaching problems. It's exactly what Chinese call "tao" or "dao" and Japanese "do". It all means the way, route or path. There are couple of things Eastern cultures are doing in a right way. One of them is naming convention. It's simple and self explanatory. For instance the whole philosophy related to Agile may be called AgileDo or Tao of Agile (i.e. The Way of Agile).

Company adopting Agile should also adopt all Agile values and principles. It's a simple choice between everything and nothing. You can't take a couple of bits and bobs from values, a bunch of principles and thinking that Bob's you uncle. No, you have to take them all.

Next time, when a headhunter, recruiter or anybody else calls you, remind yourself about pig in the suit and answer one, simple question. Would you like to work for the pig in the suit and call it Sir?