Continuous Integration is Dead

  • 934 words
  • four minutes to read
  • comments

A few days ago, my article "Why Continuous Integration Doesn't Work" was published at Almost the same day I received a few strongly negative critiques on Twitter.

Here is my response to the un-asked question:

Why the hell shouldn't continuous integration work, being such a brilliant and popular idea?

Even though I have some experience in this area, I won't use it as an argument. I'll try to rely only on logic instead.

Stop Chatting, Start Coding

  • 510 words
  • two minutes to read
  • comments

The first principle of eXtremely Distributed Software Development (XDSD) states that "everyone gets paid for verified deliverables." This literally means that, in order to get paid, every programmer has to write the code, commit it to the repository, pass a code review and make sure the code is merged into the destination branch. Only then, is his result appreciated and paid for.

For most of my clients this already sounds extreme. They are used to a traditional scheme of paying per hour or per month. They immediately realize the benefits of XDSD, though, because for them this approach means that project funds are not wasted on activities that don't produce results.

But that's not all.

Project Lifecycle in

  • 1341 words
  • five minutes to read
  • comments

In addition to being a hands-on programmer, I'm also co-founder and CTO of, a custom software development company. I play the role of a technical and management leader in all projects we work with.


I wrote this article for those who're interested in hiring me and/or my team. This article will demonstrate what happens from day one until the end of the project, when you choose to work with us.

You will see below that our methods of software development seriously differ from what many other teams are using. I personally pay a lot of attention to quality of code and quality of the internal processes that connect our team.

Best Hosted Continuous Integration Services for a Private Repository

  • 1221 words
  • five minutes to read
  • comments

Every project I'm working with starts with a setup of continuous integration pipeline. I'm a big fan of cloud services, that's why I was always using Travis. A few of my clients questioned this choice recently, mostly because of the price. So I decided to make a brief analysis of the market.

I configured Rultor, an open source project, in every CI service I managed to find. All of them are free for open source projects. All of them are hosted and do not require any server installation Here they are, in order of my personal preference (first four are the best and highly recommended):

Minimum price
Pull requests4
Log compress5
Shippablefree (!)

Dependency Injection Containers are Code Polluters

  • 687 words
  • three minutes to read
  • comments

While dependency injection (aka, "DI") is a natural technique of composing objects in OOP (known long before the term was introduced by Martin Fowler), Spring IoC, Google Guice, Java EE6 CDI, Dagger and other DI frameworks turn it into an anti-pattern.

Why Monetary Awards Don't Work?

  • 840 words
  • four minutes to read
  • comments

Monetary rewards for employees. Do they work? Should we use them? Can money motivate creative minds? Will a programmer work better if he gets paid only when he reaches his goals and objectives?

Much research has already been done on this subject, and most of it proves that connecting results with money is a very demotivating approach. For example, Ian Larkin says that the most productive workers "suffered a 6-8% decrease in productivity after the award was instituted."

I believe this is completely true. Money may become a terrible de-motivator for all modern employees (not just programmers).

My question is—why is this so?

Built-in Fake Objects

  • 556 words
  • three minutes to read
  • comments

While mock objects are perfect instruments for unit testing, mocking through mock frameworks may turn your unit tests into an unmaintainable mess. Thanks to them we often hear that "mocking is bad" and "mocking is evil."

The root cause of this complexity is that our objects are too big. They have many methods and these methods return other objects, which also have methods. When we pass a mock version of such an object as a parameter, we should make sure that all of its methods return valid objects.

This leads to inevitable complexity, which turns unit tests to waste almost impossible to maintain.

Remote Programming in

  • 225 words
  • a minute to read
  • comments

Here is an interview taken by Lisette Sutherland from, a few hours ago, which I enjoyed to give :)

Getters/Setters. Evil. Period.

  • 1178 words
  • five minutes to read
  • comments

There is an old debate, started in 2003 by Allen Holub in this Why getter and setter methods are evil famous article, about whether getters/setters is an anti-pattern and should be avoided or if it is something we inevitably need in object-oriented programming. I'll try to add my two cents to this discussion.

The gist of the following text is this: getters and setters is a terrible practice and those who use it can't be excused. Again, to avoid any misunderstanding, I'm not saying that get/set should be avoided when possible. No. I'm saying that you should never have them near your code.

Deploying to Heroku, in One Click

  • 359 words
  • two minutes to read
  • comments

There were a few articles already about our usage of Rultor for automating continuous delivery cycles of Java and Ruby projects, including RubyGems, CloudBees and Maven Central.

This one describes how Heroku deployment can be automated. When I need to deploy a new version of an Aintshy web application, all I do is create one message in a GitHub ticket. I just say @rultor release 0.1.4 and version 0.1.4 gets deployed to Heroku. See GitHub ticket #5.

You can do the same, with the help of, a free hosted DevOps assistant.