In my previous post, I started elaboration of a simple user story about Embedded Terminal Application deployment. There we have focused on the middle part of the user story about what the Administrator (the actor) wants. At the end, I have started elaboration of the last part, i.e. what is the benefit or better to say, the quality we want to achieve.

I sincerely hope that it does not strike as a controversial idea that user stories are all about quality. But I have always been puzzled, how to conect such seeminly different things as user / stakeholder intents and measurable qualities. Until, one day, Tom Gilb (@imtomgilb) explained all of that.

First of all, let us repeat the user story:

As an administrator, I want to eliminate all manual steps required to perform before users can start using SafeQ features on the MFD, so that I save time.

In the previous post, I have asked the question, whether saving time is the quality we are really looking for. The Administrator might need to work with the system in different contexts. On one hand, we have an Administrator who needs to save time, since he takes care of a small environment and has many things at once to focus on. On the other hand, we have a team trying to prepare thousands of printers for thousands of end users and willing to tradeoff litle extra time for reliability, as long as they don’t have to work with one machine at a time.

…so that I save time.

So we are dealing with complex quality here and we need to decompose. Let us start with putting together a list of aspects of the quality the Administrators are looking for (nomenclature is not important, as long as we can agree on common naming):

  • Time or Degree of Automation per Device, i.e. time we need to spend on each device in our fleet compared to the total time we need to prepare the environment for the end users.
  • Reliability, i.e. the probability with which a particular device of the fleet fails to get prepared despite Administrators doing everything right.
  • Robustness, i.e. the probability that the process and the tools we have provided the Administrators with works correctly, meaning it delivers the results it should, coping with whatever problems (such as device misconfigurations or differences between firmware versions) which can be expected (were experienced in the past, are documented or not guaranteed by the vendor).
  • Repeatability, i.e. how difficult (in terms of manual steps) it is to repeat the process in case of failure to potentially fix the failure (such as by turning of a device, which had been turned off and thus it was not possible to prepare it properly).

For each quality, we can establish three levels – goal, tolerable and past. The most important for us is to elaborate on tolerable and also prepare measurements (please note that all qualities mentioned above can be measured) and measure the past, i.e. the current state of the art for our product.

The goal shall be elaborated as a big enough improvement over the current state and also balanced with tolerable level. Tolerable simply means, that if we get below this point (such as Reliability below 70%), the user story does not exist as implemented, since we failed to deliver on the stakeholder (Administrator in this case) value.

We have decoupled the value the Administrator needs to receive in the product, but how to put all this into the user story?
We have started with time, but it seems now, that the overall quality the Administrators are looking into are not connected only with time and effort, but have something to do with the risk of the MFD not being prepared for the end users. It sounds too general, though as we are dealing with all sorts of risks, but the qualities we are looking to are all about doing the deployment quickly, have the ability to minimize failures and recover from them as fast as possible with minimum requirement for manual steps.

So let’s move forward with our user story…

As an administrator, I want to eliminate all manual steps required to perform before users can start using SafeQ features on the MFD, so that I save time deploying the system and recovering from failures.

Please note that we are still avoiding unintentional design as we are not saying what needs to be done or how the deployment or the recovery is done.

Our user story is far from complete… next time, I will elaborate on how to connect qualities with user stories and what is the value of tests in this matter.

