We’re starting a new thing, a seed fund. Its name is SeedRamp. The formula is simple: You schedule an interview, we have a one-hour conversation, you present me your startup idea, and we either give you cash right away or explain why we don’t feel like it. We don’t do any due diligence or background checks. The decision is made right there. It’s something similar to angel investment, but the amount is smaller—less than $20K, and decisions are faster.

Temporal coupling happens between sequential method calls when they must stay in a particular order. This is inevitable in imperative programming, but we can reduce the negative effect of it just by turning those static procedures into functions. Take a look at this example.

I keep repeating the same mistake again and again. So it’s time to stop and make a rule to prevent this from happening anymore. The mistake is not fatal, but it’s very annoying. When I look at production logs, I often see something like "File doesn't exist", and I ask myself: What file? Where is it supposed to exist? What did the server try to do with it? What was going on a second before it crashed? There is no answer in the log, and it’s totally my fault. I either 1) don’t re-throw or 2) re-throw without providing context. Both are wrong.

If I drive too fast and I get caught, I may get a ticket. If I drive under the influence and get caught, I may go to jail. If I turn my radio up too loud in the middle of the night and my neighbors call the police, I may get into trouble if I don’t stop it. The law basically protects us from causing trouble with each other. Why don’t we have a law against irresponsible coding?

The Ringelmann Effect (a.k.a. social loafing) is basically about people experiencing decreasing productivity when working in groups. We’re basically more productive when we work individually to achieve personal goals rather than being teamed up. That was discovered by Prof. Max Ringelmann a hundred years ago in 1913. Today, during my workshop in Berlin at DATFlock 2015, we tried to reproduce that experiment. It seems the French professor was right.

JSON or XML? Which one is better? Which one is faster? Which one should I use in my next project? Stop it! These things are not comparable. It’s similar to comparing a bicycle and an AMG S65. Seriously, which one is better? They both can take you from home to the office, right? In some cases, a bicycle will do it better. But does that mean they can be compared to each other? The same applies here with JSON and XML. They are very different things with their own areas of applicability.

There is a great book called Software Requirements written by Karl Wiegers about, well, software requirements. It’s a must read for every software engineer, in my opinion. There’s no need for me to repeat what it says, but there are a few very simple and very typical mistakes we keep making in our specs. I see them in our documents again and again, which is why I’ve decided to summarize them. So here they are, the ten most critical and typical of them, from the point of view of a programmer reading a specification document.

A chatbot (or chatterbot, as Wikipedia says) is a piece of software that talks to you in chat format. We use chatbots in a few (micro)services, and they fully replace user interfaces. I don’t think there is any innovation in this approach, but it has proved to be very effective over the last year or so. That’s the impetus for this post. Here is how the Rultor chatbot works for us and what its benefits are.

I want to create an iPhone app for my web service, but I don’t have programmers. Well, I don’t have iOS programmers. And I don’t have money. Sound familiar? What do I do? Right, I go to Google Upwork and find an awesome company in Bangalore that is excited to work with me for nothing reasonable money. In a few months and after a few thousand dollars, I realize this is not exactly what I expected. After yet another few months, I swear to God I’ll never outsource any software development to anyone. Is it just me? Not really.

InterruptedException is a permanent source of pain in Java, for junior developers especially. But it shouldn’t be. It’s a rather simple and easy-to-understand idea. Let me try to describe and simplify it.

I saw The Martian this weekend, and it triggered a few thoughts. Of course, I didn’t like the movie as a piece of art. It is total garbage, but this is not my point. There is something bigger to discuss, aside from the bad acting, primitive story-line, politically correct but absolutely unrealistic casting, and tons of logical inconsistencies. It’s Hollywood; what should I expect, right? Not just that. I think the problem is bigger.

When your team has to choose which technical decision to make, who has the final say? When one of your colleagues asks for a raise, who decides, and what is his or her decision based on? When it’s necessary to work overtime, how is it decided who will stay in the office? I’m expecting you to shrug your shoulders. You’re right, these questions never have explicit answers in modern organizations. We are used to working in a more “democratic” way, where such decisions are made subjectively by managers or more senior employees. Is this how it should be?

