Multiple Perspectives On Technical Problems and Solutions

Multiple Perspectives On Technical Problems and Solutions” is an interesting take on engineering in general and software architecture in particular.  It starts off with:

Fundamental: engineering decision-making is a socially constructed activity

[…]

In other words, engineering (as an activity) does not have “correct” solutions to problems. As an aside, if you’re looking for correct solutions to problems, I’d suggest that you go work in a different field (like mathematics); engineering will likely frustrate you.

It then goes into dialogues and discussions, architecture review meetings, and provides a few pointers on how to get the best of those.

Atlassian Stride

Stride is a new product from Atlassian.  It is a re-branded and, hopefully, improved HipChat.  I haven’t tried it yet, but our team account will be upgraded soon enough.

To be honest, I’m not that excited about this move, but I’ll give it a benefit of a doubt.  I know there was a lot of hype about Slack recently, but I was really happy with HipChat.   I tried Slack for three days, and ran away.  But HipChat I can’t leave without.  It’s a much simpler and cleaner user interface, and it just works – completely out of your way.

Judging by the screenshots, Stride is a user interface upgrade to HipChat.  Atlassian has been moving to the new design recently with BitBucket and possibly other tools, so this part makes sense from at least their perspective.  Stride also brings free video calls, voice calls, and screen sharing.  HipChat had this option for the premium accounts (2$/month/user).  We tried it for a month and reverted, as the quality of calls and video was horrible.  And there were constant crashes and disconnections. Hopefully, Atlassian has put some work into these issues for the Stride release.

The most annoying thing about the upgrade from HipChat to Stride will be all the integrations.  Atlassian is promising to migrate all the data – history, files, custom smileys, etc.  But the best part about HipChat are the integrations.  We have a whole lot of them – GitHub, BitBucket, TravisCI, Twitter, WordPress,  Zabbix, and even our own custom ones, that we use for project deployments.  All these will have to be reconfigured and setup for Stride separately.  That’ll take a few hours here and there to get things back to where they were.

As far as the new features go, I don’t see too much yet.  Apart from the already mentioned voice calls, video calls, and screen sharing, there are just a couple.  Focus Mode is not really a big feature.  HipChat, much like any other messaging application, already had the status (Online, Away, Do Not Disturb, etc).  So Focus Mode is pretty much the same thing, with an extra time setting, so that you don’t forget to change you status back after a couple of hours.

Actions and Decisions is a nice addition.  You’ll be able to mark any message as an action or decision so that its easier to find and follow up on later.  But for us that’s not going to do much as we are already using Redmine for the project management.  Actions go into Redmine as tickets, and can later be referenced in commit messages, linked to each other, etc.  Having actions in Stride will probably work for very small teams with very few projects.  For us, we have a separate room for every project, every team, every office, and then some.  So searching for actions in a hundred-something rooms is far from perfect.  But maybe Stride’s search will be more powerful than that one of HipChat.  We’ll see.

Oh, and I’m guessing all the users will have to downloading and install new apps – for mobile, desktop, etc.  That’s yet another thing to do.

As I said, I haven’t tried Stride yet, and I hope it’ll be a huge improvement over HipChat, even though I HipChat worked great for me.  As I see it now, I think re-branding and the new design could have happened on the HipChat infrastructure.  Moving people to the new application altogether has to be justified by some major improvements.  And I’m not seeing anything major just yet.

The Minimally-nice Open Source Software Maintainer

Brian Anderson shares a few thoughts on how to appear as a minimally-nice Open Source Software maintainer.  Maintaining Open Source Software projects is a demanding job.  And the more popular the project is, the more demanding it is.  Brian shares the following practices that minimize the effort while you still maintaining a positive atmosphere for the project’s contributors:

In summary, do these things if you want to appear to be nice, and also if you want to actually be an effective open source software maintainer:

By consistently exhibiting a few simple behaviors, one can at least look like a kind and decent person. Maybe someday we all actually will be.

GitFlow considered harmful, and how we do it

I came across this rather strongly opinionated blog post – GitFlow considered harmful, and I have to say that I mostly agree with it.

In our company, we use a similar approach to the Anti-gitflow, but with even more simplicity.  This is one particular thing I like so much about git is that each person, team, or company can pick the workflow that suits them best.

Just to give you a little bit of context, we have a rather small development team (under 10 people), but we do a large number of projects.  All our projects are web-based, varying from small and simple websites (static HTML), through more complex WordPress sites (multilingual, e-commerce, etc), to business applications like CRMs.  Each project is done by several developers at a time and can later on be passed on to other developers, often much later (another iteration after several month).  Each developer is working on a number of projects at a time.  And we do very fast-paced development, often deploying multiple versions per day.  Given the nature of the projects and the development pace, we don’t ever really rollback.  Rollback is just another step (version) forward.  And we don’t have long and complex roadmaps in terms of which features will be released in which version.  It’s more of a constant review of what’s pending, what needs which resources, and what we can do right now.  (It’s far from ideal project management, but it somehow works for us.  If you think you can do better, send me your CV or LinkedIn profile, and we’ll talk.)

