Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
+01 (414) 230 - 5550
Błażej Kosmowski, Technology

With Ruby on Rails as our primary backend technology, we have developed a set of practices for testing our applications. Our goal was to maximize the efficiency of writing tests that cover the most critical parts of the software built. Some means to that end are presented below.


We usually use TDD to keep decent test coverage and preserve an easy-to-follow, maintainable application design. Still it is not our goal to achieve maximum tests isolation, as we acknowledge the so called Test Induced Design Damage, where producing easily testable code can result in a more complex architecture than is in fact necessary. This is also why we do not stick to TDD 100% of our time — on occasion we decide to experiment with the code first to find the most readable, comprehensible and optimal solution. Then we either TDD it from scratch or cover the code resulting from such experimentation with the missing tests.


We tend to start our testing with high-level feature tests (the so called Outside-in testing approach). Following this practice we can jump start implementing a new feature very quickly and we always end up with a test that covers at least the most critical paths of a given feature. This is also the place where we focus on readability the most. Using rSpec and Capybara we endeavor to write tests in a way that would be easy to follow not only for other developers but also for non-technical people. When we need to put an even greater emphasis on test scenario readability for non-programmers, we resort to Cucumber as our tool of choice; for the price of a slightly higher cost of writing and maintaining the suite, we end up with acceptance documentation that can easily be followed by the quality assurance team. It is also worth mentioning that covering a big picture with feature tests while at the same time covering edge cases/specifics within lower level tests, we usually end up with a smaller overall amount of tests that handle the same amount of logic (we strive not to test the same thing multiple times).


Driving bug fixes with tests that reproduce bugs being fixed is an important routine in our testing practices. We thus ensure that a given error is handled in a sustainable way. We sometimes also re-evaluate the logic surrounding a detected bug to cover it with even more low level tests accounting for edge cases that were not foreseen before.


CI is the most important service when it comes to testing software in the long term. When our software grows, so does the test suite that takes longer and longer to execute. To stay efficient we delegate executing the whole suite to specialized services like TravisCI or CircleCI. All the tests need to pass on CI before one integrates a given feature with the application. We use the power of the CI service not only to run our tests, but also to ensure that our code style is consistent (by running linters like Rubocop or ESLint), code does not include simple security vulnerabilities (e.g. by using Brakeman) and its overall quality does not drop (i.e. by using Rubycritic). In this way it is not uncommon for us to deliver new features on a daily basis rather than in weekly (or other kind of) iterations.


If it is necessary we also add cross-service integration tests that verify the interfaces of the services we use in a given application. Thus we can react fast if a given service provider applies changes to their API or simply stops handling our requests. This is usually beneficial in applications where high availability is a critical factor.

Besides, if performance is crucial we can also provide load/stress testing scripts and analysis using such tools as JMeterloadtestsiegeNew Relic, etc. Due to the added cost of maintaining such tests, we add them only if the cost is justified by the benefits and only for the most critical parts of the system.


Frontend frameworks and libraries like ReactJSEmberJS etc. play a big role in web application development nowadays. It is usually much more efficient to cover the logic that resides in the frontend part of the application with dedicated javascripts tests than with much slower feature specs; such an approach is even more important when developing single page applications that are highly decoupled from backend code. We use a variety of tools that support us in maintaining proper tests coverage in this context, like qunitmochachaijest or enzyme.


Manual testing is an integral part of the feature delivery process. Before a given functionality is handed over to end users or the quality assurance team, we manually test it on staging and/or production environment. Verifying a solution against acceptance criteria significantly limits the number of rejections and makes the delivery process smoother and more efficient. This is usually accomplished by a person responsible for implementing a given feature, but on larger teams it may be handled by a dedicated team member or just another developer to simulate the end-user experience to a greater extent.


Writing software with an adequate amount of tests that are introduced at the right time allows us to deliver code that is not only reliable but also comprehensible. This is especially important when new developers join the team. Following the testing practices listed above also ensures that the velocity in which new features or changes are applied is not crippled with an accumulating Technical Debt. It also renders system-wide optimizations and refactorings possible without sacrificing overall application stability. If you would like to explore the related topic of keeping your application healthy, feel free to check out The four indicators of a healthy Ruby On Rails project.


Błażej Kosmowski, Technology



You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy — you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.” Martin Fowler

I doubt there are many coders out there who have not been asked by a customer at least once in their career about the necessity of refactoring or testing. They will also have encountered another question — “Can we do it later?”, where “later” in practice usually means “never”. It is not (that) hard to justify the necessity of test coverage to the customer, yet justification for refactoring seems to be less tangible, because — as the story goes — “if it works and is tested, why touch it?”. Typical arguments against refactoring are higher development cost and delays in delivery. What customers are often not aware of is not only that the arguments may not be true, but also that skipping refactoring may actually be incurring the so-called Technical Debt and thus laying the foundation for costs and delays further down the road. This debt will be paid sooner or later unless the project development stops. There are multiple high-level consequences of Technical Debt that keeps building up in the system, to name just a few:

  • new features delivered at a much slower pace

  • higher costs of new developers joining the project

  • inaccurate estimations resulting in missed deadlines

  • vendor lock-in where it becomes impossible to change the software vendor without a thorough system rewrite

The thing is that refactoring can be done with different purposes in mind and with different effects on technical debt. Some of the refactoring types can, in fact, be postponed or even ice-boxed without significant consequences, yet managing technical debt and mitigating its effects plays a big role in keeping our projects healthy. “Paying technical debt” should never appear in your backlog. If it happens it means that it was either a tolerated mess or it was not intended. Even if it was not conscious it should be named after identification.




When you decide to take on a technical debt, you had better make sure that your code stays squeaky clean. Keeping the system clean is the only way you will pay down that debt.” Uncle Bob

Refactoring for quality is the only type of refactoring that should not even be mentioned or considered as something that might be a subject for extraction into a separate task. This type of refactoring does not prevent technical debt inherently; it prevents something much worse — a mess. These refactoring procedures/activities include but are not limited to:

  • keeping code style consistent

  • following established best practices

  • keeping security in mind

  • keeping code testable

  • keeping code readable

  • conscious use of libraries and design patterns