This is a short manual for you, my friend. I assume you are sitting in the office right now, reading this blog post. Maybe you don’t like your office job, or maybe you enjoy it and feel excited to be close to your office friends. It doesn’t matter. What matters is that there is always an alternative to office slavery. I’m not talking about starting your own business. There are people in this world who work for someone without doing what is described below. They do exist, as well as companies that don’t turn their employees into slaves. I really hope you will eventually find one. In the meantime, this manual is for you.

A decorator pattern is one of the best ways to add features to an object without changing its interface. I use composable decorators quite often and always question myself as to how to design them right when the list of features must be configurable. I’m not sure I have the right answer, but here is some food for thought.

That’s what a character played by actor Bruce Willis said to Robert DeNiro’s movie producer character in Barry Levinson’s brilliant film What Just Happened. I second that. Producers, recruiters, managers, real estate agents, sales agents, lawyers, and outstaffers—what do they all have in common? They are middlemen standing between money and the proletariat, taking a huge percentage for themselves but adding no value. Their very existence is our mutual misfortune. We are too weak to get rid of them now, but sooner or later every supply chain will be mayonnaise-free. Look at Uber—taxi companies are dead already, and we now have only drivers and passengers with a computer system in between. The same will happen everywhere else.

Micromanagement, according to Wikipedia at the time of this writing, is “a management style whereby a manager closely observes or controls the work of subordinates or employees.” Everyone knows micromanagement is evil, but what could be wrong with closely observing or controlling people’s work? Nothing. Observing and controlling is not what’s so bad about micromanagement. It is something completely different.

A friend of mine asked me today, “How should I fire someone the right way? What are the tricks to do it nicely, gracefully, and professionally?” I responded by saying that if you question yourself about how to do it right, you’re doing it wrong in the first place. If firing is a painful and unpleasant process for you, there is a problem with your management model. Firing must be an easy and open procedure, visible and understood by the entire team.

There is a software to be tested. There is a team of testers. There is some money in the budget. There is some time in the schedule. We start right now. Testers are trying to break the product, finding bugs, reporting bugs, communicating with programmers when necessary, doing their best to find what’s wrong. Eventually they stop and say “we’re done.” How do they know when to stop? When there is enough testing? It’s obvious—when there are no more bugs left and the product can be shipped! If you think like this, I have bad news for you. You’re fundamentally wrong.

Amazon S3 is a perfect place for keeping private Maven artifacts. I assume you keep public artifacts in Maven Central because you want them to be available to everybody. Private artifacts are those you don’t want visible to anyone except members of your team. Thus, you want to deploy your .jar files there and make sure they are visible only by your team. Here is how we do this in all our Java projects.

A redundant variable is one that exists exclusively to explain its value. I strongly believe that such a variable is not only pure noise but also evil, with a very negative effect on code readability. When we introduce a redundant variable, we intend to make our code cleaner and easier to read. In reality, though, we make it more verbose and difficult to understand. Without exception, any variable used only once is redundant and must be replaced with a value.

In any software project, the goal is to create something stable. We don’t want it to break in front of a user. We also don’t want our website to show an “internal application error” instead of a web page. We want our software to work, not fail. That’s a perfectly valid and logical desire, but in order to achieve that, we have to make our software as fragile as possible. This may sound counter-intuitive, but that’s the way it is. The more fragile your app is in development, the more robust it is in production.

This debate is very old, but I have something to say too. The question is whether a method may have multiple return statements or always just one. The answer may surprise you: In a pure object-oriented world, a method must have a single return statement and nothing else. Yes, just a return statement and that’s it. No other operators or statements. Just return. All arguments in favor of multiple return statements go against the very idea of object-oriented programming.

Agile or not, a software project starts with a requirements analysis and definition. We basically define what needs to be done somehow, be it on a piece of napkin or a 100-page Word document. The next step is to turn this into a working piece of software as fast as possible and by spending as few dollars as possible. Ideally, this prototyping takes a week and is made by an architect working solo. Once the “skeleton” is ready, we start putting software “meat” on it. We recruit a team of programmers for that or outsource it. I see nine important steps in the skeleton creation part; let me show you them one by one.

Do we need checked exceptions at all? The debate is over, isn’t it? Not for me. While most object-oriented languages don’t have them, and most programmers think checked exceptions are a Java mistake, I believe in the opposite—unchecked exceptions are the mistake. Moreover, I believe multiple exception types are a bad idea too.

