This Is Madness

Two months ago my time with Big Blue ended. While preparing for my Journeyman tour next month, I sorted out my drafts of blog posts and rediscovered some notes concerning my last assignment in the company. It was a particularly crazy time and I only wrote about it to clear my mind. Nevertheless, such gems need to be shared. As usual all my writing is fictional and does not resemble any real people or companies.

For my latest assignment I joined another team. I was happy at first because I worked with a new prototype, which was a nice change from my previous waterfall project. The team was led by a Distinguished Engineer, so my expectations were high. But soon the forces of madness showed.

Roll Your Own
First I noticed that one developer had created his own in-memory document store to support OLAP style operations, mainly pre-aggregated sums. I was not sure why he had done that, he had not checked existing third-party products before, but I guess creating your own database is a fun project to play with. Unfortunately many concepts where missing and the provided generality was not needed. (Note: One Does Not Simply create his or her own database system during a development project.) As a new member I did not want to question him during my first weeks and just accepted it. Later when he wanted to add some features, he rewrote the whole thing from scratch during a weekend, dropping at least one month worth of my additions. I was not amused.

Web or Desktop Application?
The project was under active development for almost a year and the business stake holders had still not decided if they wanted a web or a standalone application. The core developers were used to Eclipse/RCP, so they had created a server-client application prototype. When the business was finally ready to decide, the whole team spent two days creating estimates for both variants. "Surprisingly" porting the already existing desktop client to the web was rejected as being more expensive. I guess the business did not really care. (Note: Architecture decisions need to be made early in the project.)

Upload a File
Users needed to upload a large file to the server which would take several minutes. It needed to be extra reliable (but the exact term of "extra" was never defined). So the whole team met online to discuss the issue. One developer had the idea to use messaging for the upload because "messaging is usually reliable" and the company's flagship JMS product was extra reliable. I could not believe it - WTF? The client would still have to upload the file to the server to put it into the message queue. Further messaging is not designed to work with huge files. I begged the lead developer not to introduce a new component only to transfer a several MB file from the servlet layer to the service layer. At this time I started sending emails with "Madness? No this is reliaaaaaaable".

From Prototype to Production Over Night
The project had started as research prototype with the goal to experiment and compare different algorithms. Some of the numbers did not make sense and were being discussed and changed by the business people every day. Suddenly things changed, the whole project became production software and a deadline came up. The deadline was - of course - completely unrealistic but nobody told the business. Further more, there was a strict protocol for production applications in the company which needed many documents and formal reviews. Creating these artefacts delayed the deadline, too.

The Grand Finale
For all this bureaucracy, a young developer was brought in as architect. He did most of the necessary paper work which really helped but then things got nasty. He introduced code reviews - which is a good idea in general - but his findings were useless. First he forced us to use a large JavaDoc template which introduced much noise into our classes and then he demanded that every method would log its entry and its exit. My heart sank, but fortunately my twitter followers gave me permission to ignore his rules ;-)

Again this is not much more than a rant, but it is also a true story. Some of my friends enjoy reading rants, maybe my stories reassure them that one should not work for large corporations.

My Craftsmanship Tour

In my last blog post I described Corey Haines' Pair Programming Tour. This post is about my own "interpretation" of a Craftsmanship tour and my plan how to get it started.

After working too many years for banks and big IT providers, I needed a break. I was fed up with low quality work and wanted a change of perspective. Also the idea of practice and mastery appealed to me long before the notion of Craftsmanship was born. All these things culminated in the idea to go for a Pair Programming Tour.

September 2nd
My tour will start at Monday September 2nd. Initially I planned for one month which would allow for eight to ten pairing sessions. Obviously I was aiming low. At the beginning of August all September and half of October were booked, so I changed my mind and will go on as long as I can find companies or individuals to work with.

In and around Vienna
For my first tour I will stay mainly in and around Vienna. Most of my professional contacts are from Vienna and I hope to find companies more easily by removing the need to pay a hotel room for me. Several people had warned me that the need of a budget to host me would complicate matters in Austrian companies considerably. By skipping the journey out of my Journeyman tour I might lose the benefit of having time during travel to reflect about what I just learned. I will see how that affects my tour. I got invited to visit other places in Austria as well and will stay in Graz and maybe in Salzburg for a few days each.

Pair with me
I am looking for people that will pair with me for two or three days starting this September. Two to three days seems a good time to pair with a single person. If there are more people who want to pair, I can stay longer. In Vienna I am asking for free lunch and beverages throughout the day. The only condition is that we will pair program. It should be a quiet time without meetings where you plan development activities on the mainline of delivery, e.g. writing code, writing tests or improve your build system. Even spiking or general discussions about coding, design or Software Craftsmanship in general are valuable to me. Whatever you need to do during this time, we will work on it. I will be a regular team member and will support you as much as I can. We can work together on Java SE/EE, Scala and Ruby projects. If we do some Java Script, R, Dart or Forth I am sure to learn a lot but will probably slow you down as I am not fluent in these languages. I propose we use your machine as your work might require specific set-up but I will bring my keyboard and mouse.

Finding a host
Three months ago I started preparing my tour. I created a list of the best developers I knew in Vienna and got in touch. People running startups, like Raphael Stary of letsplay.io, did not hesitate and immediately agreed with hosting me for some days. Obviously startups are flexible and many of them already practice regular pair programming. But most of my contacts had to ask their management and that was where the fun started. Hardly any company knew Software Craftsmanship or the Journeyman concept and many still did not believe in pair programming. Only due to the help of my fellow craftsmen I got invited to a few larger companies till now. My friends had to convince their management and probably vouch for me to get my visit approved. I am still working on ways to pre-sell the idea to management but it seems impossible to get into companies without a persuasive Craftsman-agent inside.

Fine-print for companies
Here are some points to clarify my idea for managers: I am not interested in your customer or the project itself, just the learning and sharing. I will sign any NDA. If you do not want to be mentioned, I will not use your company's name in any posts or tweets. I will blog about my experiences during the tour. If a post covers my visit at your company I will show it to you before I publish it.

My expectations
People asked me what I want to gain from a Pair Programming Tour. Obviously I want to learn new things. I will work with people I have never worked with, see how they approach problems, "steal" one or two of their tricks. I will see new projects and experience the development process of different teams. I hope to get new perspectives, to think outside the box. Like it was Corey's, my main goal is to improve, reflect on our principles and broaden my mind. Finally I want to raise awareness for Software Craftsmanship in my area. Just today I got an email saying that it is great that the Software Craftsmanship movement has finally arrived in Austria. ;-)

Conclusion
So if you are interested in broadening your mind as well and want to pair program with me for a few days, contact me!