Over the last weeks I read a lot about cognitive biases: typical mistakes, which people tend to make over and over. And some were scaringly familiar to me as a developer! Taking the right decision is one of the most critical activities in software development, so let’s spend a thought or two on those oh-so-familiar misconceptions.

It’s warm, the sun is shining, the sky is blue, you have php nerds ranting around - sounds familiar? Yes, it’s PHP Unconference time! It was the 2nd PHP Unconference in Europe, which took place last weekend at the Free University of Berlin. Thus, we Jimdos didn’t want to miss the opportunity to attend this awesome (un)conference.

There were loads of cool sessions, plus we gave a few ourselves, so here’s our review:

At some point as a software developer you have to answer the following question:

"How can I migrate big systems or make big software changes while still reducing risk of breakage, outages or data loss?"

The first great method is Branch by Abstraction. It’s primarily for avoiding feature branches and stale code by branching within your mainline codebase and not with you version control system: It’s the real mindset of continuous integration, instead of a big rewrite in a feature branch you introduce a new layer into your software.

What we did at Jimdo for example is migrating all of our user uploaded files from a local storage into the cloud. Before even starting the migration we introduced a new storage layer within the code. The former way was kind of copy and paste  programming like synthesizing the path to a file over and over again around the codebase without any unified interface. The new layer provided an indirection to the existing local storage, but without exposing the actual implementation (paths etc). We could implement the new layer step by step into the production codebase. Fun fact: Client code suddenly gets testable because you are able to stub your legacy storage layer implementation.

A problem we faced at this stage: How to ensure you won't break any existing code which has no unit or high level tests? We will get to this later.

So after having created a sane layer to our storage subsystem, we can start to implement the new shiny cloud storage layer implementation, of course with TDD :-). Next up have the challenge of migrating from the old to the new layer and everything without downtime!

But, this is really no big deal in the most cases. It’s data migration and has been done before. This is how we solved it for Jimdo:

First: Build a Migration Provider:

Last week Jan Lehnardt (aka @janl), lead-developer of CouchDB, co-organizer of JSConf.eu visited Hamburg. He is well known for awesome talks and keynotes at various conferences across the world. So when we invited him to see the coolest company in town - of course he couldn’t decline.

Should we use a physical board or an electronic tool?

In the agile world, this question is at the center of many heated debates. Both solutions have their advantages and both have their flaws. Physical Kanban boards have visibility and presence. They encourage face-to-face communication, enhance stand-up experiences and serve as a constant reminder of team goals and achievements. Digital boards are accessible from anywhere, making remote collaboration a breeze. Digital boards are great for distributed teams and maintenance of charts, and they link directly to the associated tickets. 

JimFlow is a hybrid tool that combines advantages of both worlds: A physical board linking all tickets to its digital counterpart through QR codes.