What is the difference between a slave and a free man? A slave has a master. That master, a cruel and ruthless villain, is telling the slave what to do and punishing him at will. However, at the same time, the master guarantees food and a roof over the slave’s head. A slave understands this exchange of freedom for food as a fair trade, while a free man values freedom more. That’s the difference. That’s how it was in the Roman empire centuries ago. But isn’t that how it is now too? Aren’t we ancient slaves in our offices and in front of our monitors?

“We don’t have time to write unit tests” or “We don’t have the budget for unit testing” are complaints I hear very often. Sometimes it may sound like, “We don’t use TDD, so that’s why there are no unit tests,” or even “TDD is too expensive for us now.” I’m sure you’ve heard this or even said it yourself. It doesn’t make any sense to me. I don’t get the logic. In my understanding, unit testing is not a product; it’s a tool. You use tests to develop a product faster and better. How can you say you don’t have time to use the tool that makes your work faster? Let me show you how.

Software development is all about creativity, right? It’s an art, not a science. As software engineers, we solve complex problems, and often our solutions are absolutely not obvious. We experiment, innovate, research, and investigate. To do all this, we talk. We sit together in our meeting rooms, Skype conference calls, or Slack channels; we discuss our solutions; we ask our coworkers for their opinions; and we argue about the best ideas. There’s no doubt meetings are the key component of the modern software design discipline … and it’s very sad to see it.

I don’t know whether it’s an anti-pattern or just a common and very popular mistake, but I see it everywhere and simply must write about it. I’m talking about exception catching without re-throwing. I’m talking about something like this Java code:

try {
  stream.write(data);
} catch (IOException ex) {
  ex.printStackTrace();
}

I have a new String(array,"UTF-8") in one place and exactly the same code in another place in my app. Actually, I may have it in many places. And every time, I have to use that "UTF-8" constant in order to create a String from a byte array. It would be very convenient to define it once somewhere and reuse it, just like Apache Commons is doing; see CharEncoding.UTF_8 (There are many other static literals there). These guys are setting a bad example! public static “properties” are as bad as utility classes.

I don’t even know where to start. Let’s begin with this: If I don’t understand you, it’s your fault. This has to be the most basic, fundamental principle of a good software architect (well, of any engineer), but most of the architects I’ve met so far, in many companies, don’t seem to believe in it. They don’t understand that the job of a software architect is to make complex things simple, not the other way around. They use diagrams, which are the most popular instruments of an architect, to explain to us, programmers, what he or she has in mind. But the diagrams are usually very cryptic and hard to digest. What’s worse is that the complexity goes up in line with their salaries—it’s disgusting.

A year ago, I tried to explain how effectively data and its presentation can be separated in a web application with the help of XML and XSL. In a few words, instead of using templating (like JSP, Velocity, FreeMarker, etc.) and injection of data into HTML, we compose them in the form of an XML document and then let the XSL stylesheet transform them into HTML. Here is a brief example of how all this can be used together with the Takes framework.

A bug exists when something doesn’t work as expected. A bug fix is basically a patch (a pull request) to the existing code base that is supposed to solve the problem and make sure that “something” works as expected. Very often, such a patch fixes one thing and breaks many others. I believe that sometimes it’s necessary to reject a bug fix and ask its author to re-do the patch in order to protect the project from bigger problems. There are a few valid reasons for such a rejection, according to my experience.

Good programmers create fewer bugs while bad programmers cause more. Sounds logical, doesn’t it? However, there is a lot of criticism of this way of thinking. Take this one, for example: Bugs are inevitable, and instead of expecting fewer bugs from us, let us focus on the right design and let testers find and report bugs; then we’ll fix them. Or this one: Being afraid to make a mistake makes me write slower and experiment less, which translates into lower-quality software. Read more about that here and here. But allow me to look at this from a different perspective and assert that yes, indeed, good programmers create fewer bugs.

Software outsourcing is what you go for when you want to create a software product but software engineering is not your core competence. It’s a smart business practice being employed by everyone from $1,000 personal website owners to Fortune 100 monsters. And all of them fail, to some extent. Actually, it’s very difficult not to fail. Here is my list of simple hints to everyone who decides to outsource software development (the most important ones are at the bottom). I wish someone would have given it to me 15 years ago.

