Book on Agile Development Practices using Scrum

Quite some time ago I was invited to contribute a book chapter to a new German book on development practices and techniques for Scrum, edited by Roman Pichler and Stefan Roock. What an honor to join them on this book project, so I wrote a chapter on agile software development using the automated refactorings that modern IDEs provide. Meanwhile the book is already out since a few month and contains a collection of really cool chapters from all kind of different authors from the agile universe. Take a look if you are interested in agile software development and willing to read a book in German... :-)

Quite some time ago I was invited to contribute a book chapter to a new German book on development practices and techniques for Scrum, edited by Roman Pichler and Stefan Roock. What an honor to join them on this book project, so I wrote a chapter on agile software development using the automated refactorings that modern IDEs provide. Meanwhile the book is already out since a few month and contains a collection of really cool chapters from all kind of different authors from the agile universe. Take a look if you are interested in agile software development and willing to read a book in German... :-)

Book on Agile Development Practices using Scrum

Slides from Spring Tooing Talk at JAX 2011

Yesterday I gave a short talk at JAX 2011 called "Spring Tooling - What's Cooking". During the talk I gave an overview of the Spring tooling landscape, demoed some nice features of Spring IDE and the SpringSource Tool Suite and deployed a small Spring app into the hosted cloudfoundy.com PaaS as well as into a local CloudFoundry cloud running exclusively on my notebook. Was fun doing that all in 30min... :-)

Here are the slides from that talk:

• Spring Tooling - What's Cooking (pdf)

The slides also contain the part that I didn't talked about (the team behind Spring IDE and STS, challenges of distributed agile development and our release cycles). So if you missed that from the talk, take a look at those slides.

Yesterday I gave a short talk at JAX 2011 called "Spring Tooling - What's Cooking". During the talk I gave an overview of the Spring tooling landscape, demoed some nice features of Spring IDE and the SpringSource Tool Suite and deployed a small Spring app into the hosted cloudfoundy.com PaaS as well as into a local CloudFoundry cloud running exclusively on my notebook. Was fun doing that all in 30min... :-)

Here are the slides from that talk:

• Spring Tooling - What's Cooking (pdf)

The slides also contain the part that I didn't talked about (the team behind Spring IDE and STS, challenges of distributed agile development and our release cycles). So if you missed that from the talk, take a look at those slides.

Slides from Spring Tooing Talk at JAX 2011

Slides from Berlin Expert Days 2011

Yesterday I was invited to the Berlin Expert Days 2011 to give two talks, one on my lessons learned from using and coaching agile development methods and techniques and one about my OSGi experiences. Here are the slides now:

• 10 Agile Years Later - Lessons Learned (pdf, in German)
• OSGi Best and Worst Practices (pdf)

Thanks again for inviting me to this nice event!

Yesterday I was invited to the Berlin Expert Days 2011 to give two talks, one on my lessons learned from using and coaching agile development methods and techniques and one about my OSGi experiences. Here are the slides now:

• 10 Agile Years Later - Lessons Learned (pdf, in German)
• OSGi Best and Worst Practices (pdf)

Thanks again for inviting me to this nice event!

Slides from Berlin Expert Days 2011

Berlin Expert Days

I will be speaking at the Berlin Expert Days about my experiences from using agile methods over the past 10 years as well as some lessons learned from using OSGi for different kind of settings and situations. Looking forward to meet you at the event on April 7th in Berlin! :-)

I will be speaking at the Berlin Expert Days about my experiences from using agile methods over the past 10 years as well as some lessons learned from using OSGi for different kind of settings and situations. Looking forward to meet you at the event on April 7th in Berlin! :-)

Berlin Expert Days

Slides from WJAX 2010: Agile Practices in the Real World

Last November I gave a talk at the WJAX conference in Munich together with Matthias Lübken about our experiences using agile methods in difficult settings. We went trough our observations adapting or replacing typical agile practices with different ones when necessary and talked about what worked and what didn't. The slides are in a lightweight style, so the real content of our talk was spoken only. Nevertheless you can find the slideware we used here:

• Agile Techniken ungeschminkt (pdf)

Enjoy!

Last November I gave a talk at the WJAX conference in Munich together with Matthias Lübken about our experiences using agile methods in difficult settings. We went trough our observations adapting or replacing typical agile practices with different ones when necessary and talked about what worked and what didn't. The slides are in a lightweight style, so the real content of our talk was spoken only. Nevertheless you can find the slideware we used here:

