Christoph Jahn

gitosis is a nice program for hosting git repositories without having to give regular access to users. Using SSH under the covers, it basically acts as a special shell, thus limiting access to git. There are a number of nice tutorials available that explain how to make things work. I particularly liked this one. However, there is a lot of manual steps involved and a lot of errors can happen. I have therefore spent some time and started writing a few shell scripts that provide a more comfortable interface. At the moment the following scripts exist:

• gitosis-init.sh : Initializes gitosis and “installs” a regular user (not git or gitosis) for further admin work. This needs to be executed locally on the machine that runs gitosis. In order to avoid password hazzle, it is recommended to run it as root. Alternatively you can run it as the gitosis user. However, this mode has not been tested well so far. Any feedback is highly welcome.
• gitosis-add-repo.sh : Puts an existing local git repository into a remote gitosis repository.

The following scripts are currently planned for the future (other ideas are welcome!):

• Add user to gitosis (copy SSH public key over)
• Add user to repo (read/write access)
• …

Download: gitosis-scripts.tgz

Please note that the scripts were written on Debian Lenny (v5) and so far only tested on this system. For more detailed instructions please check out the man pages (also included in the scripts).

The Work Breakdown Structure (WBS) is a pretty well-known tool for managing projects. It is a formalized way to split a complex task into many small (and by that more easily manageable) parts. So instead of “install computers in rack” you have list with e.g. check availability of rack space, request network and SAN connection, arrange date/time with computer center, etc. This is probably a bit simplified, but you get the point.

I use the WBS a lot as soon as things become a bit more complicated. May favourite tool are spreadsheets, which have the following advantages:

• Everbody can use them
• You can send them around via email very easily
• Versioning is easy (via naming convention or use of a proper version control system)

What attributes should be maintained per task? I have the following:

• Task ID: Never use the lines from Excel. A simple re-sorting and you are screwed
• Status: green, yellow, red
• Progress: open, done, wip (work in progress)
• Area: Whatever makes sense to you. Examples: architecture, infrastructure, project management
• Owner: The person responsible for the task towards management. Please note that this guy is not necessarily the one who does (all) the work.
• Due date
• Description
• Activity log: Whenever something happens for the task, make a note with the date and your initials (you may not be the owner)
• Task ID cross-reference: Relationship to other task(s)
• External cross-reference: E.g. task relates to specific section of document

Depending on your requirements you may need additional information. You can also leave out some of the things from above, although I would discourage that if you don’t really know what you are doing. This list has been developed over a number of projects and sooner or later I was always thankful to have them.

So what is the relationship of the WBS to a project plan? The latter is generally more high-level, contains explicit dependencies, is more used to communicate with management. In many cases one line item in a project plan is basically detailed out by a WBS

“Everybody who loves attending presentations, raise your hand! No one? Hey, come on.  ……  Still nobody?”

Ok, so why is it that you may get this kind of reaction (although probably not so extreme)? In my view the simple reason is that the majority of presentations is just absolutely poorly done. People prepare at the last minute, if at all, execute lousy on that already weak preparation and then get the appropriate reaction from the audience.  Well, perhaps I am exaggerating a bit here, but I am convinced that most presentations fall short of what would have been possible with just a little bit of extra effort.

So here are the absolute basics:

• Know your audience in advance: If you have no clue who will be attending the session you are pretty much screwed. If you have prepared a presentation for techies and business people show up, there will obviously be a mismatch between them and what you say. So for those case where you are not sure, have a “plan B” right in your pocket. In practice that means that you have to prepare not one presentation but lets say 1.7. For the case of techies vs. business guys this means that you should also have some business-related content. How much backup you need, depends on the individual scenario.
• A presentation is not primarily about slides: These days many guys out there seem to think “presentation = power point slides”. That’s just plain wrong. A presentation is about conveying content (a “message”) to the audience. The slides are a means to facilitate and support that - nothing more, nothing less. You probably now the design principle “form follows function”. For presentations it is “slides follow story line”. Because that’s what you are doing, you are telling a story.
• The story line is crucial: All too often we end up in sessions where the presenter is going through a bunch of slides with no “big picture” behind them. This is when the story line is missing and the net-result is just poor. You especially see this when someone is giving a presentation where the slides were created by someone else. They basically tell one slide after another (or even worse just read them) and in the end you don’t what the overall message was.
  I have had a particular experience when the presenter was showing a mixture of self-made and “external” slides. The start was with the external ones and I almost left the room after 10 minutes. Then came a self-made one and I thought “Wow!”. Things immediately improved dramatically and my overall rating went from “This is an insult to the audience” to neutral. With just a little bit of in-advance thinking it would have been a really good session and it’s sad that the opportunity was missed.
