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 singlereturn 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.