• Agile Techniken ungeschminkt (pdf)

Enjoy!

Slides from WJAX 2010: Agile Practices in the Real World

SE-Radio Episode with Kent Beck is Online

The latest episode on Software Engineering Radio went online yesterday and covers an interview I did with Kent Beck on the history of JUnit and the future of testing and software engineering. I am pretty excited that we got Kent on the show and have him talk about these topics. He is definitely one of the most influential guys in software engineering these days - father of extreme programming, inventor of unit testing, co-creator of JUnit, co-creator of the agile movement, created test-driven development - to name just a few things he created/invented that changed the daily life of many software developers across the planet. I don't know why it took more than 160 episodes to have him on the show, but I think this was not the last episode on SE-Radio talking with Kent Beck... :-)

The latest episode on Software Engineering Radio went online yesterday and covers an interview I did with Kent Beck on the history of JUnit and the future of testing and software engineering. I am pretty excited that we got Kent on the show and have him talk about these topics. He is definitely one of the most influential guys in software engineering these days - father of extreme programming, inventor of unit testing, co-creator of JUnit, co-creator of the agile movement, created test-driven development - to name just a few things he created/invented that changed the daily life of many software developers across the planet. I don't know why it took more than 160 episodes to have him on the show, but I think this was not the last episode on SE-Radio talking with Kent Beck... :-)

SE-Radio Episode with Kent Beck is Online

Some More Thoughts on Software Architectures

Some month ago I wrote a blog post about some of my thoughts on software architecture and why I think the metaphor of a cathedral is no longer very useful for todays software development. I don't mean that you don't need an architecture when you do agile software development. A good software architecture is absolutely necessary to survive. It is an essential part of each system.

Nevertheless agile software development is based on the idea of embracing change. "Inspect and Adapt" is the secret of success in agile development. The structure of your software emerges over time when you constantly refactor your code. But is this also true for the architecture of the system? Does this architecture emerge over time as well? Or is it adaptable when life changes?

I discussed this a lot over the past years with various people. We typically found two basic contrasting (for this posting simplified) opinions:

• Opinion 1: The architecture includes the most important technical decisions. It is hard to change those things later on. Therefore the architecture should be defined at the beginning of a project and should experience only minor changes. Major changes in the architecture are considered a bad thing and should be avoided.
• Opinion 2: The architecture of a system is an artifact that emerges over time. It reacts to change by embracing it. Changing the architecture of a system is considered a good thing and part may be part of your daily live.

While I was always an opinion-2-guy, I always had to admit that some parts of the architecture of a system are hard to change. So changing a large rich-client app to a web-based app might be expensive. The same might be true for changing the implementation language or refactoring a classical three-tier app into a Quasar-like structure.

Then I recorded SE-Radio podcast episode 166 with John Wiegand and listened to him talking about what he calls "Living Architectures":

• SE-Radio Episode 166: Living Architectures with John Wiegand

During the episode he explains the basic architectural decisions behind the Eclipse platform and the Jazz project at IBM. Both architectures are surprisingly simple. They define the general idea of how parts of the system are built and interact. And both don't contain a single word about those things I mentioned above. Even the language is an implementation detail.

The Jazz system is, for example, built around the idea of the web. RESTful services define the heart of the structure. It doesn't matter how those services are implemented, which frameworks they use or how they are internally structured. The whole system might consists out of various languages, various runtime platforms, various infrastructure settings. Even object-orientation becomes an implementation detail of individual services. All things I often thought of being part of the general architecture. But now I know that I was terribly wrong about this.

Of course there are things that are expensive to change. Reimplementing a huge system with a different language might cost you a lot. But the question is: Why do you need to reimplement everything if you switch to another implementation language? The RESTful style, for example, doesn't require such a tight language binding. Its just an example, but it made me think. And it convinced me that "the definition of architecture as the set of things that are hard or expensive to change" leads into the wrong direction.

Architectures are living things. Don't treat them as dead artifacts. And don't be afraid of change. Its a good thing. It reflects your learning. It helps you build better systems.

Some month ago I wrote a blog post about some of my thoughts on software architecture and why I think the metaphor of a cathedral is no longer very useful for todays software development. I don't mean that you don't need an architecture when you do agile software development. A good software architecture is absolutely necessary to survive. It is an essential part of each system.