In our case, we do the following:

  • We have one eternal branch, and we call it master.
  • The master branch is always stable and deployable.  Even though we don’t really deploy it directly.
  • Nobody is allowed to commit directly to the master branch.  Initially it was just an agreed convention, but because people make mistakes, we now have this rule enforced with the technology.  Both BitBucket and GitHub support protected branches.  BitBucket, in my opinion, does it much better.
  • All new features, fixes, and improvements are developed in separate “feature” branches.  Most of these are branched off the master.  For large chunks of work, we can create a feature branch, and then introduce incremental changes to it via sub-feature branches, branched off the feature one.  This allows for easier code reviews – looking at a smaller set of changes, rather than a giant branch when it’s ready to be merged.
  • We do code review on everything.  The strongly suggested rule is that at least two other developers review the code before it is merged.  But sometimes, this is ignored, because either the changes are small and insignificant (CSS tweaks or content typos), or we are really in a hurry (we’ll review the changes later).  But whatever the case is, nobody is allowed to merge their own pull requests.  That is set in stone.  This guarantees that at least one other person looked at the changes before they were merged in.
  • We tag new versions only on the master branch.
  • We use semantic versioning for our tags.
  • We don’t deploy branches.  We deploy tags.  This helps with preventing untested/unexpected changes sneaking in between the review of the branch and the deployment.

The above process suits us pretty well.

Is group chat making you sweat?

Jason Fried has an excellent write-up on the pros and cons of using group chat for the team communications, and some of the ways to make it better. We use HipChat in the company and while it’s vital to our operations and I can’t even begin to think how we could do what we do without it, it does have some negative side effects – exactly as James describes them.

The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):

Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?

 

A Million Words Published at Work in a Remote Company

Sara Rosso shares some thoughts on what to document and share, after publishing over a 1,000,000 words while working at Automattic.  Here’s the gist of it:

  • If you’re the go-to person for something in your company, consider how much of it is just gatekeeper information you could document properly to help someone else learn/grow from or work on independently.
  • Separate out processes and historical background from your strategic expertise. Processes and backstory are not really ‘what you know.’ It’s much better to be a person someone asks ‘why’ or ‘when’ to do something vs. the logistics of a ‘how.’ How can and should be documented for others to build off of regardless of your involvement. This should free you up to be more involved in the why, the new, and the next of your work.
  • If you’re repeating yourself in private chats or (gasp!) email on a specific topic, document it. That’s also what drove me to create this blog – being able to answer someone’s question with an answer you’ve already carefully crafted for someone else is a great feeling (and a great use of your time)!
  • Will someone want to know why you decided or executed something a specific way later? Share as much background as possible so colleagues are brought up to speed immediately. Share the setup & thought process you went through, where to find more information, and even the facts, ideas, or information you considered but deemed outside of scope for the particular project. My goal is to hopefully never have someone ask “where did this come from?” or “what’s your source?” or “did you consider this?” (when I had) and instead focus on enriching the discussion or challenging my ideas vs. asking me for information I should have provided in the original post.
  • Gather the best, most complete, or authoritative things you’ve authored and submit them as potential onboarding materials for new team members. Challenge them to ask questions and to find something you need to document.
  • If important progress is made, be sure to update your documentation, or retire in favor of something newer or more complete. We do this by linking from old posts to new ones, and all it takes is a quick comment and a link on an old post.

Maintainers Don’t Scale

Daniel Vetter, one of the Linux kernel maintainers, shares some thoughts on why maintainers don’t scale, what it takes to do the job, what has changed recently and what needs to change in the future.

This reminded me of this infographic, which depicts a year (even though back in 2012 – probably much busier these days) for another kernel maintainer – Greg Kroah-Hartman.  Note that the number of emails does not include the messages on the Linux kernel mailing list (LKML), which is in its own category of busy:

The Linux kernel mailing list (LKML) is the main electronic mailing list for Linux kernel development, where the majority of the announcements, discussions, debates, and flame wars over the kernel take place. Many other mailing lists exist to discuss the different subsystems and ports of the Linux kernel, but LKML is the principal communication channel among Linux kernel developers. It is a very high-volume list, usually receiving about 1,000 messages each day, most of which are kernel code patches.

35 new ways to do your work right inside of HipChat

HipChat keeps extending the amazing list of integrations with other tools and services.  This blog post – 35 new ways to do your work right inside of HipChat – lists some of the recently added.  Included, among others, is even a multiplayer snake game.

HipSnake

 

Rocket.Chat – the ultimate self-hosted open source chat platform

Chat is becoming more and more important for team communication and collaboration (what is ChatOps?).  Old school applications like Skype are being replaced with modern, web-based chat platforms, that provide group/room and one-on-one chats, file uploads, screen sharing, voice and video communications, API integration and more.  There are plenty of solutions to choose from too.

Traditionally, self-hosted solutions were difficult to setup and maintain, and were lacking in integration options.  So many teams choose to go for the third-party hosted approach.  This is not very exciting for companies that deal with sensitive data though.

As mentioned before, at work, we are using HipChat.  It’s nice, it’s free, and it integrates nicely.  Lately, there has been a lot of hype about Slack, which I tried, but didn’t particularly like.

rocket.chat

Today, however, I came across a very nice option, which seems to be a breeze to self-host and maintain – Rocket.Chat.  It’s modern – written in JavaScript, it has a long list of features, and there is a vibrant community around it.

You can try the live demo, or deploy it to your infrastructure via a gadzillion different methods, or read the beautiful documentation.  And there’s a rumor of HipChat and Slack import tool, so you won’t have to start from scratch…

Let me know what you think.