No, this isn’t another docker blog post that surprisingly uses a container ship to explain stuff. This is about looking for a better analogy for agile organizations.

I usually have a problem with those cliché examples given to describe agility. We have already moved from thinking about the agility in the relatively narrow context of software teams and extended that to the whole organization to cover the whole chain. (This also follows the lean principle of optimizing the whole) So examples should resonate more with larger, more heterogeneous environments. Resilience, adaptation and survival should be possible to observe through the organization.

Numerous examples from real life is given to show difference and advantages of agile organizations. Introducing new concepts using examples that can be familiarized helps the story.

What examples do we often see trying to symbolize agility and rigidness ?

Looking at the certain parts of the software engineering discourse, it may look like kubernetes has already become the defacto deployment environment in the world, but that is hardly the case.

Still, majority of the work runs on virtual machines. Bare metal servers are still around to meet certain requirements. There are many reasons for those and some of them aren’t quite possible solve. So there are a lot of engineering teams around the world who have never worked with containers, let alone kubernetes.

In this post, we will visit some points (definitely not an exhaustive list) to consider in the early phases of kubernetes journey to get results easier. When executed carelessly, adopting kubernetes can become a painful, demoralizing problem and it can alienate both business and engineers.

Nassim Nicholas Taleb’s books are influential in many areas and across many disciplines. It can change how we view and interpret the world. In The Black Swan Theory and Why Agile Principles Fit Better, we went on an adventure trying to explain why creating software with agile principles fit better than other approaches in a world described by Taleb.

In this post we will visit Antifragile, and see if we can find some more lessons for software engineering.

We went through a painful outage of Atlassian products. It was difficult for engineers on both sides.

The criticism on the social media about Jira often amazes me. While some of them are right on spot, there are some others that point towards not so optimal, sometimes plain wrong usage of Jira. In this two series post, I will list both antipatterns and best practices to use Jira effectively, from my experience.

Over the last few years, I increasingly come across the phrase doing it right at the first time (DIRFT) in the context of various applications of software engineering(infrastructure, cloud, microservice design as well)

However, it causes damage to the efficiency and value delivery of software engineering when it is shoehorned to software engineering.

In the rest of this post, I’ll visit the dangers introduced with this approach.

For many, software engineering seems like mostly focusing on bits and bytes, disconnected and isolated from the hassles of real life. One can sit in front of the screen for hours, trying to solve a problem in an appropriate way..until the product manager comes and asks something “very urgent” out of nowhere…Or until that lucrative contract falls..or until.. Or may be, software engineering is not isolated from the hassles of real life at all.

Behaviour Driven Development is one of the most useful approaches to write high level tests that are understandable and even writable by anybody who has necessary domain knowledge. In my favourite syntax, Gherkin, a test would look like: 1 2 3 4 5 6 7 8 9 Feature: Hungry Cat Behaviour Scenario: Given I am a cat And I have not eaten anything in the last 30 mins When I see a spider And the spider is reachable Then I pounce on it And I eat it Then I would write my glue code in Cucumber and generate reports.

Everybody experiences a certain period of adaptation in a new work environment. This is not just about learning about rules and internal resources. This is also about figuring out the collective mindset and values specific to that organization, or learning the culture. I decided to split this post in to two parts. This part focuses on main characteristics of a culture and the second part contains the list of foul smells that you should be aware of.

Now that we have visited common characteristics of a culture, we can continue with the smells. My incomplete list includes smells that are more tangible, smells that come from people (well..) and smells that are more organizational (but still not by rule). It is the people who keep a culture living. So if you spot something, it is probably because majority of people has no problem with it. Therefore the conditions I describe below will not worry most of them.

Windows Subsystem for Linux(WSL) has been on the frontpage for sometime because of its bold claim to bridge the gap between linux and windows experience in a completely new way. In this post, I will go over my experience of WSL(s) from a perspective of heavy Linux user and Java developer. The next post will include my take on making the environment reproducable. Setting the expectations I started using Unix around 1996 with Solaris 2.

In February 2018, I was diagnosed with my gall bladder full of stones. It had to be removed. It is normally a very simple operation that you leave the hospital next day. As a person whose life is mostly governed by curiosity, I had to learn about it. So I watched the training videos recorded during actual operations and read scientific material. I also searched through the internet to read about other people’s experiences.

You just bought a new software for your work. After considering alternatives, you decided to buy this one. It looked much better than the others. You installed and started working. Everything seems fine. Suddenly the power went out and your desktop is now dead. When the power came back, you restarted your desktop and opened the application. It was empty as if it was the first time. But you have been working on a document for hours.

Problem It is a usual struggle between R&D leads and developers. R&D leads need to have correct timestamps in tickets, in order to be able to calculate vital information like cycle times. This requires people click buttons in jira whenever they start working on a ticket. This rarely happens. Most developers do not care about JIRA because it is mostly useless burden for them. You can not blame developers for that.

Java projects traditionally use maven release plugin. However its shortcomings have already become a bigger problem with today’s continuous delivery requirements. In this post, I will write about an approach that does not use this plugin and works actually much nicer. What is Continuous Delivery Continuous Delivery is producing software faster (preferably after every single merge) rather than in big release cycles like weeks or months, so that there exists a stream of potential production grade versions that are ready to consume.

Whether you do Kanban, Scrum, 6-Sigma, Lean, waterfall or any one of the methods defined brilliantly here, there is one fatal flaw that can ruin everything hiddenly, while all your metrics showing everything great. This “little” thing is, goal setting What is Goal Setting ? In short, goal setting is defining strategic targets and developing plans to reach that goal. Even though this is considered a management topic, it is valuable to be familiar since it enables one to understand the steering and alignment in a company.

A common mistake recurring in software teams is logging work hours in tickets, even worse, using them to make estimations. Usually the intention is to measure who spends how much time while solving a particular ticket. In such cases, engineers are expected to log their effort every time they do some work on a ticket. This is neither correct, nor good way of measuring efforts. (Unless you log it for the billing purposes, but that is still not related to software development improvements)

Security becomes a bigger problem every day, as more code is written and more infrastructure is designed. Why does it feel like we are not improving ? Why do we keep getting shocking news every now and then ? Even though there are many documents, best practices, preventive measures, whether simple or complex, cheap or expensive, why does it feel like we are not able to improve ? There are multiple reasons for the situtation we are living through.

Imagine engineers working at a production line in an assembly plant. One of them stops working, turns around and shouts the others about how to use the certain function of a robot. Everybody stops working, raises heads and listens. One of them says he knows and comes next to him to explain. Then he goes back and starts where he left off. If such thing ever happens in plant that cares about operational efficiency, the engineers would ask the question:

The Chief Architect of the Java Platform Group Mark Reinhold has recently blogged about his vision about the future of Java’s release management. The ideas generally received positive feedback except his idea of using time based versions. Semantic versioning doesn’t work well with time-boxed releases. #javatrain https://t.co/lJrEomjf8f — Mark Reinhold (@mreinhold) September 6, 2017 Time based versions are gaining popularity. We see more products changing from semantic versions to YY.MM formatted ones.