• People want to be entertained: Think about what makes the difference for you between a good and outstanding presentation. What was special when you last left the room and thought “This was really good, I’m looking forward to the next session of this guys”. For me the main differentiator has always been humour. Nobody is interested in “content only”. Of course content is really important, but people also want a good show. Don’t be mislead: You are not expected to be comedian and crack one joke after another. But something amusing at the beginning (a so-called icebreaker) makes all the difference.
  What you choose depends very much on your personality because you want to be “authentic” here. It is also important to find a topic that allows you to smoothly proceed to the content side of things. Example: I was once looking for an icebreaker for a presentation about increased agility. A British colleague came up with a fantastic one about formula 1. So both parts were about speed and transition from icebreaker to content went just naturally.
• Not everything on the slides: Sometimes people think that everything they tell must be on the slides. I must confess to you that I once thought so as well and it’s just dead-wrong. The only job the slides have is to support your story line. Now you often want/need  to give something to people, either for later reference or because they missed the presentation. That’s a good thing to do but should not cause you to put everything into the slides. The right place for those details are the speaker notes.
• A short presentation does not mean little preparation effort: In many cases it is just the opposite. The simple reason is that the less time you have for presenting, the more you must try to come to the point quickly and at the same time avoid loosing the audience because of leaving out a critical detail. My personal record is a 10 minute presentation that took a full four man-days to prepare.
• The right level of animation: No animation at all during a presentation is probably just as wrong as having loads of them. To determine where it makes sense to hide things when the slide first comes up, think about the story line again. As it unfolds, so should the elements of the slide. If both sides go hand-in-hand you have the right mixture.
• Text on slides: Be very careful with text on your slides because it tends to distract the audience from you. They can easily look at a diagram that supports what you just say and still follow your speech. But as soon as they start reading their focus is on the slide and not you anymore. The two reasons why I put text  on slides are
  • quotes (e.g. from analysts) and
  • visualization for a line of arguments
• Face your audience: There is no reason to look at the slides and not towards the people in the room. If you do, you either didn’t prepare well enough and need to look at the slide for remembering what to say; or you put too much text on the slides and even with lots of exercising were not able to memorize things.
• Move around: Don’t stand next to your notebook all the time. For switching between slides mankind has invented cordless presenters; get yourself one.
• Involve the audience: This is not always possible but makes the whole thing more interactive. Don’t ask people to do things that might “expose” them too much. Unless you know the audience well enough the best thing is probably to ask questions like “Who has done XYZ before, please raise your hand”.
• Know thy time: You were (hopefully) given a slot with a certain length. Don’t exceed that time! It is unprofessional and unfair to the other presenters, because you steal their time. A couple of points here:
  • Practice upfront to get a feeling how much time you need; a rule of thumb is 5 minutes per slide.
  • Plan in a way that allows you to either leave out things or add some. Your advance planning of time will never be 100% accurate and this buffer will make you much more relaxed.
  • Take into account that people might ask questions.

There is certainly more but I think if you follow those points you already do a much better job than most people I have seen out there. Good luck!

Linus gave this presentation at Google a while back. Still worth watching

IBM has published a number of interesting articles about topics like SOA, architecture in general, governance etc. Please have a look at

http://www.ibm.com/developerworks/views/architecture/libraryview.jsp?search_by=Insight+outlook

It’s been 16 years that I have last visited London for non-business reasons. Unbelievable! The trip was short and I took only a few pictures but wanted to share them nevertheless.

[Show as slideshow]

Just shortly before Christmas I spent a day visiting the river Rhine that is pretty close to my place of residence. Nevertheless I had not been there before (shame on me). The wheather was not exactly great but on the other hand there were no tourists. I ended up in Koblenz at the famous Deutsches Eck (German Corner) where the river Moselle joins the Rhine. The pictures may seem a bit gloomy but that’s what the wheather was like. Nevertheless I greatly enjoyed things and will definitely come back in spring or summer …