Nevertheless agile software development is based on the idea of embracing change. "Inspect and Adapt" is the secret of success in agile development. The structure of your software emerges over time when you constantly refactor your code. But is this also true for the architecture of the system? Does this architecture emerge over time as well? Or is it adaptable when life changes?

I discussed this a lot over the past years with various people. We typically found two basic contrasting (for this posting simplified) opinions:

• Opinion 1: The architecture includes the most important technical decisions. It is hard to change those things later on. Therefore the architecture should be defined at the beginning of a project and should experience only minor changes. Major changes in the architecture are considered a bad thing and should be avoided.
• Opinion 2: The architecture of a system is an artifact that emerges over time. It reacts to change by embracing it. Changing the architecture of a system is considered a good thing and part may be part of your daily live.

While I was always an opinion-2-guy, I always had to admit that some parts of the architecture of a system are hard to change. So changing a large rich-client app to a web-based app might be expensive. The same might be true for changing the implementation language or refactoring a classical three-tier app into a Quasar-like structure.

Then I recorded SE-Radio podcast episode 166 with John Wiegand and listened to him talking about what he calls "Living Architectures":

• SE-Radio Episode 166: Living Architectures with John Wiegand

During the episode he explains the basic architectural decisions behind the Eclipse platform and the Jazz project at IBM. Both architectures are surprisingly simple. They define the general idea of how parts of the system are built and interact. And both don't contain a single word about those things I mentioned above. Even the language is an implementation detail.

The Jazz system is, for example, built around the idea of the web. RESTful services define the heart of the structure. It doesn't matter how those services are implemented, which frameworks they use or how they are internally structured. The whole system might consists out of various languages, various runtime platforms, various infrastructure settings. Even object-orientation becomes an implementation detail of individual services. All things I often thought of being part of the general architecture. But now I know that I was terribly wrong about this.

Of course there are things that are expensive to change. Reimplementing a huge system with a different language might cost you a lot. But the question is: Why do you need to reimplement everything if you switch to another implementation language? The RESTful style, for example, doesn't require such a tight language binding. Its just an example, but it made me think. And it convinced me that "the definition of architecture as the set of things that are hard or expensive to change" leads into the wrong direction.

Architectures are living things. Don't treat them as dead artifacts. And don't be afraid of change. Its a good thing. It reflects your learning. It helps you build better systems.

Some More Thoughts on Software Architectures

Some Thoughts on Cathedrals and Software Architectures

While preparing a talk on module systems and architectures I remembered some old talks I listened to talking about architectures and arguing why an explicit software architect is necessary within professional projects. Many of them used the analogy of building a dog-house versus building a cathedral. For a small dog house, you don't need an architecture. But for the cathedral you do. Hm, agree, but where is the point?

I think the world has changed. Today for most software systems the analogy of building something like a cathedral is no longer a good choice. And I hope that people no longer have a cathedral in mind when designing software. We have learned that building software is a learning process, that requirements change all the time, that we need a short time-to-market, and most of all that we need feedback all the time - and react to this feedback quickly. Agile methods reflect this and allows us to move forward to modern ways of software development.

But our view on architectures need to reflect this. Modern software architectures need to be build for flexibility, for changing requirements all the time, for changing even fundamental layers of our software in a flexible way without causing tremendous costs. Having a cathedral in mind don't help you here. But if you still like the analogy of building real buildings (even though I think this is not always a good analogy to building software at all), you should take a look at some modern office buildings. Maybe they are not as beautiful as some of the old cathedrals, but they are built for flexibility.

But building flexible architectures is not an easy task. We need to build a flexible architecture and at the same time just what we need without designing all possible stuff upfront. Sounds like contradictory goals, eh? Hm, in some way, they are. I think modularity can help you to solve this conflict. Modularity (and I mean modularity on a higher level than individual classes or packages, but more something like Bundles in OSGi) helps you to think about dependencies, coupling, cohesion, and many of these nice design principles. And I think we all agree on having a good, decoupled design makes life easier when things change - and they will change.

While preparing a talk on module systems and architectures I remembered some old talks I listened to talking about architectures and arguing why an explicit software architect is necessary within professional projects. Many of them used the analogy of building a dog-house versus building a cathedral. For a small dog house, you don't need an architecture. But for the cathedral you do. Hm, agree, but where is the point?

