I am a business oriented, data-driven engineering leader with 24 years experience in creating/maintaining critical, scalable, resilient software solutions including global markets.
I work on outcomes, efficiency, quality, risks with a lean, transformative mindset
Myths and Mistakes About Product Owners
Once upon a time, there was only product manager. Then the concept of product owner came in to the picture. It puzzled many, because we were creating software products before and there were people leading products. However, it became impossible to keep up with the demand for increasing the frequency of impactful releases with sufficient quality while maintaining current roles and communication structures and tighter feedback loops. We can observe indirect impact of Kano Model on software products in terms of increased workload and expectations on product managers.
Why Many Young Engineers Struggle in the First Years
Back in college, we had a professor whose exams contained some questions that people found to be notoriously difficult compared to others. To get a score higher than “good enough”, we had to solve questions that include problem combinations that we never came close during the lectures. I did not understand why he was doing that back then. What we had seen during the lectures, was enough to cover every piece of knowledge needed to solve those questions, but only few were able to solve all questions.Why Our Infra Integration Code Keeps Changing
Years back, we had a maven dependency that was part of a large project for many years. It was coming from a few Java versions back in the past (Those were the days when a new release of Java was a rare event to witness). But it was working just fine, no tests failing, nothing new needed. It didn’t make any stability or performance problem at all. It didn’t have any dependency that might need an update.
A Better Analogy for Agile Organizations
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 ?
Do's and Dont's When Moving to Kubernetes
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.
Is Software Antifragile ?
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.
Top 10 Anti-Patterns Using Jira
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.
Doing Things Right at the First Time..In Software Engineering
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.
The Black Swan Theory and Why Agile Principles Fit Better
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 maybe, software engineering is not isolated from the hassles of real life at all.Using Different Programming Language to Write BDD Tests
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.
Culture Smells in Software Teams - Part 1
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.Culture Smells in Software Teams - Part 2
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.Experiencing WSL as a Linux Veteran
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.How to Prevent The Influence of Echo Chambers
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.
Kano Model and How Do We Disappoint Users While Being Agile
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.How to Change Jira States Automatically
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.Continuous Delivery and Version Handling with Java, Maven and Jenkins
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.
Dangers of Setting Goals Wrong in Software Teams
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.
Issue Tracking Anti-Patterns: Logging Work Hours (and Solutions)
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)
Reasons Why We Keep Making Security Flaws
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.