Why should we not mention refactoring for quality as something special? Because it needs to be an integral part of our development process. The more complex the code is the more readable it should be and the more time should be spent on planning, research and refactoring. Not only is refactoring the last step in Red-Green-Refactor loop of the TDD cycle but it is also much easier to apply it immediately rather than to be picked up later. Here are a couple of reasons why it is so:

  • it is more efficient to refactor when one is in scope of the problem

  • if refactoring is not done, it may affect testability and architecture when code is integrated with by other developers

  • does not make developers procrastinate / defer the task forever

  • refactoring tasks are difficult to be handed over to other developers

  • refactoring early saves time spent on code-review and communication

The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying off in the future. A mess is always a loss.” Uncle Bob

Hence keeping quality high should not be a matter of making a decision. It should be a matter of just doing it. It adds some overhead when the project starts but pays off many times over when development progresses.





Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.” — Donald Knuth

This is the first type of refactoring that might be considered to be postponed. It might even not be considered to be refactoring because performance tuning sometimes happens at the cost of readability or code cleanliness or might even be regarded as counterproductive.

If the cost of making some performance optimization is low, it falls under the Refactoring for Quality category and should be addressed immediately. For instance, using database capabilities to search through a set of records instead doing it manually outside of database costs almost nothing in development effort while it may impact performance significantly.

In turn, when we identify some important performance problems, resolving those might involve some refactoring tasks (vs. scaling) that need to be scheduled and prioritized separately.




Building code in a decomposed way with consciously applied design patterns inherently leads to codebase that is reusable. Sometimes though preparing a given solution in a reusable way requires a significant time investment. This may collide with business goal of delivering the feature fast. Even though such code might knowingly be intended to be reused in the future, such code may be an introduction of conscious and justified technical debt that may be addressed later if necessary.




This is a similar situation to refactoring for reusability but it is performed on a larger scale. Extracting libraries, dividing monolithic applications into or augmenting them with micro-services, introducing architecture that relies on plugins will with all likelihood require some significant refactoring of the codebase, even well before the actual extraction happens. As the extraction itself is usually a task of its own, it is reasonable to treat correlated refactoring that renders extraction possible in the same way.




Refactoring for metrics is a type of refactoring that should be applied with caution. Depending on the project and technology there might be multiple metrics measuring a variety of aspects of our code. They are often useful and indicate, for instance, missing code coverage, unhealthy code due to issues with its complexity or size, etc. In most cases, such matters can be addressed immediately, but if the time investment needed is significant, such refactoring can be postponed as well.

Refactoring for metrics also has its dark side. Sometimes the only result of such refactoring is a degradation of code quality, i.e. the degradation associated with the decomposition introduced, unnecessary tests, etc. We should always remember that automated code analysis may not capture our intentions behind conscious design decisions. In such cases, we should not only restrain from refactoring such code but also add proper exceptions that will stop those false alarms from harassing us.




Refactoring legacy code almost always concerns refactoring to raise code quality and reusability. While sometimes considered to be fun, this is the most tedious chore. Sometimes we can treat a chunk of code as legacy even if it was just added to codebase — this applies for example to low-quality code that was not refactored in an ongoing fashion and piled up in pull request that nobody wants to approve. In such a scenario, one can notice that this is where we may lose the most time in comparison to refactoring on the spot. Something that might be written in n hours incorporating refactoring all along the way may take much longer when refactored later on in the process. Still, it needs to be done if compromising code quality is the only alternative.

Refactoring genuine legacy code is a different story — if we take over some existing codebase with questionable quality and outdated libraries, it is something that definitely needs to be managed and usually requires a lot of planning. Refactoring everything in one run or rewriting the whole codebase rarely is an option. Instead, an iterative approach coupled with a focus on the most problematic areas as well as balancing refactoring costs and benefits should guide us in the process. There is usually no quick and simple way here.




Sooner or later we will be forced to provide a hotfix, where delivering a solution apparently has a bigger value than refactoring. In many cases, hotfixes are small changes that will not need any refactoring after all, but sometimes the situation can be different.

It might be a good idea to have some protocol for such circumstances, e.g opening a Pull Request that is geared towards refactoring right after integrating the hotfix with the codebase. People tend to spot long-running Pull Request more easily than some low-priority chores in the project management software. Such Pull Requests — tagged properly — might be mentioned during daily stand-ups until the necessary refactoring is applied and merged. This is just an example of a solution and each team might address this problem in a different way.




Refactoring, when applied on time, can help keep our code healthy and easy to work with. It will also benefit the team velocity — the latter will not degrade due to the accumulation of technical debt. On the one hand, optimizing for speed or reusability, improving our metrics or just handling old legacy code might all be managed separately and intentionally postponed. On the other hand, beside some well-justified exceptions, refactoring aimed at keeping code quality high should be applied as part of a regular, ongoing development process and not treated as some special, optional step that needs to be handled after delivering the feature. After all: “Preventing technical debt is what allows development to be agile in the long run”. Dan Radigan, Senior Agile Evangelist, Atlassian



Błażej Kosmowski, Technology

Before starting development on a legacy project, we are often asked to do a quick review of its quality. Some projects are easy to analyze and the task just boils down to a look into a couple of classes, routes file, tests etc.; yet from time to time we realize that the actual problems might be harder to discover than we thought. There is also a situation in which we do not have access to the codebase before we sign an agreement and start to work on the project. In such a situation it may pay off to establish the key practices that the development team might have (or might not have) followed. Those practices can not only give us some quick and precise feedback on the project quality but they can also serve as a checklist for keeping our existing and new projects healthy.

The list below has been designed for projects based on the Ruby on Rails framework, but it can easily be adapted for other frameworks, languages and projects.




“Test Driven Development” features in almost all programming-related job postings, at least in the Ruby on Rails ecosystem. But do we actually do it? And to what extent? What is our coverage? How much does it cost to maintain a green test suite? Those are all valid questions if we intend to follow routines that keep our project in a healthy shape.

