Command, Control, and Innovate

  • 652 words
  • three minutes to read
  • comments

Command and control has worked effectively in military units across the world for thousands of years. But apparently we've just discovered that the best companies are built on different verbs, which are inspire, delegate, trust, lead, innovate, etc. The question is whether we really uncovered something new that our predecessors failed to understand for ages or something else is going on.

OOP Without Classes?

  • 148 words
  • a minute to read
  • comments

I interviewed David West, the author of the Object Thinking book, a few weeks ago, and he said that classes were not meant to be in object-oriented programming at all. He actually said that earlier; I just didn't understand him then. The more I've thought about this, the more it appears obvious that we indeed do not need classes.

Inheritance Is a Procedural Technique for Code Reuse

  • 603 words
  • three minutes to read
  • comments

We all know that inheritance is bad and that composition over inheritance is a good idea, but do we really understand why? In most all articles I've found addressing this subject, authors have said that inheritance may be harmful to your code, so it's better not to use it. This "better" part is what bothers me; does it mean that sometimes inheritance makes sense? I interviewed David West (the author of Object Thinking, my favorite book about OOP) a few weeks ago, and he said that inheritance should not exist in object-oriented programming at all (full video). Maybe Dr. West is right and we should totally forget extends keyword in Java, for example.

Gradients of Immutability

  • 509 words
  • two minutes to read
  • comments

Good objects are immutable, but not necessarily constants. I tried to explain it here, here, and here, but now it's time to make another attempt. Actually, the more I think about it, the more I realize that immutability is not black or white—there are a few more gradients; let's take a look.

Vertical vs. Horizontal Decomposition of Responsibility

  • 388 words
  • two minutes to read
  • comments

Objects responsible for too many things are a problem. Because their complexity is high, they are difficult to maintain and extend. Decomposition of responsibility is what we do in order to break these overly complex objects into smaller ones. I see two types of this refactoring operation: vertical and horizontal. And I believe the former is better than the latter.

Eight Levels of Communication Maturity

  • 571 words
  • three minutes to read
  • comments

Each software team organizes its communications in its own specific way. Some use Slack, Trello, or GitHub; others just sit together in the same room. There are many methods and tools. I believe it's possible to rank them by the amount of damage they cause to your project. This is the list of all of them I'm aware of at the moment.

What's Wrong With Object-Oriented Programming?

  • 761 words
  • three minutes to read
  • comments

Recently, I was trying to convince a few of my readers that a better understanding of an object in OOP would help us solve many problems in existing pseudo-object-oriented languages. Then, suddenly, the question came up: "What problems?" I was puzzled. I thought it was obvious that the vast majority of modern software written in modern OO languages is unmaintainable and simply a mess. So I Googled a bit, and this is what I found (in chronological order).

If-Then-Else Is a Code Smell

  • 336 words
  • two minutes to read
  • comments

In most cases (maybe even in all of them), if-then-else can and must be replaced by a decorator or simply another object. I've been planning to write about this for almost a year but only today found a real case in my own code that perfectly illustrates the problem. So it's time to demonstrate it and explain.

A Distributed Team Delivers Code of Higher Quality

  • 958 words
  • four minutes to read
  • comments

OK, the title is not exactly accurate. I've missed the "can" word. A distributed team can deliver code of much higher quality than a co-located one, and now I'll explain why. Of course, not every distributed team can do that. Most of them can't even deliver code that works, let alone quality code. But if a team—a distributed one—is managed according to the principles I'll explain now, the quality will be much higher than the same team can achieve if co-located. What I'm going to show you is that working in a remote mode, if done right, guarantees higher quality of code. Surprised?

8+2 Maturity Levels of Continuous Integration

  • 474 words
  • two minutes to read
  • comments

There are a number of levels you have to go through before your continuous integration pipeline becomes perfect. I found eight of them and presented my findings at DevOpsDays in Salt Lake City a few weeks ago (watch the video). Now it's time to write them down and ask you—Which level are you at? Post your answer below.