I think the world has changed. Today for most software systems the analogy of building something like a cathedral is no longer a good choice. And I hope that people no longer have a cathedral in mind when designing software. We have learned that building software is a learning process, that requirements change all the time, that we need a short time-to-market, and most of all that we need feedback all the time - and react to this feedback quickly. Agile methods reflect this and allows us to move forward to modern ways of software development.

But our view on architectures need to reflect this. Modern software architectures need to be build for flexibility, for changing requirements all the time, for changing even fundamental layers of our software in a flexible way without causing tremendous costs. Having a cathedral in mind don't help you here. But if you still like the analogy of building real buildings (even though I think this is not always a good analogy to building software at all), you should take a look at some modern office buildings. Maybe they are not as beautiful as some of the old cathedrals, but they are built for flexibility.

But building flexible architectures is not an easy task. We need to build a flexible architecture and at the same time just what we need without designing all possible stuff upfront. Sounds like contradictory goals, eh? Hm, in some way, they are. I think modularity can help you to solve this conflict. Modularity (and I mean modularity on a higher level than individual classes or packages, but more something like Bundles in OSGi) helps you to think about dependencies, coupling, cohesion, and many of these nice design principles. And I think we all agree on having a good, decoupled design makes life easier when things change - and they will change.

Some Thoughts on Cathedrals and Software Architectures

Slides from Meet-The-Experts on Architecture

Last friday I was invited to give a talk at the Meet-the-Experts event in Solingen. I talked about my view on architectures in an agile world and how module systems drive those architectures for a flexible future. Here are the slides:

• How Module Systems Drive Architectures (pdf)

Enjoy!

Last friday I was invited to give a talk at the Meet-the-Experts event in Solingen. I talked about my view on architectures in an agile world and how module systems drive those architectures for a flexible future. Here are the slides:

• How Module Systems Drive Architectures (pdf)

Enjoy!

Slides from Meet-The-Experts on Architecture

ObjektSpektrum-Article on Agility & Architecture

Together with my colleague Stefan Roock I wrote an article on building architectures in an agile way for the current issue of the German ObjektSpektrum magazine. The article is part of a controversy with Thomas Lieder about how to incrementally build architectures in agile projects.

In the introductory part of the controversy we talk about the basics of agile methods and the goal of keeping a flat cost curve for features over a long period of time. To achieve this goal we need to change and refactor the software all the time. This is an integral part of agile software development. We learned that its not possible to foresee the future and therefore decided to design only the next steps - and refactor, if we learn over time and find better designs if new requirements appear. This is quite clear on the low-level of individual classes and nicely supported by test-driven development and refactoring tools.

If we use the same argumentation for the architecture of a project, the discussions get a lot more controversy. People don't believe that it is easy to change and refactor the architecture of a system incrementally and flexible over time. We found this discussion often times quite unstructured and using the term architecture in various flavors and meanings. To ease the discussion about agile architectures we divide between the basic architectural style and the concrete architecture of a concrete system. Our opinion is that the basic architectural style is hard to change over time (for example changing a system from a standalone-rich-client application into a multi-user app-server-based system could be quite hard). In contrast to this we believe that changing the concrete architecture and structure of a system could be done incrementally and agile over time. This is obviously not true for every application. They need to be build from ground-up for flexibility and change. But how to build a system that is easier to change over time, even on the architectural level?

From our point of view, there are three fundamental characteristics of design you need to remember every day to build flexible architectures: understandable, loosely coupled and free of redundance. There are many well-known design principles that helps you to build such systems. Keep them in mind, build loosely coupled components, think about good APIs between them - and you are on the right track to build flexible applications and flexible architectures.

Together with my colleague Stefan Roock I wrote an article on building architectures in an agile way for the current issue of the German ObjektSpektrum magazine. The article is part of a controversy with Thomas Lieder about how to incrementally build architectures in agile projects.

In the introductory part of the controversy we talk about the basics of agile methods and the goal of keeping a flat cost curve for features over a long period of time. To achieve this goal we need to change and refactor the software all the time. This is an integral part of agile software development. We learned that its not possible to foresee the future and therefore decided to design only the next steps - and refactor, if we learn over time and find better designs if new requirements appear. This is quite clear on the low-level of individual classes and nicely supported by test-driven development and refactoring tools.