It is not impossible to write even medium-sized projects without specs at all or cover tiny projects with hundreds of tests with minimum value. One’s job is to find that sweet spot in which our tests bring a lot of value while not taking us many extra hours of work just to maintain the suite after each small change. Pure TDD is also something that can bring us problems in application/architecture design (the so called Test Induced Design Damage, that DHH has some great talk about), when our drive to make the code testable makes it less readable and less comprehensible.

It might be a good idea to consider the Outside-In Testing approach to keep our testing practices under control. In this case development is driven by high-level tests (i.e. feature specs) and then each lower-level concern or edge case is handled by more specific tests. Thus we do not end up testing the same thing multiple times and with some occasional experimentation before “TDDing” we can end up with a pretty decent architecture.

All in all, the most basic question is about tests presence. If there are no/few tests in the codebase it is a fairly reliable indication that you may have to face some significant / challenging problems.



Well, the actual question should be “Do you use design patterns to keep your code quality high?”. There is no use for design patterns where there is no place for them, so those should only be applied consciously. Times when “you should keep your controllers slim and models fat” are long gone now. Models (or in fact most classes) do deserve to be kept slim as well. It virtually boils down to keeping each class responsible for only one thing — the so called Single Responsibility Principle.

The decorators and service objects, mentioned in an old yet still valid post by @brynary about the slimming of models, became quite popular, but that is not all we can do to keep our classes testable while keeping their responsibility narrow. “Design Patterns in Ruby” (by Russ Olsen) is a great source for diving into more sophisticated solutions and extending our skills toolbox with some nifty techniques.

Leaving design patterns aside, it deserves to be mentioned, that keeping our controllers actions limited to the RESTful ones can also help in keeping those classes in good shape. DHH himself has some strong opinion about it, as it is outlined in this post by Jerome Dalbert. Also following Sandi Metz Rules for developers should do some good to the shape of our classes.

To sum up, the point is not to use as many design patterns as possible, the goal is to keep our classes slim, with narrow responsibilities and public interfaces. If a design pattern is a means to an end here, let’s use it! If we add a bit of refactoring here and there in the classes themselves to keep the method complexity low, we will end up with comprehensible, reusable and testable code at the cost of added indirection (which a decent coder can deal and live with). At least, this is the plan. On the other hand, if the project is of a moderate size and using few design patterns and/or class slimming techniques, we can expect some of the classes to be huge code dumps, which are not very comfortable to work with. This might not be true for projects with very simple logic and requirements, yet it is a warning sign we should be aware of.



Ok, so there we have this magic code — almost no code there and everything just works! Awesome! Well sort of. There are so many means to keep our code slim (do not mistake with slim classes) — gems, libraries, convention-over-configuration-everything! It looks nice at the beginning , yet later it turns out we need to customize something (especially something not foreseen by the library author), or somebody else is to work with our code. The “magic” now becomes a problem as it makes a given implementation harder to understand, requires diving into multiple libraries, crafting customized solutions to modify the default behavior. The code looks nice, but it is not easy to work with. The key is to decide if a given solution really gives us much benefit in terms of less code being written, or is it ok to just write a couple of lines and keep code comprehensible and easily modifiable. After all being explicit about a given behavior is advantageous in most cases.

In Ruby on Rails (or for that matter in Ruby itself) there is also this very tempting thing that drives “magic” to a new level. Metaprogramming. When you discover it, you just have to love it. This love dies quickly if it was not you who coded the piece. Dynamically creating methods or altering their behavior makes tracking what code does a living hell and renders stack traces useless. I may be exaggerating a bit, but it definitely can make things much more complex to understand.

There is one more place where we might pay even more attention as regards the trade-off between readability and being DRY (Don’t Repeat Yourself). Specs. One might find that keeping tests very DRY makes them much less readable; e.g. when we need to jump around a file to locate those “shared” things, aggregate them in our head, find what the subject is all about and then finally what is tested in those “shared examples” and “shared contexts” — the word “shared” becomes our foe. Keeping test prerequisites/setup, executing code being tested and asserting the result all in one place renders the test (more) comprehensible, yet it does so at the cost of repetition, the cost we are ready to pay for the benefit that comes with it. The benefit is even more valuable, when we need to alter/fix somebody else’s tests or the corresponding code that is tested.

So should we write everything from scratch and limit the use of libraries to the minimum? By no means! We just need to be aware of how a given solution affects the readability of our code. There are so many gems and libs that make the coding of some aspects of our application easier. Many of the them encapsulate useful logic and solutions that would otherwise force us to reinvent the wheel in our project. But some are just adding the “magic” — let’s be cautious here. Metaprogramming is not a bad thing either, but let’s make sure we use it where it is necessary and more beneficial than alternative approaches. Finally, let’s keep our tests in a good, readable shape. If somebody finds it hard to understand the code we have written, the tests will be the place in which they will seek for the answers first.



One thing that is really painful for a reviewer when analysing the code is the same comment being repeated all over again; another remark about wrong indentation, yet another comment on using a better method alias, and still one more mention about a method not covered with specs… The good news is, if we get tired of repeating same comments all over again, all sorts of automation tools come to the rescue. Those that might indicate a healthy rails project can be divided into three categories.

Code style standardization tools and services will take care of the basics: how the code is laid out, if the code style is consistent (i.e. houndrubocop), if best practices (i.e. Rails Best Practices) are applied when necessary or even if there are no obvious security holes (i.e. brakeman) in our implementation.

The second group is similar to the first in that it also depends on static analysis but it focuses more on such metrics as test coverage (i.e. simplecov) or the quality of code (i.e. rubycriticCodeClimateCodeBeatPullReview).

The last group of basic automation tools and services encompasses CI / CD (continuous integration / continuous delivery) solutions. Even the most comprehensive test suite is not worth a dime if nobody runs it. CI services help in executing and monitoring the current status of our tests suite. It can even stop our deployment if we go red. There are many players on the market, i.e. CircleCITravisCIJenkinsCodeShip, etc.

Can we live without those tools and keep our project in a good shape? We surely can! It will however require much more attention, more thorough code reviews and a good amount of discipline. Why just not make use of this great services and be liberated to focus on much more interesting stuff?




