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 30mins 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.