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.