A project that is driven by Outside-In testing, uses various design patterns to keep classes slim and testable, balances the code DRYness and readability as well as takes advantage of automated code analysis is most likely a healthy well-crafted piece of software. Even without looking at the code, if you inquire the team about those aspects of the development process you can get a general understanding of project condition. As regards new projects, this list may help you establish a set of practices that will keep the project bullet-proof from the very beginning.


Błażej Kosmowski, Technology

We use them to perform a number of tasks like shopping and paying bills or communicating with other people. Computers undoubtedly make our lives easier and save a lot of time, but there is price to pay. Headaches, low back and neck pain, muscle strain and sore eyes are ailments commonly associated with sitting in front of a computer screen for a long time. Most of us have experienced these health issues to some extent, but people who are especially prone to suffering from them are those who use computers in their work on a daily basis. These include translators, accountants, office workers, and IT specialists. Fortunately, you are not doomed to pain and there are a few simple ways to avoid it.



After working for long hours most computer users complain of watery and bloodshot eyes, conjunctival redness, burning and tingling, headache, drowsiness, apathy. Most also give symptoms of blurred vision and the feeling of dry eyes.

The reason behind this discomfort is the fact that working in front of a computer forces your eyes to continuously focus and align to the changing images on the screen. Your eyes need to accommodate to what they see in order for the brain to interpret the images correctly. The task is much more demanding for your eye muscles and requires greater effort than, for example, reading a newspaper. The eyes have to move in a way they are not naturally intended. To make matters worse, a light source facing a computer screen causes a significant glare, which may contribute to the feeling of eye fatigue. Older monitors may additionally cause a noticeable flicker of images, which is not only irritating, but may also cause eyestrain. Other harmful factors are excessive or poor lighting in the room, incorrect posture during work, and an inappropriately arranged workstation. If you are worried about CVS, implement these simple changes in your work environment and follow the advice.



Use proper lighting.

Minimalize the glare and reflection on the screen by moving the monitor away from direct light source. The windows should be to the side of your monitor, and remember to avoid excessive overhead lighting. Instead, you should aim for a number of different sources of ambient light.


Rearrange your workstation

Your screen should be between 40 to 70 cm from your eyes. That is why CVS is more common among laptop users, as with laptops, the distance between the screen and our eyes is much smaller. In addition, the centre of the screen should be about 20 degrees below your eye level.


Remember to blink

A healthy person normally blinks about 18 times a minute, but it has been found that this number falls to as little as 4-5 times when we are working in front of a computer screen. Why is blinking so important? Its main job is to keep your eyes moist and dirt-free. Inadequate blink rate could lead to dryness and irritation. If you experience dry eyes, ask your doctor for artificial tears, and try to blink more often to rewet your eyes.


Upgrade your monitor display

Buy good quality large IPS display 19 inches or more. They have a sharper display, usually come with an anti-reflective surface and produce less harmful glare. Another thing you can do is to adjust the brightness of your screen so that it matches that of your work environment. Also, change the contrast between the background and characters on the screen if it is not high enough. If you wear glasses, remember to get anti-reflective (AR) coating applied to your lenses.


Take breaks and exercise your eyes

A good way to give your eyes a rest is to look away from the screen every 20 minutes and gaze at a distant object for about 20 seconds. This would relax the focusing muscles in your eyes and reduce the feeling of tiredness. You should also take more short breaks and walk away from the computer. According to a studyconducted by National Institute of Occupational Safety and Health (NIOSH), workers who take up to four 5-minute breaks throughout the day, reduced the feeling of eyestrain and fatigue.



If you spend long hours hunched towards a computer throughout the day, you are more likely to suffer from the so-called computer back syndrome. The term refers to posture and back problems, as well as sharp pain in the upper and lower back and neck. This is caused by prolonged and excessive stress placed on the muscles, nerves and joints. Generally speaking, even if you keep a good posture, your spine is under much greater pressure when sitting than standing or lying down. To make matters worse, people with desk jobs may find it difficult to keep the perfect posture for 8 hours or more. They have a tendency to twist around in their seat, cross their legs, change the position of their feet. All this may increase the feeling of tension and back’s overload to an even greater extend.



Get a comfortable chair.

One of the most important things you can do to minimize the pain in the back or neck is to have an ergonomic chair that promotes good posture. A good chair should share the burden of supporting your body load with your back, so that your body does not have to do all the work. One of the most important features to look for in a chair is lumbar support, as this is where most back issues usually start. It supports the natural low back curve in your spine, thus minimalizing the strain and discomfort. Make sure the lumbar support is adjustable for height and depth. As far the backrest is concerned, it should be between 30 – 50 cm (12 – 19 inches) wide, must support the natural curve of the spine and be adjustable. If the backrest is not part of the chair completely from the seat, you should be able to adjust it in height and angle. If it is not separate from the chair, it should be adjustable in forward and back angles. An ergonomic chair should have enough width and depth so that the user can sit comfortably. This usually means there should be about 5 – 10 cm (2 – 4 inches) between the back of your knees and the seat.

Another thing to bear in mind when choosing an office chair is that it needs to have a height adjustable seat. You should be able to sit back comfortably with both of your feet flat on the ground. Sitting in a chair that is too high or too short can further increase the back and neck problems you are experiencing. Remember, there are no one-size-fits-all solutions. The last thing to take into account is the material on your office chair seat. Opt for cloth fabric that breathes rather than hard surfaces. Leather may not be the best option, especially in offices with no air conditioning, as it does not breathe and may feel hot over time.


Customize your office space.

Office chair is not the only thing that needs to be adjustable to your height and preferences. Placing your keyboard and mouse is also important. You should not have to bend your forearms more than 20 degrees to reach them (or 45 degrees if you prefer standing instead of sitting). It is also not good if you need to extend your arms forward in order to type. Remember to keep all the items you need in your work (e.g. a phone, books, a document holder, etc.) within your reach. Thus, you will avoid stretching out to get them when necessary.



Take short breaks to stretch out the muscles, stand and walk. It will help you to keep the muscles and joints loose and promote the blood flow. Even a short walk to the water cooler or bathroom can help you avoid the pain and relax.

