“The final delivered product should contain the sources, all needed dependencies and the documentation on how to build the system.”

Frequently this or something similar could be found in the requirements without a proper description what is really wanted and is often misunderstood on both sides. And sometimes it is dangerous as well.

One question should be: Is this a good requirement? If you’ll take a look at the definition of a good requirement, e.g. at wikipedia or the IEEE docs, this would be enough to start working. Btw. I would replace the “should contain” with “must contain” – it’s less ambiguous and represents a much better level of importance of the requirement. Maybe for some nitpickers it is essential to split this into more requirements – one for sources, one for dependencies and one for the documentation – Atomic!

Today someone asked if I’ve got Backups of every piece of code i’d wrote. Intimidating question and of course not. I’m sure I’ve got zipped backups of the last sources for some older ones but in most cases a backup of the VCS for the important projects. Somewhere the CVS for the ugly LaTeX things called Diploma thesis too.

I know only two cases were i really regret not having a backup.

And again… I had three very good days in Munich at the conference. Very good conversations, lots of presentations and fun too.

Sometimes strange things could be nice too – I’ve got an invitation from a consulting company to join an evening where practices for IT service management should be applied on the example of ‘grilling a steak’. Sounds funny. Service management is not necessarily my topic but meat in combination with fire -of course- is.

In many cases I’m not in tune with (many) consultants – it starts with the suits – and this evening sadly reinforced this feeling. As I arrived I realized that this event was obviously from higher management consultants for higher management consultants and there I sat surrounded by suits not knowing if I’m able or willing to adapt to the superior posted behavior and language. Of course I have to admit this did not apply to everyone and I shouldn’t be this biased. Heya there is beer and appetizers – Alsace Tarte Flambée with bacon and onions and sandwiches with some kind of stilton and figs.

…just basics. I believe my first encounter with JBoss as application server was in 2003 and most projects before where done with Apaches Tomcat. Nearly one or two years later – and with a little bit more experience with Java Enterprise – the JBoss system became the preferred app server by me and the tool of choice (in cases where I’ve got the choice).

Working with it on a regular basis started but since then I’d never thought about some kind of training. Due to I’m a development guy maintaining JBoss means in most cases something like setting up, deployment, config the datasources and security things – and all this mostly not in productive scenarios. As it happens, I’ve got the chance to visit a training for a week with a nice bunch of people. 7 from ops, 3 from dev and 3 rather undefined ones – a perfect mixture to see, discuss and solve problems from other viewpoints. Usually this could be the case in the daily work too but this was without pressure and more comfortably despite the extensive topics that were dealt with in just five days.

I’m on my way to the RoadShow and expecting much fun with some other guys working together. In some aspects the current openshift is still a little bit confusing (compared against v2) and not in productive use (here). So I’ll hope to get some nice inputs and discussions at the event.