Tagged: Programming

Is Endurance a Good Quality in Software Projects?

The ability to endure hardship without complaining is often considered a positive feat associated with “endurance” or “stamina”. However, endurance seems to be a double-edged sword (not only) in software projects. An appeal to speak up in software projects instead of just enduring the status quo.

The Enduring End User

Everyone who has been involved in a long-running or a maintenance software project knows this type of end user. He has been working with the software day in day out for years and knows all the pitfalls and bugs. He also knows workarounds for most of the pitfalls. Those workarounds take more time than originally intended, but he doesn’t mind. He knows that the working day is over at 5 pm. So he endures.

While the Enduring End User is not happy about all the bugs in the software he works with every day, the Outspoken End User literally hates them. As soon as someone tells him about some new workaround to be used to dodge a new bug, he grabs the phone and calls the project manager to express his disappointment in the software and submits a request to fix the bug. If no one reports the bug, how will it be fixed, after all?

The Enduring Developer

The software developer finds himself in the middle of things when working on a software project. The end user confronts him with new requirements regularly. The project manager assigns tasks and wants to know when they are done. There is no real software development process established in the project, so the developer manages all the incoming requests as fits best. He wants to perform good, so he finishes his tasks quickly. He is not always happy with what he delivers but it is like this in all software projects, after all. So he endures.

Meet the Outspoken Developer: he speaks up when he realizes that he cannot complete his tasks in acceptable time and quality. He says “no” if the project manager wants to assign him additional tasks. He alerts the project team to the missing development process. He alerts them again when nothing happens after the first time. He may not always finish his tasks in the time expected by the project plan, but he will deliver better quality.

The Enduring Project Manager

The project manager has the task of negotiating between customer (end user in many cases) and project team. Both parties are annoying at times. Especially if they just don’t shut up and keep pointing out things that could be done better within the project. But he knows how to deal with those rebellious sentiments within the project. They just have to be endured until forgotten.

The Outspoken Project Manager, on the other hand, adresses the proposals of other team members and stakeholders. He talks them through and by discussing them finds a solution that the project benefits from in the end.

Endurance? Yes, but…

The above descriptions can certainly be transferred to many more roles in projects (and not only software projects) and they are certainly a little exaggerated. However, be aware that it is easy to fall into a mode of just enduring a project instead of actively participating in it since actively participating means to step on someone’s toes now and then… .

Nevertheless,endurance is necessary: How often do we delve in foreign code trying to find a solution to some wicked bug we just can’t get our head around? In a situation like this you have to keep calm and endure the time-consuming process of finding and fixing the bug. The important thing is to not just move on after this tedious bug fix. Ask yourself what the cause was that brought you into that situation. What can be done better? If you know something, speak up and talk to people about how to make it better. Perhaps even set up a white board where proposals like this can be posted and discussed in the team.

Import Custom Tasks in Ant Scripts

I recently had to import custom ant tasks in an ant build.xml file. Custom ant tasks are usually shipped in a JAR file. Two options were available in the project’s context to make a custom ant task defined in a JAR file available in the build file. Those options are described below along the example of the antcontrib ant library.

Option 1: JAR file in %ANT_HOME%/lib

If you put the antcontrib.jar file in the lib directory of your ant installation, the library will be available by default. All you have to do is to load the ant tasks from this library:

<taskdef resource="net/sf/antcontrib/antlib.xml"/>

From this point on, all ant tasks defined in antcontrib.jar are available in your ant build file.

Option 2: JAR file anywhere

In most cases you don’t want to “dirty” your ant installation by putting a custom library in the lib directory. So, you have to specify the location of the JAR file (which would be in some sub directory of your project):

<taskdef resource="net/sf/antcontrib/antlib.xml"
  classpath="path/to/antcontrib.jar"/>

Using namespaces in Ant

To keep your custom ant tasks distinct from default ant tasks, you can add namespaces to each custom library. Here is a toy example:

<project name="MyProject" xmlns:antcontrib="net/sf/antcontrib"/>
<taskdef uri="net/sf/antcontrib"
  resource="net/sf/antcontrib/antlib.xml"
  classpath="path/to/antcontrib.jar"/>

<!-- now we have to use the prefix "antcontrib:" to access
  the antcontrib tasks -->
<antcontrib:foreach ... />
</project>

Optimistic vs. Pessimistic Version Control

Version control is a vital element in every software project, since every project member responsible for software development or configuration management has to use it. Thus, the choice of the right tool should be well considered. With this choice comes the choice of a collaboration paradigm: optimistic version control or pessimistic locking of the resources contained in the project repository. Both paradigms offer a solution to resolving or avoiding conflicts when two developers want to access the same resource at the same time.

Optimistic Version Control