Sitting up straight is good for you, but try to avoid staying in one position all day long. You should be able to regularly change your posture to eliminate tension in the muscles. Tile the backrest of the chair in order to sit reclined or declined when necessary. If you have an adjustable desk, you may find standing in front of the screen a better option for you. However, you should not overdo it, as it may make your legs feel sore at the end of the day.



It would seem that the main cause of pain around the elbow is playing tennis. This is not always true. Often the pain is caused by working for long hours in improper position and when the height of the tabletop is not adjusted properly. It causes the feeling of overload in the forearm tendons, especially if you perform monotonous work such as prolonged typing. With tennis elbow, the muscles and tendons in the elbow get damaged, because they are kept in the same position for a long period of time. This may be caused by keyboard and mouse not placed at a proper height.



First of all, remember to assume the correct position when working. Sit up straight without bending or extending your forearms forward too much. Consider buying a special vertical mouse and an ergonomic keyboard with a V-shaped design with which you will be able to type at a slight angle with your wrists in a more natural position. The vertical mouse is also much more ergonomic than a regular one and can help you avoid further muscle strain. A good way to prevent the condition is to do a little stretching before overusing the elbow muscles. Remember to take breaks to allow your arm to dangle at your side. This will help relax the muscles and joints and release the tension.



Headaches and fatigue

Frequent and recurrent headaches are a common complaint among people with sedentary lifestyle, including heavy computer users. Usually, there are several reasons behind it: working under a lot of stress trying to meet the deadline, long working hours, poor work environment, too dim or too bright lighting. If you happen to suffer from frequent headaches, there are a couple of thing you can do to curb headache triggers or to avoid the headache altogether.

As it was mentioned before, a common headache trigger is your workstation, if it is not arranged properly. You may be more prone to headaches if you work in a very bright environment and already suffer from eyestrain. As with the case of computer vision syndrome, a good way to get rid of the headaches is to take frequent breaks and spend the time doing activities that do not require you to focus on a screen. You might also want to switch the overhead light off when working at a computer and adjust the contrast settings on the monitor.

Another factor that might trigger headaches is improper posture. If you constantly lean towards the monitor, you are not only more likely to develop a chronic pain in the back, but also get a headache. Do not sit in one position all day, but always keep your back and shoulders straight. Adjust the chair, desk and monitor to your preferences, and again: take breaks to stretch out your muscles and relax.

Other things you need to take into account when trying to fight off headaches and fatigue is your diet. Limit your caffeine intake, because coffee acts as diuretic and dehydrates you. Drink plenty of water instead. Working long hours and irregular meal times often come together. Unfortunately, if you skip meals and let yourself get hungry, you are more likely to get a headache at the end of the day. Remember to ventilate your office regularly and, if possible, go outside during your break or after work to make sure you get enough fresh air.

Do not forget about proper sleep hygiene. The relationship between sleep and headache is inseparable and has been known for years. If you deprive yourself of sleep, you are more likely to suffer from headache and fatigue the next day. This, in turn, will most probably affect your performance at work. Try to develop good sleeping habits and keep a regular sleep schedule. If possible, take a short nap in the early afternoon to regenerate and recharge, but do not overdo it.

A common headache and fatigue trigger not to be taken lightly is stress. Working under tight deadline can be daunting, but you have to try to minimize stress, for example, by scheduling tasks or establishing a better communication with management, clients and co-worker. Remember that regular physical activity is thought to be a major stress reliever.


Overweight and hypertension

The link between sedentary behaviours and overweight has been known for a long time. Since IT specialists tend to spend hours sitting in front of a computer screen, it should come as no surprise that they are at a great risk of developing overweight or even obesity. There are several reasons to it. One obvious factor is inactivity of sitting, as a result of which your organism burns fewer calories. In addition, people with sedentary jobs are likely to munch on sweetened and salty snacks, eat irregularly and choose junk food over healthy diet, which does not help to prevent overweight. What is more, the researchers from Tel Aviv University discovered that placing your backside under mechanical pressure, such as sitting down for prolonged periods, actually makes the cells in your stomach turn into fat cells much faster. To make matters worse, larger weight is often associated with higher blood pressure levels.


Fortunately, there are a few steps you can take to reduce the risk of overweight and hypertension.

  • Start with your diet: make healthy food choices and watch the portion sizes. Avoid fast food and processed food, and if you must snack, opt for fresh and dried fruit or nuts, instead of sweets. Eat regularly and make sure you do not skip meals.

  • Cut down on coffee you drink throughout the day, as caffeine may raise your blood pressure. For the same reason you should also quit smoking and limit your alcohol intake.

  • If limiting your working hours is not an option, try to adopt a more active lifestyle after work: take regular exercise, go to a gym, start jogging, etc. If the weather conditions allow, leave your car in a garage and walk or cycle to work.

  • Sit as little as possible. You can try working at a standing desk or just stand up as often as possible during breaks or at meetings. If you have a tolerant and progressive boss, ask them for a treadmill desk, which is taking the standing desk to a new level!

Between coding, developing new software and applications, IT professionals spend significant amounts of time working in front of a computer screen and putting their health and well-being at risk. Whether it is stress, eye muscle strain, pain in the back or headache, when unattended to, these issues may have serious health consequences and lower the productivity and performance of the workers. That is why, it is in best interest of both the workers and employers to address these problems as soon as they start to occur, or better: prevent them from happening in the first place. Fortunately, with a few changes in the attitude and working environment, most of the health problems can be easily avoided or reduced to large extent.


Błażej Kosmowski, Business, Dariusz Wylon, Grzegorz Rduch, Michał Czyż

Selleo’s MMS – a 360-degree feedback system with monetary rewards

We have so far presented 3 elements of the Selleo’s feedback system in the series; the previous articles described the following components:

  • RevYou – an online service where developers exchange feedback geared towards technical skills development and knowledge sharing, and
  • client satisfaction surveys, which provide service delivery teams with the clients’ feedback on the quality of products built as well as the level of service delivered,

