Skip to main content

Posts

Developing The Organizational Language

This is another follow-up post on my first year at eyeo.

In a company where the norm was to shun any hype, and avoiding cargo-culting by all means, it was not easy to use the language I had come to learn in the industry. Mentioning "Agile" would derail any discussion into shoot-downs, anecdotes and personal opinions and experiences. Few of the agile values, principles or practices were taken at face value. The more experienced colleagues had bad experiences with "agile transformations", and the large majority of younger colleagues had not recognized the pains of silofication, nor experienced the joy of successful organizational change.

As is the norm these days, "DevOps" has already been reduced to infrastructure engineering. Scrum was a fad, XP forgotten, Kanban was a board on the wall. Sprints were pointless, we'd rather ship when there's a big enough reason to ship. Conway's and Little's laws were unknown, as were Lean, theory of constr…
Recent posts

Working in Teams over Working as Individuals

I recentlypostedthis sketch on Twitter:

Thanks to a few mighty retweets, it gathered a lot of views (9000 impressions, whatever that means). While that's fun and all, I still felt a bit sad that such an awfully simple insight can garner much more popularity than a thorough blog post that I put some hours into.

So, rather than let Twitter get away with this, I'll steal my own content back into the blog :)

The thread went like this:

Pondering how to battle individualism in companies. For some, it is counter-intuitive that teams can be more responsive, faster and even more accountable than single individuals.

Having "teams" in place is no guarantee that team work is happening. Be wary of too large teams, "I/me/mine", personal contact details instead of team point of contact. Good team is sailing crew, not galley slaves.

Beware heroes, go-to persons, calling in favors and other shadow handling of work. Real teams make the work explicit, both requests/needs and re…

An Anecdote About Trust

Back at uni, we had a semester about IT project management, and one of the highlights was this two-day off-site where we went to a camp and did team-building kind of exercises to explore social dynamics and stuff.

One exercise was called "Saboteur". In short, the mission was for the teams to recreate a complicated building block construction set in a different room. The constraint was that each team could only dispatch one person at a certain interval to study the original construction. The goal was to get to the identical structure first.

Additionally, each team was "infiltrated" with an unknown amount of saboteurs, tasked with slowing down their teams without revealing their purpose.

To counter for this, our team decided to use double-checking observation roundtrips to weed out the saboteur(s). The team members that were found to have provided wrong observations were excluded from making any more observation roundtrips. I remember this girl in particular that was…

Mediation in Teams

I recently found myself mediating a personal conflict within a team. In this post, I'll share what I quickly had to pick up and learn in order to do so.

Disclaimer: I am not a trained professional in conflict handling. If you find yourself in a similar situation, get professional help from a trained mediator and do not try to do anything without the backing of the supervisor(s) of everyone involved!
Spotting the conflict I try to keep some tap on the conversations that are happening around the company, and in particular I try sensing conflicts. In this case, I spotted what at first looked like a regular somewhat heated exchange in a distributed team, and then as the discussion continued, the participants started to pull for executives to come in and break the argument in their favor. The topic under discussion was definitely a team-internal thing, so my alarm bell started chiming. This didn't feel like a regular technical discussion. It had an air of threat and desperation to i…

The End of GitMinutes (my podcast)

I'm just about ship GitMinutes episode 46, which is going to be the final episode. I'll just paste the outro script here, as it sums up the sentimental thoughts pretty well:

I’m happy to have finally finished [publishing the last episodes from Git-Merge 2017], just in time before Git-Merge 2018 takes place in March. I won’t be going there myself, so I’m counting on someone else to pick up the mic there.

It’s sad to be shipping this one as it is probably the last GitMinutes episode ever. To go a bit down memory lane, 6 years ago, my daughter was born, and as I used a little of that paternity leave to set up my podcasting infrastructure and produce the first few episodes. Initially it was just going to be 10 episodes and call the experiment finished. Instead, I got to 46 episodes, the last dozen or so lazily tailing the last few Git-Merge conferences.

To every one of my guests, thank you so much again for coming on to share your passion in this little niche of computer science a…

