Are You a Hacker or a Designer?

  • 1025 words
  • four minutes to read
  • comments

Twenty years ago, the best programmer was the one capable of fitting an entire application into a 64Kb .COM file. Those who were able to get the most out of that poor Intel 80386 were the icons of programming.

That's because twenty years ago computers were expensive and programmers were cheap. That was the time of the "hacker mentality". That time is over. That mentality is not appreciated any more, because the market situation is completely opposite.

Today, computers are cheap and programmers are expensive. This is the era of the "designer mentality", when the readability of our code is much more important than its performance.

Paired Brackets

  • 240 words
  • a minute to read
  • comments

Here is a notation rule I'm using in Java code: a bracket should either start/end a line or be paired on the same line.

The notation applies universally to any programming language (incl. Java, Ruby, Python, C++, PHP, etc.) where brackets are used for method/function calls.

Here is how your code will look, if you follow this "Paired Brackets" notation:

new Foo( // ends the line
  Math.max(10, 40), // open/close at the same line
    "hello, %s",
    new Name(
  ) // starts the line

Incremental Billing

  • 830 words
  • four minutes to read
  • comments

When you hire a software developer (individual or a team), there are basically two types of contracts: fixed price or time-and-material. They are fundamentally different but the truth is that in either case—you lose.


In the eXtremely Distributed Software Development (XDSD) methodology everything is different, including the way we invoice our clients. Let's see what happens in traditional contracts and what changes in XDSD, which we practice in

How We Write a Product Vision

  • 1271 words
  • five minutes to read
  • comments

Every software project we work with is started from a Product Vision document. We create it during our Thinking phase. Even though the document is as short as two pages of English text, its development is the most painstaking task in the whole project.

There are a few tricks and recommendations which I'd like to share.

We usually design a Product Vision in four sections: product statement, stakeholders and needs, features, and quality requirements.

What Does a Software Architect Do?

  • 671 words
  • three minutes to read
  • comments

Do you have a software architect in your project? Do you need one?

Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a "software architect" badge on someone's t-shirt, the most reputable programmer gets it.

The badge rarely changes his responsibilities, though. After all, the team stays the same and enjoys having technical discussions together, involving everyone. In the end, a software architect is more of a status than a role with explicitly defined responsibilities. It is a sign of respect, paid by other team players to the oldest and the most authoritative one among them. Right?

Absolutely wrong!

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

  • 1240 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.