This blog post is focused on MMS (Merit Money System) – a system which enables each and every Selleo team member to reward their co-workers with kudos (reward points which convert to bonuses) as a token of appreciation for their colleagues’ efforts, performance, demeanor and other aspects they deem worth rewarding.

In many companies and organizations it is the managers who act as the primary – if not the only – feedback givers; even more often, those managers are also the only agents who evaluate and reward the work of the employees who report to them. We believe there are better ways to manage feedback, evaluation and reward. MMS is an attempt to create an alternative to the more traditional approaches.

Each Selleo co-worker has a pool of 20 kudos (reward points), which they are free to share with their co-workers every week. The few co-workers who are involved in interactions with a number of colleagues have as many as 40 kudos to share. Importantly, each and every co-worker is free to decide who will be rewarded as well as what they grant their kudos for, be it successful sale, smooth collaboration on a project, good demo, assistance, guidance, blog article publication, hiring or training a new colleague, helping with acquiring foreign language skills, event organization, someone’s personal merits, a colleague’s wedding, etc. – to cite just a few comments from the system.

The system is administered via a web service and is based on limited visibility: all the co-workers can see the top three collectors – the colleagues who received the biggest number of kudos – during the previous week, as well as the so-called “hamsters” – those who were particularly reluctant to share their kudos with others.

Besides, everyone can also see the kudos they have received along with the comments attached to them. Everyone can also review all the other submitted comments and thus find out what sort of attitudes, actions or behaviours are rewarded; the co-workers cannot see who such comments were submitted by, nor can they identify the recipient.

Apart from being good fun, this solution is also believed to be a means to an end, rather than an end in itself. The number of kudos a given co-worker collects, has a significant impact on the bonus they receive; the other – less significant factor – being the co-worker’s seniority. Generally speaking, the more appreciation you receive from your colleagues in the form of kudos, the bigger the bonus that eventually lands in your pocket. The system is administered via a simple web application, and was inspired by Jurgen Appelo and his concept of Merit Money. You can find out more about it in his recently published book: “Management 3.0. Workout. Games, Tools & Practices to Engage People, Improve Work, and Delight Clients.”You may review the Merit Money concept itself here.

Towards a more holistic approach – the merits of MMS

It seems that the MMS offers two main advantages from our perspective. Firstly, the conventional evaluation and reward systems administered by managers often encourage competitiveness rather than cooperation. With MMS it is the other way round. The people are often rewarded for collaboration as well as building and maintaining good working relationships with their colleagues. They are thus incentivised to support and help one another rather than compete against one another.

Secondly, if 80% of people perceive their performance to be better than average, chances are high that a large number of employees might feel frustrated that their efforts are undervalued or not rewarded properly; the risk seems much bigger with conventional solutions, where it is usually only the managers / superiors who assess those who report to them and decide on the rewards.

With MMS it is impossible to completely rule out the feeling of disappointment on the part of some co-workers, but the fact that it is a far more holistic solution makes the disappointment less likely to occur. One may in fact feel treated more objectively and/or fairly if the assessment comes from all those they work with rather than just a single individual.

What is more, as MMS is a continuous assessment and reward mechanism, the risk that somebody’s contributions will be disregarded, is also less likely.


Why so much hassle for feedback?

Each and every co-worker is free to gather, analyse and assess the information flowing to them from their daily encounters and interactions, team reviews and regular company updates, 360-degree feedback sessions, technical reviews and comments in RevYou, client questionnaires and other sources. They can then judge the impact their colleagues exert on them, their team and/or the company and choose to reward their co-workers’ contributions accordingly. In doing so they shape their own working environment themselves and – most probably – the future of the company.

Still, most importantly, you are provided with a lot of valuable feedback which enables you to better understand yourself, your weaknesses and strengths as well as the impact of your attitudes, actions and demeanor on other people. With such input at hand you are free to embark on an intriguing quest for self-awareness, professional growth and personal development. And who knows, you may become a better professional, colleague, friend, or simply, a better human being.


Błażej Kosmowski, Business, Grzegorz Rduch, Michał Czyż

RevYou – an environment in which to polish development skills and build quality products


In the previous article of the series we described the 360-degree feedback sessions that Selleo uses to foster their team spirit, increase collaboration and inspire individual co-workers to learn and grow both professionally and personally. This article is focused on a feedback mechanism which is meant to support developers in their efforts to master technical skills with which to create quality solutions.



RevYou is an internal online service aimed at improving technical development skills and thus increasing the quality of products built. Its core mechanism is based on technical peer feedback. 

RevYou is a software tool for codebase peer reviews that works in a way similar to the Github comments feature, which enables the users to provide feedback on the code submitted by their peers – they can just review the deliverables or they can choose to comment on them as well. What makes the RevYou solution different from Github, however, is the fact that it helps to ensure the reviews are actually conducted. Accordingly, unlike with Github, submitting reviews is not optional. It is only comments that are provided at the feedback giver’s discretion.



RevYou keeps each new commit on a “to review list” until the whole commit has been thoroughly reviewed and/or commented on by at least one developer. Interestingly enough, RevYou “recognizes” that not every developer is an expert in all the domains of the technology stack used by the company. It is therefore possible for a given user to provide a partial review of a given commit, leaving other parts to be reviewed by the developers with more relevant expertise. Another interesting feature of RevYou is that it encourages users to jointly review commits from multiple projects. By contrast, at Github, it is quite common for developers to limit themselves to reviewing the commits meant for just one and the same project – the one they are working on themselves.


What advantages does RevYou offer to developers and their clients?


The benefits of using RevYou are multifold. The reviewer can learn about other technologies and solutions by investigating other programmers’ code, which is especially beneficial for cross-project knowledge transfers. What is more, when a developer submits a comment on a code contribution, they have an opportunity to spread some best practices and/or good techniques across their team or even across the whole company, which proves particularly useful when training junior programmers. Another advantage is betterquality assurance (QA). If the codebase is thoroughly reviewed, poor solutions and malfunctions are more likely to be weeded out during the implementation process and the code quality on a given project is significantly enhanced. On top of that, since the codebase becomes more standardised, the code is easier to understand and maintain for other developers who may need to work on the same project in the future.