Optimistic version control is the default setting in prominent tools like CVS or Subversion. A conflict is created and resolved the following way:

  • Persons A and B get resource X from the repository
  • Person A checks his changes into the repository
  • Person B tries to check in his changes and is alerted of a conflict
  • Person B merges his changes into the version of X checked in by Person A

Pessimistic Locking

Pessimistic version control avoids conflicts altogether by locking resources.

  • Person A gets resource X from the repository, locking it
  • Person B tries to get resource X from the repository but cannot, since it is locked
  • Person A checks in his changes into the repository, unlocking resource X
  • Person B can now get resource X from the repository an do his changes

This technique is pessimistic in that it expects the worst, which in this case is persons A and B editing resource X at the same time.

Why Pessimism is bad

In my opinion, pessimistic version control is just a measure of some manager to let the poor developers feel who’s the boss. The term “pessimistic” alone should be enough to think about another solution (try explaining to someone not involved in software development why we are pessimistic about version control…).

The main reason for my opinion is the fact that while resources are locked by someone, no one else can work on these resources, effectively blocking the progress of everyone else, who just now needed to change something. Plus, if I want to change a resource someone else is currently blocking, I have to call this someone and tell him to drop me a note when he’s finished, which is organizational overhead. For resources that are changed often (like configuration files or central source files) this can be a severe problem!

I often hear the argument “But when a resource is locked, we don’t have to merge anymore. And merging is evil, because it is much work and error prone”. It is not. There are tools to help the developer to merge files. These tools are proven. In most cases you only have to look at the tools’ output an confirm it. Merging files only gets nasty when a file has completely changed…which is rarely the case.

Another argument for pessimistic locking is this: “In large teams, many people are working on the same repository. Thus, optimistic version control would result in a lot of merging”. Besides the previous argument that merging is neither difficult nor dangerous, a large team should work on a large project. What is the chance that 2 out of 20 developers try to access the same resource (out of 20 000) at the same time?

Additionally to the above argumentation for optimistic version control I have had some rather bad experiences with pessimistic version control. Someone always forgets to check his sources back into the repository. Very frustrating if this someone is not reachable by phone because he’s sick or on vacation. Furthermore, not all tools boasting the locking feature really work. In my case, the locking mechanism didn’t always work and you had to merge anyways. Or the tool let the developer choose whether to lock or not. This made it possible for Person B to check in his changes while Person A had the resource locked…automatically creating a branch without letting the developer know this. I don’t want to know what changes were lost due to this bug… . Very ugly, indeed.

So…why not let the developers actually work instead of letting them twiddle their thumbs while waiting for someone to release a lock?

Code Smell: Constants Interfaces

As I am currently refactoring the code of an application created by an insurance company, I will document some code smells I encountered. This way, I will be reminded if I am ever tempted to create such code myself. I’ll begin with constants interfaces, which are a legacy of pre-Enum days and lazy coders.

Constants Interfaces

Constants Interfaces are created in order to save the lazy coder some key strokes. A constants interface is an interface defining nothing but constants and looks like this:

public interface MyConstants {
  public static final String MY_CONSTANT_1 = "foo";
  public static final String MY_CONSTANT_2 = "bar";
  // ...
}

This interface can then be “implemented” by other classes  that need access to the constants. The constants can be used without the prefix “MyConstants.”.

public class MyClass implements MyConstants{
public void doSomething(){
    System.out.println(MY_CONSTANT_1 + MY_CONSTANT_2);
  }
}

Why is this bad? There are several reasons (some of which may be subject to flavor-discussions).

The Code Smell

First of all, interfaces were designed to describe the behavior of a component (i.e. its methods). Thus, an unbiased programmer expects an interface to describe behavior and will be irritated if he only finds constants.

Second, the use of such an interface encourages the habit of simply implementing the interface, even if only one or two of perhaps 50 constants are used. Thus, 48 constants are visible in the implementing class but are not used, which violates encapsulation. Furthermore, if the implementing class is part of a class hierarchy, all subclasses will also have direct access to the constants defined through the interface. In my current refactoring assignment the constants of a single interface were visible in >100 classes of a rather unflexible class hierarchy (which should also be subject to refactoring). Worse: some classes high up in that hierarchy implemented more than one constants interface, making all constants visible in sublasses.

Third, though admittedly a weak argument, using a constant with its class prefix (MyConstants.MY_CONSTANT_1) is more self-documenting than using the constant name alone. Assuming, of course, that the class and constants names are well chosen. If the class prefix is always used, the single advantage of constants interfaces is lost.

Better Solutions

In conclusion, interfaces defining nothing but constants are bad practice and should be avoided. If such interfaces are already present, they should be refactored into either enums or final classes with a private constructor.