Microvesting

  • 523 words
  • two minutes to read
  • comments

Most startups don't have enough cash to pay programmers as much as they deserve, unfortunately (or maybe not). Instead of cash, startups give their early employees shares of stock, which they will be able to either 1) sell in a few years and become millionaires billionaires, or 2) throw away and remain nobodies. It's a common practice. The question, however, is what is the right procedure, and the optimal algorithm, to transfer those shares to programmers. When exactly do they become shareholders? What is the formula?

More Bugs, Please

  • 447 words
  • two minutes to read
  • comments

A bug is something we find in a software product that "doesn't look right" (this is my personal definition). A bug can be hidden or visible; it can be "already fixed" or "still present"; it can be critical or cosmetic; it can be urgent or of a low priority. What is important is that the more bugs we are able to find and fix before our customers see them, the higher the perceived quality of the software. Simply put, bugs are a very good thing, if they are found by us, not our customers. We pay our programmers for each bug they find. Here is a cheat sheet for them, showing where and how they can find those bugs, to make more money.

Are You a Coder or a Developer?

  • 659 words
  • three minutes to read
  • comments

Software development and coding are two different things. Usually, the former includes the latter, but not always. Coding produces lines of code, while software development creates products. Unfortunately, the majority of programmers joining Zerocracy now are coders. Even though they claim to be developers, in reality they are lacking the very important sociotechnical skills that differentiate product creators from lines-of-code writers.

The Educational Aspect of Static Analysis

  • 344 words
  • two minutes to read
  • comments

Very often new programmers who join our projects ask us whether we have auto-formatting instruments to make Java code look exactly the way Qulice expects. (Qulice is the static analyzer we use.) I always reply that having such an automated code polisher would only be harmful and wouldn't help the project and its members improve and grow. Here is why I think so.

Five Stages of Microbudgeting

  • 942 words
  • four minutes to read
  • comments

Microtasking, which I explained in an earlier post, works only when each task has a very specific reward for success and a punishment for failure. I believe that the best reward and punishment instrument is money. The budget is fixed, the programmer gets it only when the task is completed (reward), no matter how much time it cost; if it is not completed, there is no money at all (punishment). Pure and simple. However, a logical question arises: how can we know upfront what is the right budget? Who sets it?

Operator new() is Toxic

  • 501 words
  • two minutes to read
  • comments

To instantiate objects, in most object-oriented languages, including Java, Ruby, and C++, we use operator new(). Well, unless we use static factory methods, which we don't use because they are evil. Even though it looks so easy to make a new object any time we need it, I would recommend to be more careful with this rather toxic operator.

The Formula for Software Quality

  • 288 words
  • two minutes to read
  • comments

How do you define the quality of a software product? There is definitely an intrinsic emotional component to it, which means satisfaction for the user, willingness to pay, appreciation, positive attitude, and all that. However, if we put emotions aside, how can we really measure it? The IEEE says that quality is the degree to which a product meets its requirements or user expectations. But what is the formula? Can we say that it satisfies requirements and expectations to, say, 73%?

SRP is a Hoax

  • 590 words
  • three minutes to read
  • comments

The Single Responsibility Principle, according to Robert Martin's Clean Code, means that "a class should have only one reason to change." Let's try to decrypt this rather vague statement and see how it helps us design better object-oriented software. If it does.

Alan Kay Was Wrong About Him Being Wrong

  • 441 words
  • two minutes to read
  • comments

From time to time someone asks me what I think about what Alan Kay, the father of OOP, the designer of Smalltalk, the first object-oriented language, said in 1998 about OOP. He literally said that the very term "object" was misleading and a more appropriate one would be "messaging." Here is what I think.

DAO is Yet Another OOP Shame

  • 409 words
  • two minutes to read
  • comments

Someone asked me what I think about DAO and I realized that, even though I wrote about ORM, DTO, and getters, I haven't had a chance yet to mention DAO. Here is my take on it: it's as much of a shame as its friends—ORM, DTO, and getters. In a nutshell, a Data Access Object is an object that "provides an abstract interface to some type of database or other persistence mechanism." The purpose is noble, but the implementation is terrible.

How Micro Is Your Tasking?

  • 2264 words
  • 9 minutes to read
  • comments

"What are you doing now?"—when you hear this question from your boss, be aware: you're dealing with a micromanager. Keeping us busy is the key objective of these creatures and this is what makes them so annoying. To the contrary, effective managers make sure we are productive, meaning that our results satisfy their expectations. They are not interested in knowing what we are doing to deliver them—they manage the project, instead of managing us. And the first step to making the project manageable is to decompose its scope into smaller pieces.

Trust. Pay. Lose.

  • 440 words
  • two minutes to read
  • comments

"Listen up, dude," a friend of mine said when he called yesterday, "I trusted them for over a year—we've been partners. They've been programming it all and I was busy doing business development. Now they've quit and I'm left with nothing! What am I supposed to do with all these JavaScript files? How do I even know they are mine? Moreover, they don't even want to cooperate. I feel like a hostage. Please, help me out!" What could I say? "It's too late, dude," was my answer, "but the good news is—you are not the first to have this problem."

Constructors or Static Factory Methods?

  • 894 words
  • four minutes to read
  • comments

I believe Joshua Bloch said it first in his very good book "Effective Java": static factory methods are the preferred way to instantiate objects compared with constructors. I disagree. Not only because I believe that static methods are pure evil, but mostly because in this particular case they pretend to be good and make us think that we have to love them.

Five Features to Make Java Even Better

  • 730 words
  • three minutes to read
  • comments

I stumbled upon this proposal by Brian Goetz for data classes in Java, and immediately realized that I too have a few ideas about how to make Java better as a language. I actually have many of them, but this is a short list of the five most important.

Lazy Loading and Caching via Sticky Cactoos Primitives

  • 594 words
  • three minutes to read
  • comments

You obviously know what lazy loading is, right? And you no doubt know about caching. To my knowledge, there is no elegant way in Java to implement either of them. Here is what I found out for myself with the help of Cactoos primitives.