[Show as slideshow]

One response I got for my post on Lifecycle Management was the following:

Are you saying that one idea is that an organisation can run its whole development lifecycle by modelling it inside of a BPM tool, using it like a workflow manager?

Yes, exactly. Many people are currently thinking about how they can streamline the approval chains they have around their software development processes. The challenge here is in many cases that the tools (project management, spreadsheets, …) are disconnected from the layer where the actual work happens. And we all know what happens in such a case sooner rather than later…

So the idea is to connect the various layers that have a role here. The top-level of such a process is usually about the “stage” of a software asset (e.g. new application, enhancement, bug fix etc.). What you can then do is manage the transition from one stage to another (e.g. from development to testing) by means of a BPM system. This is the first level of visibility.

To take things a step further would then mean to also connect the stuff that gets you a deeper insight. Those would typically be the technical systems like issue tracking (these have a broader scope than just bug tracking), built systems, results from automated testing etc.

So at the end it all comes back to the idea of end-to-end visibility. And here, once more, the advantage of a universal BPM system (as opposed to something that comes together with a specific application like CRM or ERP) kicks in: You can connect pretty much everything quickly and then model the process you want.

And for management the whole thing comes with reporting and business activity monitoring (BAM) out-of-the-box. So you not only know what’s going on an individual level but also get the complete picture in real-time whenever you want. I would think that this is what many managers are longing for.

Release It!

Michael Nygard. Pragmatic Bookshelf 2007, Paperback, 326 pages, $18.69

I bought this book about a year ago and -shame on me- only just read it. It’s really great for everyone that is interested in designing and developing robust software. So in that sense a must-read for all of us.

The book is organized in four general sections: Stability, capacity, general design issues and operations. For all of them a number of typical scenarios are described and general approaches discussed. The author seems to have a pretty strong Java and web application background (at least those are the areas of most of his examples), but the patterns and solutions are great for all systems, languages and use-cases.

So overall what we have here is a book that is fun to read and at the same time offers great insight into large-scale software systems. In my view everyone who works in this field can benefit from this book.

The author is also blogging on Amazon.com and seems to cover quite a few interesting topics.

For some time the topics of SOA Governance and BPM have been looked at as if they were two relatively unrelated things. And this perception is correct in the sense that you don’t have to have them together. However, more and more people realize what huge additional benefits are in for them if they combine the two things. In many cases the idea is that you need some logic to govern the actual work (design, development, testing etc.) for a process that has been modeled in a nice fancy tool.

But you can also do it the other way around: Think about what you would get if you could govern your whole IT lifecycle management from one tool. The idea goes like this: You store all relevant information about “objects” that are relevant for your organization in a central repository, and the different attributes that describes those objects (aka assets) are completely freely configurable. You probably need to attach additional information to them, like existing documentation etc. So in a way you can think of these information in the repository as a way to store the knowledge about all relevant aspects of the organization and then leverage this knowledge.

Now based on that groundwork, whenever a request for a new a feature in the IT landscape comes in, you can have it go through a “workflow”. The first steps would probably be about an approval chain. So people from various functions (e.g. product management, operations, security, marketing etc.) would need to either approve or reject this. How the final outcome is determined can be a bit tricky (and is much more a political topic than a technical one).

Then come steps like gathering requirements, signing them off, doing the development etc. You probably also want to integrate this whole thing with your development chain (automated testing, continuous integration etc.). At any given point in time you know where your development stands in terms of the project plan.

So if you step back a bit and look at what you get, we are not talking about development tools any more. Instead this is true, real-time end-to-end visibility. There are clear responsibilities for assigning tasks (a human being has to decide on something) and you no longer need to fear emails that are lost in the inbox of someone’s email program. Instead you get a view into the currently open tasks, their due dates etc. Other advantages existing but for now those are the critical ones. The reason for this is that these functionalities allow you to have automatically generated documentation that satisfies your compliance requirements. In most organizations these things eat up enormous amounts of resources and affect processes that should deliver value to the organization.

Let’s leave it here for now. I am quite interested in your comments on this, so please let me know.