How to Be Lazy and Stay Calm

  • 1068 words
  • four minutes to read
  • comments

What frustrates me most in my profession of software development is the regular necessity to understand large problem scopes before fixing small bugs, especially if the code is legacy and not mine. Actually, it's even more frustrating when the code is mine. The "deep thinking," as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how.

Nine Steps of Learning by Refactoring

  • 1341 words
  • five minutes to read
  • comments

I was asked on Twitter recently how is it possible to refactor if one doesn't understand how the code works. I replied that it is "learning by refactoring." Then I tried to Google it and found nothing. I was surprised. To me refactoring seems to be the most effective and obvious way to study the source code. Here is how I usually do it, in nine object-oriented steps.

Fully Transparent Donations via Zerocracy

  • 461 words
  • two minutes to read
  • comments

Open source is free, as in beer: you write code, nobody pays you. Of course, there are many ways to monetize your efforts, but there will be no direct cash payments from your users, usually. There are ways to collect money, which include an obvious "tip jar" button on your GitHub project page. The chances anyone will pay are low though. In my opinion, this is mostly because nobody trusts you enough—they are not sure you will use the money to make the product better. Most likely you will just spend it and nothing will change. But they want the product, not to make you happier. At least that's what I feel when I see a Patreon button.

How I Test My Java Classes for Thread-Safety

  • 648 words
  • three minutes to read
  • comments

I touched on this problem in one of my recent webinars, now it's time to explain it in writing. Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I'm doing it.

Zerocracy: A Project Manager That Never Sleeps

  • 871 words
  • four minutes to read
  • comments

I've been in the software business for almost 30 years. I wrote my first piece of code when I was 12. Since then I have been programming and managing other programmers, hiring and firing them, planning projects and their budgets, finding and losing customers, investing into software teams and losing my investments, even teaching others how to manage software projects. What is my overall impression? It's a pain. I think I've found a solution though.

Fluent Interfaces Are Bad for Maintainability

  • 881 words
  • four minutes to read
  • comments

Fluent interface, first coined as a term by Martin Fowler, is a very convenient way of communicating with objects in OOP. It makes their facades easier to use and understand. However, it ruins their internal design, making them more difficult to maintain. A few words were said about that by Marco Pivetta in his blog post Fluent Interfaces are Evil; now I will add my few cents.

Don't Aim for Quality, Aim for Speed

  • 708 words
  • three minutes to read
  • comments

I decided to write this blog post after reviewing this pull request. What happened there? The author of the PR wasn't able to figure out the "right" way to implement it, and the code reviewer was waiting and waiting. Eventually, the reviewer came to me, since I was an architect, and complained that it was taking too long and he wasn't able to earn his money for the review he had done. Then the author of the changes explained that he couldn't finish since there were impediments and design inconsistencies; he also couldn't earn the money he deserved for fixing the issue. What did I say? I said: Forget the quality, just finish it any way possible.

Don't Parse, Use Parsing Objects

  • 331 words
  • two minutes to read
  • comments

The traditional way of integrating object-oriented back-end with an external system is through data transfer objects, which are serialized into JSON before going out and deserialized when coming back. This way is as much popular as it is wrong. The serialization part should be replaced by printers, which I explained earlier. Here is my take on deserialization, which should be done by—guess what—objects.

Microvesting

  • 560 words
  • three 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

  • 367 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

  • 961 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

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

sixnines availability badge