Błażej Kosmowski, Business, Dariusz Wylon, Grzegorz Rduch, Michał Czyż

Satisfaction surveys – feedback for better product and service quality


We all have been clients on multiple occasions and are – on the whole – fairly good at recognizing and appreciating good products and solid customer service. Still it is by no means easy to put oneself in the client’s shoes, thoroughly understand them and their specific needs as well as to use the understanding to build and deliver solutions that go beyond the client’s expectations. No matter how hard the challenge may be, meeting it is a very rewarding experience indeed.


You do not need to guess blindly what actually makes your client satisfied; you can engage them and lead them to provide you with insights on what supreme product and service actually mean to them. Systematically gathering, analysing and acting upon your clients’ feedback may very well enable you to better understand your customers’ concerns and expectations and ultimately help you deliver a product and service which is likely to delight rather than just be accepted by those you serve. Importantly – in doing so – you and your team are very likely to grow professionally and get better equipped to both attract and satisfy more customers in the future.


Client feedback sources

At Selleo, as in many other companies using Scrum, we collect and process feedback which emerges on a continuous basis from Scrum events held together with the clients’ product owners as well as from other encounters with the clients’ stakeholders. On top of that, however, we regularly conduct client satisfaction surveyswhich help specific individuals and/or teams to identify their own strengths and weaknesses as well as opportunities for improvement as seen by the specific client stakeholders they deliver service to.

The observations made by clients from without the organization together with the conclusions they draw from their interactions with the team can provide invaluable input with which to design and develop better software products but also with which to create memorable customer experiences in the process of service delivery.


The survey – inspirations and adaptations

The client satisfaction survey designed and implemented in Selleo is based on the questionnaires devised and advocated by David H. Maister, the author of “Managing The Professional Service Firm” and “The Trusted Advisor”.


The author’s survey meant to elicit customer feedback was modified to better suit the business context we operate in; the modifications introduced help to capture the specific character of the service delivered by a software development house which is in principle preoccupied with designing and building custom software solutions (products!) together with the clients who commission the service. Accordingly, the survey is divided into two parts: one focused on the assessment of the quality of the product delivered (what) and the other which concentrates on the quality of the process of service delivery (how).


Product quality part aims to establish if and to what extent the client is satisfied with the technical characteristics of the solution crafted, such as its reliability, responsiveness, user-friendliness, the quality of visual design and the like. The first part is sometimes modified to reflect the specific requirements of a given client engagement / project.

As regards the service quality part of the survey, the criteria/questions have been grouped into a few categories, each centred on a different aspect of service delivery: the team’s overall attitude, accessibility and timing, process and communications, relationship management, contributions and the client’s overall impression.

* Overall attitude.The client can review and assess the team in terms of how accurate and careful they are in their approach to work. While filling in the survey, they can also indicate whether the team members are proactive and anticipate potential problems and issues as well as if they offer creative solutions.

* Time. In this section of the survey, the clients assess whether the team members are easily accessible time-wise. Other crucial factors include the team’s ability to work on deadline and ensure fast development at the client’s request.

* Process and communications. Clients are asked to provide feedback on how effective the communication with the team members is. The factors that usually inhibit mutual understanding and efficient collaboration include technical jargon, poor documentation of the work done, insufficient and/or untimely explanations regarding the solutions implemented and actions planned. Thus clients evaluate if the team members can listen actively, keep the client updated on what is going on in their project and if the team are willing to deal with problems openly and quickly. The survey helps to make sure the process runs smoothly, the team communicate effectively and – importantly – the client feels they are involved, on track and in control.


* Relationship. Good relationships with customers and, more specifically, with the people working at the client end, are the foundation of productive and long-lived cooperation. What is more, satisfying relationships are often a key factor behind recurrent projects and referrals, i.e., the business development practices the company strives for and greatly appreciates. In this section of the survey, clients can evaluate if the team members make them feel they and their needs are important to the team, if the team are easy to collaborate with and if they are proactive in offering support and helpful advice.

* Contributions. It seems that one of the key factors in delivering unique customer experience may very well be the ability of the service provider to go beyond their narrowly defined value proposition. Thus it is a good idea to use the survey to find out if the client served feel that the team go beyond technological and implementation issues and if they understand the client business and the broader business context within which the client and their solution operate. It makes perfect sense to make sure the team are able to make valuable product contributions and are helpful in diagnosing the causes of the client’s problems, identifying the opportunities their clients face and redefining the client’s view of their situation. Some clients may surely not expect it, yet they are truly impressed when you are able to offer the kind of insights and contributions. Why not ask your client if you actually do so?


Gathering and processing the client feedback

The survey is administered online. The client needs about 10 minutes to evaluate the service delivery team against 35 performance criteria. Still some clients choose to elaborate on their assessment by providing more extensive and insightful feedback in the comments sections of the questionnaire. If the team wish so, they may also discuss the results and/or clarify specific points directly with the feedback giver during a joint review session. Having received their clients’ survey results the teams usually identify the areas where they exhibit the greatest weaknesses and undertake to work on one or two issues before they move on to tackle the the other opportunities for improvement.

The feedback provided by the client enables the team members to put themselves in their client’s shoes and better understand the experience the latter are going through. As a result, the team get a much better position to deliver the service which meets or even surpasses the client expectations. Last but not least, the insights thus received may provide directions to both the team as a whole and to the individual team members on how to become more professional in their approach.

Post Scriptum