If we use the same argumentation for the architecture of a project, the discussions get a lot more controversy. People don't believe that it is easy to change and refactor the architecture of a system incrementally and flexible over time. We found this discussion often times quite unstructured and using the term architecture in various flavors and meanings. To ease the discussion about agile architectures we divide between the basic architectural style and the concrete architecture of a concrete system. Our opinion is that the basic architectural style is hard to change over time (for example changing a system from a standalone-rich-client application into a multi-user app-server-based system could be quite hard). In contrast to this we believe that changing the concrete architecture and structure of a system could be done incrementally and agile over time. This is obviously not true for every application. They need to be build from ground-up for flexibility and change. But how to build a system that is easier to change over time, even on the architectural level?

From our point of view, there are three fundamental characteristics of design you need to remember every day to build flexible architectures: understandable, loosely coupled and free of redundance. There are many well-known design principles that helps you to build such systems. Keep them in mind, build loosely coupled components, think about good APIs between them - and you are on the right track to build flexible applications and flexible architectures.

ObjektSpektrum-Article on Agility & Architecture

Incremental Design at SEACON 2009

A few days ago I gave a short talk on Incremental Design at SEACON 2009, a new buzzword-free conference in Hamburg, Germany. Aside of the fact that this was the first conference in my beautiful home town (and only 15min away from home), I enjoyed to meet a lot of people there. I also made up a few slides for my talk, which you can now download as PDF (in German):

• Inkrementeller Entwurf (pdf)

And last but not least I used my new presentation tool called Session Five for the first time. Was absolutely great!

A few days ago I gave a short talk on Incremental Design at SEACON 2009, a new buzzword-free conference in Hamburg, Germany. Aside of the fact that this was the first conference in my beautiful home town (and only 15min away from home), I enjoyed to meet a lot of people there. I also made up a few slides for my talk, which you can now download as PDF (in German):

• Inkrementeller Entwurf (pdf)

And last but not least I used my new presentation tool called Session Five for the first time. Was absolutely great!

Incremental Design at SEACON 2009

Building a Lego Castle Incrementally and Interatively

My colleagues Henning Wolf and Arne Roock had a great idea for our company booth at the last JAX conference: Every attendee got a single LEGO brick in his conference pocket. The goal was to jointly build a LEGO castle at the booth, piece by piece, with a huge crowd of developers. So every attendee got a time slot of 30 seconds (a single iteration) to place one or more bricks and/or to refactor the existing building. And we had (and I think the builders, too) a lot of fun with that! Its always fun to work with these creative guys!

Arne and Marcel recorded a stop-motion-movie from the building process, taking a picture after each 30-seconds iteration. The final movie is published at the companies website:

• Stop motion movie: it-agile and the LEGO Experiment at JAX

Have fun watching the movie!

My colleagues Henning Wolf and Arne Roock had a great idea for our company booth at the last JAX conference: Every attendee got a single LEGO brick in his conference pocket. The goal was to jointly build a LEGO castle at the booth, piece by piece, with a huge crowd of developers. So every attendee got a time slot of 30 seconds (a single iteration) to place one or more bricks and/or to refactor the existing building. And we had (and I think the builders, too) a lot of fun with that! Its always fun to work with these creative guys!

Arne and Marcel recorded a stop-motion-movie from the building process, taking a picture after each 30-seconds iteration. The final movie is published at the companies website:

• Stop motion movie: it-agile and the LEGO Experiment at JAX

Have fun watching the movie!

Building a Lego Castle Incrementally and Interatively

JAX 2009 Revisited

My colleague and friend Matthias Lübken wrote with me a short blog-kind-of-a review, reflecting the JAX conference in Mainz last week. Just some thoughts and impressions on OSGi, Scala, Pecha Kucha (and more...) for the next Eclipse-Magazin. The online version is already available here:

• JAX-2009-Comments and Thoughts
  

But take care, its German... ;-)

My colleague and friend Matthias Lübken wrote with me a short blog-kind-of-a review, reflecting the JAX conference in Mainz last week. Just some thoughts and impressions on OSGi, Scala, Pecha Kucha (and more...) for the next Eclipse-Magazin. The online version is already available here:

• JAX-2009-Comments and Thoughts
  

But take care, its German... ;-)

JAX 2009 Revisited

Slides from WJAX 2008 online

Still being at the WJAX conference in Munich I took the time to put the slides online from all the talks I am involved in:

• Agiles Multi-Projekt-Controlling beim Deutschen Ring (in german, together with Norbert Grosz)
• Umstieg auf OSGi - aber wie? (in german, together with Matthias Lüken)
• Classloading and Type Visibility in OSGi
• Lessons Learned from Adopting "The Eclipse Way" (in german)
• Aspect Weaving for OSGi (together with Heiko Seeberger)

Enjoy!

Still being at the WJAX conference in Munich I took the time to put the slides online from all the talks I am involved in:

• Agiles Multi-Projekt-Controlling beim Deutschen Ring (in german, together with Norbert Grosz)
• Umstieg auf OSGi - aber wie? (in german, together with Matthias Lüken)
• Classloading and Type Visibility in OSGi
• Lessons Learned from Adopting "The Eclipse Way" (in german)
• Aspect Weaving for OSGi (together with Heiko Seeberger)

Enjoy!

Slides from WJAX 2008 online

Looking forward to WJAX and Eclipse Summit Europe

Saying goodbye to OOPSLA I am already thinking about the next two conferences coming up on my schedule and which are highly promising to be very very interesting. In a bit more than one week there is the WJAX conference in Munich, Germany. The program is fully packed with interesting stuff and I am quite happy to talk about some cool stuff as well.

Starting on Monday I will participate in the Agile Day at WJAX where I will talk together with Norbert Grosz about experiences from introducing agile development to an insurance company.
Next is the OSGi Special Day on Tuesday. Together with my colleaque Matthias Lübken we will talk about moving existing applications towards using OSGi. Later that day I will give my fun talk about classloading and type visibility in OSGi - I still love classloading stuff. :-) Wednesday I have the pleasure to share my experiences from using and adapting "The Eclipse Way" (the famous development process of the Eclipse team) for general in-house projects. And finally on Friday, at the OSGi Experts Day, Heiko Seeberger and I are going to showcase Equinox Aspects to the attendees. This will be a real fun week in Munich!

Not far away from WJAX is the Eclipse Summit Europe, starting at Tuesday, November 18th, in Ludiwgsburg, Germany. Together with Jeff McAffer and Heiko Seeberger I am organizing the Runtime Symposium on Tuesday morning. Take care you don't miss this symposium to meet people who are also interested or involved in the runtime projects at Eclipse. In addition to that I will give (together with Heiko) a short talk on Equinox Aspects on Wednesday.

And last but not least I would be really happy to hear from you what you would like to know from the talk on classloading and type visibility in OSGi. If you have any questions you would like to get answered within that talk, please comment on this blog entry. I will try to incorporate them into the talk.

See you there!

Saying goodbye to OOPSLA I am already thinking about the next two conferences coming up on my schedule and which are highly promising to be very very interesting. In a bit more than one week there is the WJAX conference in Munich, Germany. The program is fully packed with interesting stuff and I am quite happy to talk about some cool stuff as well.

Starting on Monday I will participate in the Agile Day at WJAX where I will talk together with Norbert Grosz about experiences from introducing agile development to an insurance company.
Next is the OSGi Special Day on Tuesday. Together with my colleaque Matthias Lübken we will talk about moving existing applications towards using OSGi. Later that day I will give my fun talk about classloading and type visibility in OSGi - I still love classloading stuff. :-) Wednesday I have the pleasure to share my experiences from using and adapting "The Eclipse Way" (the famous development process of the Eclipse team) for general in-house projects. And finally on Friday, at the OSGi Experts Day, Heiko Seeberger and I are going to showcase Equinox Aspects to the attendees. This will be a real fun week in Munich!

Not far away from WJAX is the Eclipse Summit Europe, starting at Tuesday, November 18th, in Ludiwgsburg, Germany. Together with Jeff McAffer and Heiko Seeberger I am organizing the Runtime Symposium on Tuesday morning. Take care you don't miss this symposium to meet people who are also interested or involved in the runtime projects at Eclipse. In addition to that I will give (together with Heiko) a short talk on Equinox Aspects on Wednesday.

And last but not least I would be really happy to hear from you what you would like to know from the talk on classloading and type visibility in OSGi. If you have any questions you would like to get answered within that talk, please comment on this blog entry. I will try to incorporate them into the talk.

See you there!

Looking forward to WJAX and Eclipse Summit Europe

Open XP-Days Germany 2008