This approach of quality is inspired by Evolutionary Project Management and Competitive Engineering technique put together by Tom and Kai Gilb ( It is not easy, but it is elegant in its simplicity and beatiful.


It’s easy to create vertical text block selection in IntelliJ Idea.

Click Mouse wheel and drag.

Mouse wheel click is sometimes mapped to a function in operating system and selection won’t work.

There is alternative shortcut. Press ALT and drag cursor (by left click).

You’ll select vertical text block.

Newer versions of IntelliJ Idea have support for multiple cursors. Each line of selection will contain one cursor.

Common feature in many application is possibility to zoom text content by Ctrl+Mouse Wheel.

IntelliJ Idea has this feature, but it’s disabled by default.

You can enable zoom in few steps. Open Settings (Ctrl+Alt+S), search for “zoom“, select Editor.


Check the option “Change font size (Zoom) with Ctrl+Mouse Wheel“. Click OK and enjoy the zoom feature 🙂

VirtualBox is able to host 64bit guest OS on Windows. That’s useful for testing various platforms.

The trouble begins when you turn on Hyper-V Windows Feature. It might happen by installing some software or update. When Hyper-V is enabled then it’s not possible to create new guests with 64bit OS and it’s not possible to boot anything with 64bit kernel created before this feature was turned on.

In order to make 64bit guests working again you’ll need to turn off Hyper-V feature.

Search for “windows feature” and open “Turn Windows features on or off

Search for “Hyper-V” in Windows features and uncheck it.

hyper-v-disableClick OK and reboot the machine. 64bit OS guests start working again.

One of our internal projects at Y Soft R&D carried out by the Lead Developers is to prepare and maintain internal teaching materials. We have only recently started with the project and our first goal is to prepare trainings and drills for the baseline level to establish the basic skills each and every developer at Y Soft needs to know. Parts of it are also relevant for other colleagues, like Solution Architects, due to them writing and testing customizations.

Our baseline level is modeled around 4 Rules of Simple Design and we are now working on the first part, which is covering unit testing. We spent a whole day to prepare simple rules to help developers write good unit tests, defining what we call Unit Test Patterns.

There are four patterns we have defined:

  • Referentially Transparent Contract
  • Non-Referentially Transparent Contract
  • State Inspection
  • Side Effects Inspection

The first two are modeled after Classic TDD while the latter two are modeled after London school of TDD (What’s the difference?).

We are now preparing the coursework, guidelines and exercises to stick to the following outline.

  1. Unit Testing Trivia. The AAA / GWT principle.
  2. Using frameworks and tools to write / run unit tests in Java and C#.
  3. Unit Test Patterns. The Decision Flow or How do I know which pattern to use?
  4. Writing Tests using the RT Contract pattern
  5. Writing Tests using the non-RT Contract pattern
  6. Writing Tests using the State Inspection Pattern
  7. Writing Tests using the Side Effects Inspection Pattern

We want to produce internal web casts for the first three and Koans like exercises for number 4 – 7. Essentially providing contracts to write tests to and evaluating the tests by executing them on several purposedly flawed implementations.

The purpose of this is not to reinvent the wheel, but provide an easy to use, simple framework to help design and write unit tests.

Over the years, I have acummulated several acronyms, which I believe capture essence of various disciplines done right. Here are some picks from my list…


One cannot ignore SOLID principles, if you are serious about object oriented design. While this might seem obsolete, it is now relevant more than ever. One word of advice, take SOLID as a whole, do not choose one principle over another. They are not meant to be applied in isolation.

So what SOLID stands for?

  • Single Responsibility Principle
  • Open / Closed Principle (Open for Extension / Closed for changing implementation)
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion


Is a collection of patterns used in OOD. While I find rather artifical, I am still using it to remind myself of the different aspects of OOD I should take into account.

GRASP stands for General Responsibility Assignment Software Patterns, which is somewhat lame. What it really stands for are the following patterns or notions:

  • Controller
  • Creator
  • Indirection
  • Information Expert
  • High Cohesion
  • Low Coupling
  • Polymorphism
  • Protected Variations
  • Pure Fabrication

One day, I will write about what those really mean to me.


Is a recent addition, to my collection, but I quite like it. It is the threat model invented at Microsoft as part of their Secure Development Lifecycle framework.

STRIDE stands for different threats developers should take into account when capturing potential threats:

  • Spoofing Identity
  • Tampering with Data
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privileges


Simply put: Duplication Is Evil.

Gradle is great tool for automation in organization. Software developers often stick just with command line or IDE integration. Non-programmers can use Gradle GUI feature.

Just type command (or store it in batch file):

gradle --gui

Gradle gui

You can select task and execute it. There is another handy feature: Favorites. Here you can store useful commands for your Gradle build.

Gradle GUI favorites

User Stories, Epics, Themes, Agile Use Cases, Behaviors… whatever helps us capture user motivation, need and the benefit is useful and an improvement over bloated analyses and specifications which (and many developers do not notice that) just steal creativity out of our work. I am not going to write another post about the benefits of this, but I am going to elaborate on one particular use story, we have met with, which was not done right.

Before I do this, I need to first introduce a notion of unintentional and intentional design. Intentional design stems from constraints imposed by customer environment, market conditions, etc. and is best captured in constraints and conditions. However, sometimes it might find its way to user stories while not defeating the purpose. Unintentional design is quite different story, and while it seems that such thing is obvious, it is far from it.

Before we delve into the story, let’s provide some background. SafeQ application has components which run on MFDs (Multi-Function Devices or Multi-Function Printers). You all know them as those rather big devices which can do copying, scanning and printing and these days, they can also run third party applications. In SafeQ, we call these applications Embedded Terminal applications. Before they can be used, they require some kind of installation or deployment.

And here comes our use story:

As an administrator, I want to automatically deploy Embedded Terminal application to the MFD, so that I save time.

Let’s delve into it…

As an administrator…

Administrator is the person who performs the deployment and the maintenance of the system. Nothing really misleading about this yet.

…I want to automatically deploy Embedded Terminal application to the MFD…

Which is the unintentional design. Automated deployment of ET application is part of our feature set, but can be done terribly wrong, if the developers focus on the automation and not the essential part, which is difficulty and sensitivity to human error.

So, let us elaborate…

As an Administrator, I want to eliminate all manual steps required to deploy Embedded Terminal application to the MFD…

Which switches our focus from automation, to something more important… the number of manual steps (and implied complexity) of the deployment of the embedded terminal application. But we still suffer from unintentional design: deployment. What is deployment? Even when we have this term defined in our glossary, it is still unclear and ambiguous word for the developers. When does the deployment start and when does it end?

As an administrator, I want to eliminate all manual steps required to perform before users can start using SafeQ features on the MFD…

And we have come up with intent, which is clear from design… the purpose of the whole activity is to enable users access SafeQ features. By all means not ideal, but much better in expressing the purpose and avoiding design.

…so that i save time.

Difficult to understand, what saving time really means. Does it mean, that we need to save time when preparing the MFD, but at the cost of difficult troubleshooting later. Is saving time really the quality we are looking for?

Look at it from the perspective of the Administrator, who needs to prepare thousands of MFDs for thousands of users (a scenario which is quite common for our customers). Does he care about his time most? From the perspective of having to deploy one machine at a time, he does. But he also cares about the readiness of the devices. Would he prefer to tradeoff some of his time just to increase the reliability of the environment? Ask them, they tell you “by all means”.

We are looking into a complex quality here… time, reliability, failing fast. So our user story is not complete yet, but I will focus on this topic in my next post.


In Y Soft, there is a group of Clojure fans (including myself) that are fool enough to participate as contestants in Clojure cup and we are looking forward to see you there as well!closure-cup

Clojure cup is a world-wide competition where you develop a Clojure or ClojureScript application in 48 hours and then being judged by some of the big names from Clojure comunity, including Craig Andera, Reid Drapper, Michael Fogus and others. The competition starts on Sept 27th 0.00 am UTC, which means it will start at 2.00 am local time (Czech Republic). You must do all your work during 48 hours without any previous code prepared, however, you can use any publicly available libraries (including your own).

We are considering using Clojure stack on our next products and think this is a great opportunity to both, test the suitability of Clojure on real world application and deepen our knowledge of the language and platform in general. We already have a complete team of four people, but if you are looking for spaces where all your team could meet and stay near Brno, definitely get in touch with us on our twitter – @ysoftdevs and we could all meet at our beautiful HQ offices.

See you there and good luck to all of us. We are looking forward to see your great applications.

You made changes in your repository. You made the commit and at the very same moment you realize that it’s not completely correct.

You need to fix the last commit.

Git provides possibility to amend last change.

Type command for git gui interface:

git gui


Click radio button Amend Last Commit.


You can change the commit message or remove staged item by double click.


When you made all necessary changes click Commit.