Vertical and Horizontal Decorating

  • 225 words
  • a minute to read
  • comments

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.

You're Just the Mayonnaise in a Bad Sandwich

  • 1371 words
  • 6 minutes to read
  • comments

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.

Are You a Micromanager?

  • 562 words
  • three minutes to read
  • comments

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.

How to Fire Someone Right

  • 490 words
  • two minutes to read
  • comments

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.

When Do You Stop Testing?

  • 682 words
  • three minutes to read
  • comments

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.

How to Set Up a Private Maven Repository in Amazon S3

  • 411 words
  • two minutes to read
  • comments

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.

Redundant Variables Are Pure Evil

  • 396 words
  • two minutes to read
  • comments

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.

Need Robust Software? Make It Fragile

  • 555 words
  • three minutes to read
  • comments

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.

Why Many Return Statements Are a Bad Idea in OOP

  • 258 words
  • a minute to read
  • comments

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.

Nine Steps to Start a Software Project

  • 2113 words
  • 8 minutes to read
  • comments

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.