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!

Corey's Pair Programming Tour

After my last rant on the missing quality in today's mainstream IT I got several mails from friends who had heard that I had quit my job (for the same reason). They asked me what I was up to now? The short answer is that I am planning a Pair Programming Tour (called Code Cop Tour). The long answer needs more explanation.

The Beginning
Like in every good story, let us start at the beginning - well maybe not at the very beginning, but let us start with Corey Haines. In 2008 Corey Haines, an US based programmer, lost his job and embarked on an unique, personal "Pair Programming Tour" around central US. He was travelling around, practising software development, pair-programming with people for room and board (room and food). InfoQ posted a summary about his first trip back in 2008, that I will in part repeat here: ... Corey Haines has embarked on a tour in the name of increasing our industry's emphasis on software as a craft. ... While he has dubbed the tour a "Pair Programming Tour", its ultimate intent is somewhat less about the practice of pair programming per se than it is about the ideas of what it takes for a software developer to really become good at what he or she does. ... Haines has posted video interviews revealing many of the unique insights he has gained about pairing, automated testing, and the evolution of a software craftsman while sharing the keyboard at the home-bases of Dave Chelimsky, Brian Marick, Uncle Bob Martin, and others.

Corey maintained a blog On Being A Journeyman Software Developer throughout his travels where he recorded his insights. While preparing for my own tour, I read it all, right from the first entry. Here is my summary:

Several Trips
Corey spent an entire year being a Journeyman Coder. A few others have done similar trips, but much shorter. These trips have been called "Pair Programming Tour", "Journeyman Tour", "Software Craftsman Road Trip", "Software Craftsmanship Walz" and so on. He split his journey into short tours of up to four weeks, using a conference or another event as leg for a trip.

For a certain trip he picked a region to explore, reached out to people that he knew in that region and talked to companies in the area, looking for places to allow him to visit. He knew a lot of people who worked from home, independents and remote workers, who he might visit. He prepared a list of places up front, with 50% already filled with people to pair or companies that would host him. For the remaining time he maintained a Pairing Calendar, that people interested in hosting him could look at.

Pair Programming
In general he spent between one and five days with people, usually two or three days, pair-programming on whatever they wanted to work on. He worked with people of widely varying experience and skill level on various projects. Due to the high density of well known individuals in his area he was also able to work with book authors, open source project leads and celebrities like Uncle Bob. He saw many aspects of software development, gained exposure to new software tools, learned new coding tricks and thus both actively trained others and got trained himself. (Pair Programming is next to many things a powerful technique for sharing knowledge.)

When visiting companies (I assume) he was just another member of the team and contributed as much as possible. Still he was an outsider with his own views and experiences, who most likely acted as agitator as well. (Obtiva's Jake Scruggs explained the role of agitator in his report about the 8th Light vs. Obtiva Craftsman Swap: The workers all believe the same, so they do not have a hard object to push up against. They got to sharpen their edges on me, and I got to sharpen my edges on them.)

Reflection during Travel
Between pairing sessions Corey drove around the country. He used the long road trips to think about what he had learned and reflect about conversations. He said himself that My head was so full of thoughts after the intense discussions with people; I just had to stop and record my very first "road thoughts." Maybe not by his planning, but this was an important part of a learning tour. To emphasize learning, we need to revisit the material studied before, reflect on it, sort it out.

Teaching
To Corey teaching was as important as learning. He updated his blog regularly, discussed new ideas or revisited old concepts. Next to recording his road thoughts he made several video interviews with people he had paired with. He talked at conferences and spoke at user groups on his way. Later he travelled around and organized Code Retreats in various places. He convinced people that software is a craft and explained the idea of Software Craftsmanship in general.

This is my understanding of the "classic" Journeyman Tour - and exactly this is what I will do. I am planning my tour since two months and in the next blog post I will describe my Code Cop Tour. Stay tuned ;-)