Going for Lead-Time

Note: This topic of this post was heavily inspired by The Phoenix Project and the succeeding tome of reference, The DevOps Handbook.

There are many metrics out there that can guide you to improve your business, but in the upside-down world of Internet business, many of these can be plain wrong, or at least they do not serve well as guides for what you should be doing. If you measure success by measuring profit, for instance, you'll run out of good will with your users or partners very quickly.

Then there are a load of more noble but fuzzy numbers that you can measure by surveying employees or users. Think employee-happiness, etc. While these are definitely useful, they are easy to get wrong, and it's easy to over-do it, causing survey fatigue. They're also hard to trace from cause to effect. It's hard to say which particular company decision lead to some satisfaction rating going down.

Take the SWOT analysis as a particular one of these surveys. It will give you a grea…

How Silos Grow

In my previous post, I suggested several topics to blog about, based on my experiences of 2017. How Silos Grow was the topic most asked for:
This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders.
I've worked in silos, and in companies without them, but I haven't been there to witness them coming into existence before. It is a fascinating phenomenon, yet oh, so common. And a killer of great companies. This posts digs into why and how silos happen. It's a bit of a long one, so here's the TL;DR:
It is about human nature.Departments are a good thing (for some things).People in different departments are inherently different.The project method is still problematic (and reinforces the silos).Cross-departmental teams should be the first-class organizational unit instead. Although the idea to write this came from my first year at eyeo, thi…

Joining eyeo: A Year in Review

It's been well over a year since I joined eyeo. And 'tis the season for yearly reviews, so...

It's been pretty wild. So many times I thought "this stuff really deserves a bloggin", but then it was too inviting to grab onto the next thing and get that rolling.

Instead of taking a deep dive into some topic already, I want to scan through that year in review and think for myself, what were the big things, the important things, the things I achieved, and the things I learned. And then later on, if I ever get around to it, grab one of these topics and elaborate in a dedicated blog-post. Like a bucket-list of the blog posts that I should have written. Here goes:
How given no other structures, silos will grow by themselves This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders. I've worked in silos, and in companies without the…

Joining Eyeo

A couple of months ago I left Viaboxx, more than five years after I started there.

It was a great ride. It combined the excitement and intensity of working at a startup, with the safety of working with a profitable, self-organizing company of experienced full stack developers.

During the time there I worked with everything from Raspberry Pis to huge parcel stations, from single-page-webapp AngularJS applications and Node, to state-of-the-art modern Java-cloud applications. I learned how to do infrastructure-as-code with Puppet, and immutable infrastructure with Docker. We developed our own products, did research projects and provided consulting for big enterprises - always learning, always trying out new things. Being small allowed us to optimize for learning while having an awesome culture where colleagues felt like family or great friends.

Still, a part of me missed some of the challenges I worked more with when I was consulting, or working for larger companies. Helping people to wo…

Encrypting and Decrypting with Spring

I was recently working with protecting some sensitive data in a typical Java application with a database underneath. We convert the data on its way out of the application using Spring Security Crypto Utilities. It "was decided" that we'd be doing AES with a key-length of 256, and this just happens to be the kind of encryption Spring crypto does out of the box. Sweet!

The big aber is that whatever JRE is running the application has to be patched with Oracle's JCE in order to do 256 bits. It's a fascinating story, the short version being that U.S. companies are restricted from exporting various encryption algorithms to certain countries, and some countries are restricted from importing them.

Once I had patched my JRE with the JCE, I found it fascinating how straight forward it was to encrypt and decrypt using the Spring Encryptors. So just for fun at the weekend, I threw together a little desktop app that will encrypt and decrypt stuff for the given password and sa…

Replacing Boxen with Vanilla Puppet (for setting up a new mac)

I recently got a new MacBook at work and decided to overhaul my personal setup routine. Last time I tried an early version of Boxen, and although I was pretty happy with it there were a few things that bothered me. It is very opinionated, and I had a hard time stopping it from overwriting my .gitconfig and things like that. It also dragged in a series of dependencies I didn't feel the need for, and made Homebrew a bit weird by installing it in the non-standard location /opt/boxen/homebrew.

