Naming Fail

I’ve no idea what went wrong here. Nice, clean code. Javadoc is present. Completely useless.

/**
* Interface for switchable artefacts
*/
public interface Switchable
{
        /**
        * set the component on or off
        */
        public void setOnOrOff(boolean value);
        
        /**
        * returns if the artefact is on or off
        */
        public boolean getOnOrOff();
}

More Enumeration Fail

I recently came across of some brilliant chunk of WTF-code. The reason was that some swedish users complained about the software not caring about their language settings.

First step was to review the method which stored the settings:

public class DBwriter extends DBaccess {

    public enum Lang {
	DE, EN, FR, NL, SV, IT;
    }

    public void saveLangSetting(long userId, Lang lang) {
	super.executePreparedStatement("INSERT INTO usersettings VALUES ('?','?')", userId,lang.name());
    }
}

Second step was the method which fetched the stored settings:

public class DBreader extends DBaccess {

    public enum Lang {
	DE, EN, FR, NL, ES, IT;
    }

    public Lang getUserLang(long userId) {

	Lang res = Lang.EN;
	try {
	    res = Lang.valueOf(super.executePreparedStatement("SELECT * from usersettings WHERE id=?", userId).getString("lang"));
	} catch (Exception e) {
	    // why should this happen?
	}
	return res;
    }
}

It was a famous moment to realize what was happening there. But it even got better in the moment I found the only usage of getUserLang:

Lang lang = reader.getUserLang(id);
session.setLanguage(lang.name());

I’m just proud the thousand monkeys on their thousand typewriters somehow managed to store some languages successfully.

Enumeration Fail

The more I dig into some older code lately the more I wonder what my colleague was drinking all the time.

/**
* Enumeration of Names
*/
public interface Names
{
	static final public String NAME_1 = "ONE";
	static final public String NAME_2 = "TWO";
	static final public String NAME_3 = "THREE";
}

Why not. But at least he could have the javadoc fixed.

Java Singelton fail

Exciting WTF moments at work (no joke, stuff I’ve seen coded by real Java professionals):

public static ThisObject getInstance(){
   return this.instance;
}

So far, so good. Looks like a normal singelton pattern.

public static void setInstance(ThisObject object){
    this.instance=object;
}

This seems to be a little odd. But ok, I’ve seen this before for smuggling Mock-Instances during jUnit-Test into the otherwise static-referenced Singleton. Not nice but quite applicable when Unit-Tests are created for code fragments using this singleton.

public static ThisObject createInstance(){
    return new ThisObject();
}

This code really caused some raising eyebrows. Turns out that someone reused some methods in a kind of stateless way, which where supposed to work only statefully within the instance of the singleton. So he created this little factory method which always created unused instances. This actually worked because no static fields were accessed within the methods.

public static void killInstance(){
    this.instance = null;
}

Code actually used with a lazyloading singleton pattern. Actually this was proven to be working code. Think about it. Twice.

Formulate the obvious

Talking about project planning and project management it might sound obvious to state that it is quite useful to write down everything what gets decided. In fact many things seem to be obvious for those who are involved with the project. Usually the longer the time used to prepare a project, the more things get obvious.

When the first meetings to determine goals of an upcoming project take place, the discussions are  very controversial.  As a result, the protocols of such meetings are quite useless. But the more the expected results are discussed and outlined, the more things get obvious for everyone involved. As a result, the protocols are quite useless. Not again!

So the challenge seems to be to write down what everyone thinks is so obvious that it does no further discussion. But this is really hard work. Usually in every project there is a leading party. This may either be the customer for other-directed projects or higher ranking management for self-directed projects. The leading party in a project is the entity in the meetings whose opinion counts the most. And it is usually this same party which thinks everything is obvious and everyone in the room just likes to have a cup of coffee in a meeting.

The real challenge is now to find someone, who is willing to collect all those obvious informations and put it in a readable way which actually makes sense. This is actually a threefold challenge:

  1. Usually the information must be collected by filtering the important parts from everything what is said
  2. This has to be supplemented by all the information what has not been said but seemed obvious to the leading party
  3. The result has to be taken seriously by everyone involved in the project

