Talk: "methodological software development"

As I said - I'll try to keep this more current...

As mentioned in my previous post I just returned from my talk at the GI in cologne and besides the issues with the colour of my slides I think it went quite well.
I surely would attend the GI meetings more often if only they where not on tuesdays - the athmosphere was rather open and the discussions gave some rather interesting pointers.

For those who would like to see the slides again: You can download them from www.michaelmahlberg.de/GI-MethodenMichaelMahlberg.pdf. But you should be prepared for a somewhat lenghty download - apart from the "slightly" dark appearance on screen a textured backdrop tends to create large pdf outputs... in this case about 10 Megabyte...

Lessons from my last talk

As some of you may know im a big fan of Presentation Zen and try to follow some of the ideas in my talks. Today I was reminded of a few lessons I should have thought about beforehand:

No matter how cool your slides may look with that subtle gray-in-black backdrop and the translucent, intersecting areas - don't rely on it. Always keep a second set of slides handy that is optimized for bright ambient lights if you can't check the location beforehand! It's not important how it looks on your screen or in your controlled environment - it's import how it transports your message during the presentation. Therefore: bright coulours and high contrast for all unknown environments (at least as a backup).

Although I believe that a presentation is not the set of slide (i.e. you can never mail a presentation to someone - you can only mail the slides) I tend to put some effort in slide-design and so they ought to look good.

The other point is file size - since I converted to the Mac I tend to adopt a somewhat disrespectful attitude regarding the size of elements I use in a presentation - that's allright as long as the main point of the slides is to support the talk. As soon as I want to distribute them I could be running into trouble - for example when a simple 37-slide slideshow results in an almost 10MB pdf...

regarding the talk itself ... see next post

Upcoming Talk(s)

Following some examples from colleagues I'll try to post a little more information on my upcoming activities. Right now the list contains only one talk, but I'll try to keep the information on this blog more current in the future.

• I'll hold a talk on the state of the practice of "methodological software development" for the Cologne chapter of the GI (Gesellschaft für Informatik / German Chapter of the ACM ) on June 12.
  The talk will give a quick (20 minute) overview over practical experiences with applied development methodologies from SADT and IEM to XP and Scrum over the last two decades.
  Unfortunately the website is not quite up to date yet, but at least the location plan ought to be correct.
  

BTW:
Is "praxis-talk" really a legal english term?

Are technical topics no business topics?

I started to write this about a year ago - I think it's time to finish my earlier posts to get at least the basic ideas behind them in writing before I try to start new topics.

Every now and then I come across the silly notion, that technical decisions - like "Java Yes, Ruby No" - are considered to be "not of business relevance" and are to be left to the "IT department" since "the business folks wouldn't know anyway".

Apart from the inherent hubris from "IT" people with that attitude I think this point of view is rather short-sighted. If there are implications the business is not aware of it is the solution providers responsibility to inform the business people.

But - getting back to Java vs. Ruby style questions - to build a certain application with an estimated life-span of 6 month (e.g. because there is a legal requirement for exactly that time-span) might be a sensible thing to do in language 'Y' while it may be more sensible to assign two interns to do manual data corrections than to build an application using language 'X'.

You may substitute X and Y in the above paragraph with Ruby and Java respectivly according to your personal bias (or - for that matter - with any pair of programming languages) but the business people really should have a the last word in the decision.

ceterum censeo: We (including me) should really stop using the term "IT" ... if only I knew a suitable substitute ...

Dictatorship of the Dominant Decomposition

Well I thought this was well known, but obviously it isn't - a least outside the aspect-oriented crowd. So here are a few pointers for starters.

As a matter of fact I was wrong about the phrase though - it is called:

The tyranny of the dominant decomposition
(scroll down a little in the Glossary)

The original Papers can be found at ibm's reasearch site. Opposed to the AOSD glossary my preferred paper is the one about Multi-Dimensional Separation of Concerns. The one about Morphogenic Software is still worth a read though.