migrations

Thinking beyond your team

Recently, couple of my teams decided to combine their codebases. It was essentially the same application, written twice over to do the UI for a wizard that went down 2 paths. Their backends do very different things. However, the customer sees a very similar interface.

After having done the migration, there have been some gripes. There is a lot of waiting between time zones. Ownership isn’t clear. Operational setup hasn’t been worked out. Perhaps the biggest issue was that there are two teams for a single codebase. It seems to trip people up when it comes to figuring things out.

So I’ve been asking this one question over and over:

Imagine the other team reported to you (or you were part of the same team). How would you solve this?

Another version of this question:

Imagine you had 15 people in your team across 2 locations. How would you run your scrum processes?

Once you remove the artificial manager/team/pod based barrier, people seem to work it out. This little mental barrier is the root of a lot of problems when collaborating. It is really important for people to identify their tribe. For most people, their tribe is their scrum team. Increasingly, that isn’t good enough to get the best results. At least in my team, we need to expand our view of what our tribe is.

Big redesign in the sky

This is perhaps one of the greatest articles every written on software rewrites. Every single developer should read and understand what it is trying to say.

...but the reality of green field projects is that they create the illusion that your messes don’t matter. Your messes do matter. Every single one of your messes matters. And if you don’t clean them up from the very start, you are going to wind up with a horrible messy legacy wad in short order.

How true. Few years back, I went through most of what is written in the article. I watched two systems, built to replace the same system before it, one after another. We fixed some messes but didn't quite understand what we were trying to overcome. Each new system got out of date and messy faster than the previous one!

This was also the reason for me hiring the architect for my new home. She walked around the old place and asked us about our messes, habits and workflows:

Why do you have a chair here? Is this where your mail pile up? Why do you take work calls from the sunroom?

Nowadays, whenever I hear about the need for a rewrite, I dig into understand issues in-depth. They often surface smaller pieces to fix.

Why is it hard to deploy? Let's run through a recent feature, why did it take so long?

Couple of other questions I ask:

Where do the rubbish pile up in the system? (example: are all the AB tests wired in your REST API and it is a monster...) What system do you have in place to collect the rubbish periodically?

Lastly, my colleague @Anuraag used to say:

Is your rewrite trying for a revolution or evolution? Definitely don't attempt a rewrite if you are looking for an evolutionary change.

Keep this in your bookmarks. Read it often. Share it with everyone. Thanks @JoeS for sending this to me few years back.