Seven Virtues of a Good Object

  • 2694 words
  • 10 minutes to read
  • comments

Martin Fowler says:

A library is essentially a set of functions that you can call, these days usually organized into classes.

Functions organized into classes? With all due respect, this is wrong. And it is a very common misconception of a class in object-oriented programming. Classes are not organizers of functions. And objects are not data structures.

So what is a "proper" object? Which one is not a proper one? What is the difference? Even though it is a very polemic subject, it is very important. Unless we understand what an object is, how can we write object-oriented software? Well, thanks to Java, Ruby, and others, we can. But how good will it be? Unfortunately, this is not an exact science, and there are many opinions. Here is my list of qualities of a good object.

Hits-of-Code Instead of SLoC

  • 964 words
  • four minutes to read
  • comments

Lines-of-Code (aka SLoC) is a metric with a terrible reputation. Try to google it yourself and you'll find tons of articles bad-mouthing about its counter-effectiveness and destructiveness for a software development process. The main argument is that we can't measure the progress of programming by the number of lines of code written. Probably the most famous quote is attributed to Bill Gates:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight

Basically, this means that certain parts of the aircraft will take much more effort at the same time being much lighter than others (like a central computer, for example). Instead of measuring the weight of the aircraft we should measure the effort put into it... somehow. So, here is the idea. How about we measure the amount of times programmers touch the lines. Instead of counting the number of lines we'll count how many times they were actually modified—we can get this information from Git (or any other SCM). The more you touch that part of the aircraft—the more effort you spent on it, right?

How Immutability Helps

  • 1609 words
  • 6 minutes to read
  • comments

In a few recent posts, including "Getters/Setters. Evil. Period.", "Objects Should Be Immutable", and "Dependency Injection Containers are Code Polluters", I universally labeled all mutable objects with "setters" (object methods starting with set) evil. My argumentation was based mostly on metaphors and abstract examples. Apparently, this wasn't convincing enough for many of you—I received a few requests asking to provide more specific and practical examples.

Thus, in order to illustrate my strongly negative attitude to "mutability via setters", I took an existing commons-email Java library from Apache and re-designed it my way, without setters and with "object thinking" in mind. I released my library as part of the jcabi family—jcabi-email. Let's see what benefits we get from a "pure" object-oriented and immutable approach, without getters.

An Empty Line is a Code Smell

  • 408 words
  • two minutes to read
  • comments

The subject may sound like a joke, but it is not. An empty line, used as a separator of instructions in an object method, is a code smell. Why? In short, because a method should not contain "parts". A method should always do one thing and its functional decomposition should be done by language constructs (for example, new methods), and never by empty lines.

How Much Do You Cost?

  • 2655 words
  • 10 minutes to read
  • comments
badge

I'm getting a few emails every day from programmers interested in working with Teamed.io remotely. The first question I usually ask is "what is your rate?" (we pay by the hour) What surprises me is how often people incorrectly estimate themselves, in both directions.

I hear very different numbers, from $5 to $500 per hour. I never say no, but usually come up with my own hourly rate estimate. This article explains what factors I do and don't take into account. These are my personal criteria; don't take them as an industry standard. I do find them objective and logical, though—so let me explain.

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
  String.format(
    "hello, %s",
    new Name(
      Arrays.asList(
        "Jeff",
        "Lebowski"
      )
    )
  ) // 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.

badge

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 Teamed.io.

How We Write a Product Vision

  • 1271 words
  • five minutes to read
  • comments
badge

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!