Here is what Wikipedia says at the time of this writing:

A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.

I think that’s incomplete. The definition entirely excludes “non-behavioral” defects related to, for example, maintainability and reusability.

Maintainability is the most valuable virtue of modern software development. Maintainability can basically be measured as the working time required for a new developer to learn the software before he or she can start making serious changes in it. The longer the time, the lower the maintainability. In some projects, this time requirement is close to infinity, which means it is literally unmaintainable. I believe there are seven fundamental and fatal sins that make our software unmaintainable. Here they are.

“Here is the specification; how much will it cost to create this software?” I hear this almost every day from clients of Zerocracy and prospects that are planning to become our clients and outsource the software development to us. My best answer is “I don’t know; it depends.” Sounds like a strange response for someone who claims he knows what he is doing, doesn’t it? “Here is the 20-page specification that explains all the features of the product; how come you can’t estimate the cost?” I can, but I won’t. Here is why.

I suggest classifying class constructors in OOP as primary and secondary. A primary constructor is the one that constructs an object and encapsulates other objects inside it. A secondary one is simply a preparation step before calling a primary constructor and is not really a constructor but rather an introductory layer in front of a real constructing mechanism.

When I start to repeat myself in unit test methods by creating the same objects and preparing the data to run the test, I feel disappointed in my design. Long test methods with a lot of code duplication just don’t look right. To simplify and shorten them, there are basically two options, at least in Java: 1) private properties initialized through @Before and @BeforeClass, and 2) private static methods. They both look anti-OOP to me, and I think there is an alternative. Let me explain.

Software outsourcing is a disaster waiting to happen; we all know that. First, you find a company that promises you everything you could wish for in a product—on-time and in-budget delivery, highest quality, beautiful user interface, cutting-edge technologies, and hassle-free lifetime support. So you send the first payment and your journey starts. The team hardly understands your needs, the quality is terrible, all your time and budget expectations are severely violated, and the level of frustration is skyrocketing. And the “best” part is that you can’t get away or else all the money you’ve spent so far will go down the drain and you will have to start from scratch. You have to stay “married” to this team because you can’t afford a “divorce.” Is there a way to do software outsourcing right?

When you enter your email and password into the Facebook login page, you get into your account. Then, wherever you go in the site, you always see your photo at the top right corner of the page. Facebook remembers you and doesn’t ask for the password again and again. This works thanks to HTTP cookies and is called cookie-based authentication. Even though this mechanism often causes some security problems, it is very popular and simple. Here is how Takes makes it possible in a few lines of code.

A software architect is a key person in any software project, no matter how big or small it is. An architect is personally responsible for the technical outcome of the entire team. A good architect knows what needs to be done and how it’s going to be done, both architecturally and design-wise. In order to enforce this idea in practice, an architect uses two instruments: bugs and reviews.

A software architect is a key person in a software project, which I explained in my What Does a Software Architect Do? post a few months ago. The architect is personally responsible for the technical quality of the product we’re developing. No matter how good the team is, how complex the technology is, how messy the requirements are, or how chaotic the project sponsor is, we blame the architect and no one else. Of course, we also reward the architect if we succeed. Here is what I, as project manager, expect from a good architect.

How much work should be done within a constructor? It seems reasonable to do some computations inside a constructor and then encapsulate results. That way, when the results are required by object methods, we’ll have them ready. Sounds like a good approach? No, it’s not. It’s a bad idea for one reason: It prevents composition of objects and makes them un-extensible.

When you hire a programmer or a team of programmers to implement your business idea, there is a significant risk of theft and accidental loss. They may implement your idea (or its elements) without you using their own resources. Also, they may disclose it to their friends, and those friends may disclose it even further, until it is eventually implemented by someone you don’t even know. This happens a lot—and everywhere. I’ve been on both sides. Here is my experience and a few recommendations.

Iterator is one of the fundamental Java interfaces, introduced in Java 1.2. It is supposed to be very simple; however, in my experience, many Java developers don’t understand how to implement a custom one, which should iterate a stream of data coming from some other source. In other words, it becomes an adapter of another source of data, in the form of an iterator. I hope this example will help.

There are plenty of books about software engineering, but only a few of them rank among my favorites. I read all of those that do over and over again, and I might just update this post in the future when I stumble upon something else that’s decent.