Part one is usually hard enough as one soon finds out that everything said in a meeting usually does not make any sense at all when put together. So, this information has to be organized and “straightened”. But furthermore it is necessary to add all those details which are not spoken out. Actually not all of the information. It should be sufficient to identify what the leading party thinks is obvious and unnecessary to mention. This requires a very good knowledge about the project – which aspects of it are important but not discussed so far – and the leading party. The last point is the reason why usually the early stages of project planning lack of good documentation: No one really cares.

But it is of great importance that the documentation of the general project goals gets approved by everyone involved. If there remain white spots or even points of disagreement the whole project is most likely to be doomed.

Please note, that I’m talking about the very early stages of a project here. When I write about formulating the goals of a project, I’m not writing neither about the requirements specification nor the technical specification. Far before those very formal documents it is usually beneficial for a project to put the global requirements into terms. Especially when these are neither very specific nor very detailed yet!

Planning the planning

In my last post I postulated 18 points of inevitable steps in software development. Now I want to explain some of them. Let’s start on the top

First and – in my eyes – the one most important point is to organize the project evaluation itself. This might sound trivial but is most likely to get forgotten in the whole process. The reasons for that are diverse but one can classify them in two categories: other-directed projects and self-directed projects. An example for the first category are customer-ordered-projects whereas the latter could be normal product development e.g. implementation of a new major feature. In the first case, planning the planning is often omitted as a customer offers his own ideas on how things work. In the second case almost the same is done by some higher-ranking management person. Why first listen to those who should do the work when you already have a phantasy of what will happen? Never confront illusions with reality seems to be the devise here.

Everyone involved with project planning knows this situation: The idea of what the result of the project might look like has just been vaguely, informal described and now you are asked “Tell me, how long would it take?”. And now you are asked to compete with an absurd small period of time without any ressource-planning being made. And no matter what you answer – you suck! The worst thing you might do is to give an answer which can me interpreted somehow as if it is possible. But usually you should have enough knowledge in this situation to give at least an time-table what to do until you could answer this question and how long it might take. This is 1. because you got this position somehow and 2. hopefully for a good reason.

I’ve heard and seen a couple of cases where the give timeframe until the project can seriously be evaluated was far beyond the absurd assumption made previously. In this case you can either

  1. try by ignoring that you do not have the slightest idea of what the result will look like
  2. you are convincing that the time is necessary and either worth or the project is doomed or
  3. quit the job

Most project managers decide for the first option. As a consequence software development is most often somewhat of gambling where you can only bet whether the current project is doomed or keeps being dissatisfying. Please note, that the latter options is the more favorable one. Sad enough.

A project plan frame

No one working in software development would doubt that project planning is necessary and important. But one may doubt that anyone knows how to do it. Actually I don’t remember someone ever telling me that a project plan worked out just fine. But I know a lot of stories on how project plans just failed inevitably. And before I post something about the my greatest failures in project planning – this might come later – I want to write about how to frame a project plan which respects the most important aspects from my point of view.

First I will draw an outline of the project:

  1. Set a timeframe for project evaluation
  2. Determine and formulate the goals of the project
  3. Create or determine an prototype
  4. Determine and formulate the gained cognitions
  5. Determine and formulate the positive and the negative aspects of the prototype
  6. Revisit the goals of the project
  7. Evaluate the project: time-constraints, resource-constraints, quality-constraints, expected results
  8. Sketch out a project design
  9. Build a sophisticated project infrastructure!
  10. Split the project into tasks and assign them explicitly
  11. Create the implementation
  12. Check wether implementation fulfills the project goals
  13. Mend the implementation
  14. Check wether implementation fulfills quality standards
  15. Improve the implementation
  16. Create Documentation for usage, administration, configuration and deployment
  17. Approve the results of the project
  18. Deliver or use the results and be happy with it

Yeah, I know there are about a gazillon of different models for projects plans out there. So why come up with a new – such informal – one? The reason is, that all of this points must be done at some point, no matter what the project plan layout looks like. Whether you are working in a scrum-like-pattern or with a fully elaborated derivation of the V-Model. So this is not an alternative model made by some who thinks he can easily reinvent everything because he likes to ignore textbooks. This is merely an enumeration of what is unavoidable in a software development process – and nevertheless most often done wrong!