If you are working with a software development service provider and would like to use the survey with them, feel free to contact me (g.rduch “at” – I am more than willing to share it.


Błażej Kosmowski, Business, Dariusz Wylon, Grzegorz Rduch, Michał Czyż

Feedback – a quest for self-awareness, professional growth and personal development.

Feedback is a double-edged sword. You may have received useless feedback which raised frustration or even anger and thus had no positive impact on the people involved. Still feedback can become a crucial and valuable element of both workplace communication and private life, transforming people, the relationships they build as well as the social environments within which they live and grow.

Properly provided and received, feedback enables you to find out more about yourself and your actions; in particular, you gain insights into how the other people you interact with perceive you and your behaviour. As such feedback may help you more objectively identify your weaknesses and strengths as well as the areas of potential growth and development.

Acting on the conviction stated above, the Selleo team have been experimenting with feedback extensively and – in doing so – have developed a constructive feedback system which supports the co-workers – as individuals as well as members of teams and a community of work – in their attempts to understand themselves and each other better as well as to facilitate their professional and personal growth. The Selleo feedback system consists of a few apparently connected elements:

  • 360-degree feedback sessions, where each individual is free to exchange feedback with their work circle, i.e., all the co-workers the person interacts with,
  • RevYou – an online service which helps to ensure that the code a developer submits is thoroughly reviewed by their colleagues;
  • client satisfaction surveys, which enable those who serve a specific client to elicit the client’s assessment of the quality of solutions implemented as well as the level of service delivered, and finally,
  • MMS (Merit Money System) – a system which enables each and every Selleo team member to reward their co-workers with kudos (reward points which convert to bonuses) as a token of appreciation for their colleagues’ efforts, performance, demeanor and other aspects they deem worth rewarding.

The following text is the first article in a series which aims to describe the different components of the Selleo feedback system in greater detail.

360-degree feedback sessions

One of the elements of the feedback system in Selleo is a periodically organized 360-degree feedback session. We were inspired to experiment with the practice by Jurgen Appelo and his Management 3.0book. To cut a long story short, each co-worker – whatever their position or area of responsibility – is invited to take part in a gathering during which the participants are free to give and receive feedback to and from each other. Participation in the session is not obligatory and you are free to refrain from either providing feedback for a specific individual or receiving feedback from them. Despite the voluntary basis, about 60-70% of the people choose to take part in the event, and the fraction of those who choose to attend has been growing steadily. The feedback exchanged is usually focused on performance, behaviour, communications and attitudes.

Rules for giving and receiving feedback

Providing and receiving feedback in a constructive way can be quite a challenge and a daunting task indeed. Some people initially struggle because they simply do not know how to give another person feedback or receive feedback from them; few people have been trained or offered an opportunity to practise the skill before. Thus we chose to introduce a couple of rules which make the whole process easier for the participants to handle. We have opted for and advocate the following set of rules for giving feedback:

1. Give feedback only when the recipient is ready to take it.

2. Always maintain eye contact with the recipient. Admittedly, looking somebody in the eye may feel hard, especially if you are about to criticise their behaviour. However, people who maintain eye contact are generally considered more confident, honest, and reliable. They seem interested in the interlocutor, who in turn are more likely to accept the message.

3. Be specific. Your recipient must know exactly what you think they did well/wrong – focus on some specific behaviour that caught your attention, rather than a generic evaluation of a person. The former is more descriptive and based on your observations, while the latter seems more judgmental, accusatory, and refers to your interpretations, which may be flawed. Try to avoid statements starting with “You…”, and replace them with “I-messages” instead.

4. Provide both negative and/or positive feedback as need but use feedback sandwich with caution. Feedback sandwich is a technique used mainly with negative feedback, when you want to highlight delicately the mistake of a feedback recipient. To achieve this, you sandwich criticism between two pieces of praise. The idea behind this method is to make the negative feedback more palatable to the recipient. If you use positive feedback to balance a negative message, it may diminish the value of your praise and the feedback recipient might feel it is not genuine.

5. Focus on the feelings the behaviour evokes in YOU. When giving feedback, use “I-messages” to express how a person’s behaviour affects you and your work, trying to be as specific as possible. If you concentrate on your own feelings, the recipient does not feel attacked and is less likely to get defensive. On the contrary, it creates more favourable conditions for self-reflection and awareness that might lead to future improvement.

6. State clearly what your expectations are. Specify what kind of behaviour you expect and suggest a few alternatives on how to change things for the better. Explain how the expected change in behaviour will affect you and your work.

7. Be realistic and do not expect the impossible.


Guidelines for receiving feedback.

It is a good idea to remember that as a participant you aim to become aware of how you and your work is perceived by others and to gain some insights on possible improvements. The following rules may help you benefit from the feedback you get.

1. Taking part in a 360-degree feedback session is voluntary. Besides, you do not have to accept feedback from a given individual without giving a reason for your decision.

2. Do not interrupt the feedback giver, while they are reviewing your behaviour. A lot of people will feel the need to discuss the comments, try to justify their actions or even deny what they hear. Don’t do it, just listen. The point is to understand the other person’s perspective. Naturally, you are allowed to ask for clarification if anything remains unclear.

3. Use the feedback received to reflect on your performance, behaviour or attitude in question. Think through any constructive feedback or suggestion you may hear and remember that negative information can be useful and you are free to use it to your own advantage. You may share your reflections with the feedback giver and tell them what you are planning to do with the feedback, but it is not a must.

4. You are the only person to decide to what extent you are going to take the feedback into account, which – if any – changes you are going to implement and what you are going to do with the information you received.

The advantages of 360-degree feedback sessions.

One of the unquestionable benefits of such 360-degree feedback is that the recipient is provided with feedback from a wide range of people working with them, and not just the managers or business owners. The approach allows one to understand and combine varied perspectives and arrive at a holographic picture of oneself and one’s contributions to the company. The feedback recipient can also gain a better understanding of how their behaviour and specific actions affect the work of other people in their team or, more broadly, in the working community. The received feedback is richer and more meaningful, and is thus more likely to lead to long-lasting effects, e.g., behavioral changes and improvements. Unlike traditional feedback approaches, 360 feedback sessions seem to encourage teamwork, foster better working relationships and increase the awareness of mutual dependency.

It is worth noting that the group sessions do not eliminate the need for one-on-one feedbackencounters. Some people in the company still choose to sort things out in private and the experiences from the group sessions simply help them conduct their exchanges more smoothly.

Thanks to the feedback sessions and encounters, the Selleo co-workers are provided with an opportunity to reflect upon their strengths and weaknesses as well as the impact they have on their colleagues, their team and the company.

They are often lead to identify opportunities to improve and grow both professionally and personally. Admittedly, this may not be a perfect working environment for everybody, but if you are eager to develop your professional and social competencies in dynamic interaction with your colleagues, then perhaps you might like to meet the challenge.