Since Boxen is based on Puppet, and I've used plenty of Puppet on Linux, I wanted to simplify things a bit and see how far standard Puppet on OS X would get me.

Warning! Make sure you don't install puppet using brew! It'll install an old version which is not trivial to uninstall.
It's fairly straight forward to install Puppet on a Mac, but since there is no standard package manager, like there's yum or apt on Linux, you have to set it up with a provider, in our case: Homebrew.…

Retiring from the Bonn Agile Meetup

Yesterday I organized my final meetup.

Back in February 2011, I invited to the first meetup, back then under the "XP" banner, renaming to be Bonn Agile a few months later.

So, wow, that makes it nearly 5 years, or 50 meetups after a rough count.

Most of these meetups were not organized by me though. I want to use this post for thanking the people who were around in the begining, co-organizing or just giving great feedback on how to get the meetup rolling.

I'm sure I'm forgetting some names, but +Patrick Cornelißen+Kurt Häusler,  +Frederic Hemberger, +Christoph Pater and +Jan Ehrhardt  took their share of the load back then until they moved from Bonn to other places. +Simon Tiffert and +Matthias Lübken provided valuable advice when starting up. As companies go, +tarent solutions GmbH+doo and, most of all +Data in Transit GmbH (big thanks to +Jutta Horstmann!) have been supporting the meetup since the very beginning, with +Viaboxx (my employer) hosting the annual S…

Android Voice Commands for Cyclists Listening to Podcasts or Music

Disclaimer: I do not recommend using earphones while on your bike, but there are times or roads where I think it's OK. Pull out your earphones when nearing potentially dangerous situations (like intersections). At least pause the audio.
These tips also apply to anyone unable to look at and touch their device, leaving voice commands their only option (useful for visually impaired people, people wearing thick gloves, etc). First of all, you need an Android with a fairly new version of Google Now installed, like Lollipop. You'll need a headset with a microphone button. I’ve got an iphone headset that works great with my old Moto G, excluding the volume control. You need to make sure that a connected headset can bypass the device’s lock mechanism. It’s in:         Settings -> Language & input -> Google voice typing -> Hands-free Your audio playback software has to work with the Google Now commands. I’ve tried Google Music and BeyondPod successfully. So, off we go! You’…

The Sweet Spot of Docker

I just stumbled across this "Ask HN: What is the actual purpose of Docker?".

After using Docker more and more over the last months, my answers have gradually changed. It used to be more hype-like, with "immutable infrastructure", "portable" and stuff like that. Now it's more practical, I feel I can say more concretely what our benefits are.

My favorite answer comes down to Docker being a standardized way of deploying and running applications.

The old way of deploying our software was complex with a taste of chaos, then became managed but complicated through the introduction of Puppet (or your configuration management tool of choice). I'm hoping Docker will nudge it more towards the simple (quadrant).

How we used to deploy (and still do) - most of these are done through home-made shell scripts we distribute using Puppet:

Installing Debian packages (mostly standard packages, sometimes from 3rd party repositories)Dropping WAR files into Tomcat (applic…

A Better Way to Git Push to Deploy (updateInstead & push-to-checkout)

Wow, nearly a year since my last post. I was sort of thinking it would be something more profound, but here goes: Git recently (with version 2.3) introduced a way of easily pushing changes into a remote non-bare repository, a.k.a. push-to-deploy. The old way would be to have a post-receive hook run some update logic which would do some procedure to update a non-bare repository. There now is a simple way of configuring the target repository to update its work tree instead upon being pushed to.

Now, pushing to the target repo may fail in cases where it has been modified, so soon after, a new push-to-checkout hook was introduced to deal with this, but it will only take effect in Git 2.4. I'll show how to set up both below.

Surprisingly, when searching for "push-to-checkout", I found very few articles about this, even though it was loudly mentioned on the GitHub blog (twice, and on StackOverflow, of course). So here's another one for the googles. Besides, I just wrote th…