The XP-Days conference series is a nice event series throughout Europe for people interested in agile software development (not reduced to Extreme Programming) and related topics. This years XP-Days Germany will take place in Hamburg from November 27th to 29th.
In opposite to the past XP-Days this years conference has an open review process in parallel to the submission process. This idea has two great advantages: everybody can review and comment on submissions via the submission system and people who submit sessions can benefit from those reviews and feedbacks by improving their submissions before the program committee decide. Sounds good, eh? I am used to this kind of open submissions from the EclipseCon conference and I must say: I like it a lot.
So don't forget to submit a proposal or give feedback on existing proposals - or simply join the conference this November!!!

The XP-Days conference series is a nice event series throughout Europe for people interested in agile software development (not reduced to Extreme Programming) and related topics. This years XP-Days Germany will take place in Hamburg from November 27th to 29th.
In opposite to the past XP-Days this years conference has an open review process in parallel to the submission process. This idea has two great advantages: everybody can review and comment on submissions via the submission system and people who submit sessions can benefit from those reviews and feedbacks by improving their submissions before the program committee decide. Sounds good, eh? I am used to this kind of open submissions from the EclipseCon conference and I must say: I like it a lot.
So don't forget to submit a proposal or give feedback on existing proposals - or simply join the conference this November!!!

Open XP-Days Germany 2008

EclipseCon 2008: Short Talk on Adopting "The Eclipse Way"

I put my slides from my short talk at EclipseCon 2008 about adopting "The Eclipse Way" online in the events section. Enjoy!

I put my slides from my short talk at EclipseCon 2008 about adopting "The Eclipse Way" online in the events section. Enjoy!

EclipseCon 2008: Short Talk on Adopting "The Eclipse Way"

Slides from OOP

Yesterday I gave a talk at the OOP conference together with Ivo Eitner, the technical project manager of a project I am involved in as a consultant over the past years. We talked about our experiences adopting "The Eclipse Way" within that project. If you are interested in the slides and are able to read and understand German, here are the slides as PDF.

Yesterday I gave a talk at the OOP conference together with Ivo Eitner, the technical project manager of a project I am involved in as a consultant over the past years. We talked about our experiences adopting "The Eclipse Way" within that project. If you are interested in the slides and are able to read and understand German, here are the slides as PDF.

Slides from OOP

EclipseCon 2008

I am very happy to tell you that two of my proposed sessions are accepted for presentation at EclipseCon 2008 in Santa Clara. The first one ("Spring OSGi Reloaded") is an updated version of last years tutorial about the combination of Spring and OSGi technology (now called Spring Dynamic Modules for OSGi Service Platforms). And I am very happy to be part of the tutorial team consisting of BJ Hargrave, Adrian Colyer, Bernd Kolb and myself. The second one is a short talk about "Lessons Learned from Adopting The Eclipse Way" for general in-house software projects.

I am very happy to tell you that two of my proposed sessions are accepted for presentation at EclipseCon 2008 in Santa Clara. The first one ("Spring OSGi Reloaded") is an updated version of last years tutorial about the combination of Spring and OSGi technology (now called Spring Dynamic Modules for OSGi Service Platforms). And I am very happy to be part of the tutorial team consisting of BJ Hargrave, Adrian Colyer, Bernd Kolb and myself. The second one is a short talk about "Lessons Learned from Adopting The Eclipse Way" for general in-house software projects.

EclipseCon 2008

Excellent Talk about Simplicity

In general I don't like to write too positive about things that happens within my company. This often sounds like pure advertisement for the company business and therefore I don't like it for my private blog. But today I need to make an exception. Not because I would like to do some advertisement but because I thing the talk given by Stefan Roock about "Simplicity in Software Projects" (held at the german XP-Days this year in Karlsruhe) is absolutely excellent. If you are able to understand spoken german you should definitely take the time (about 60min) and listen to Stefans talk (screencast or pure mp3). It is funny, entertaining and inspiring for every day project life. The sound quality is somewhat poor but the talk is definitely worth listen to anyway.

In general I don't like to write too positive about things that happens within my company. This often sounds like pure advertisement for the company business and therefore I don't like it for my private blog. But today I need to make an exception. Not because I would like to do some advertisement but because I thing the talk given by Stefan Roock about "Simplicity in Software Projects" (held at the german XP-Days this year in Karlsruhe) is absolutely excellent. If you are able to understand spoken german you should definitely take the time (about 60min) and listen to Stefans talk (screencast or pure mp3). It is funny, entertaining and inspiring for every day project life. The sound quality is somewhat poor but the talk is definitely worth listen to anyway.

Excellent Talk about Simplicity