Monday, January 26, 2015

Slack? An even better cross-team collaboration tool?

Two weeks ago, I talked about Flowdock, an online tool to aggregate multiple sources into a single environment where agile teams can work together. I also promised to look at an alternative service named Slack. When we introduced Flowdock, somewhere in November 2013, Slack was still in its very early stages. However, after one year, I decided to check it out once again…and it has changed, boy has it changed. But before I continue, let me quickly recap Flowdock's biggest pain points:

  • A separate inbox
  • No option for sending messages between flows.
  • No support for Markdown in technical discussions.
  • No support for SharePoint and OneNote URLs.
  • No per-flow notification settings
  • Unintuitive search functionality
  • No Windows Phone and Windows desktop versions.

So here's one of Slack's many views:

clip_image001

You will immediately notice that messages from external services such as Github or TeamCity appear inline with the remainder of the conversations. I'm not entirely satisfied with the look-and-feel and the noise created by the RSS feed, but I suspect the guys behind Slack will work on that soon enough. The right pane is used to either provide an overview of the members, your recent activity or mentions, starred items or uploaded files. What you can't see are the many user and team options, in particular on email, desktop and push notifications. Looking at the available integrations, those seem to be on par with Flowdock, but when you look a bit closer, you'll notice the maturity of those integrations. For instance, the GitHub integration options look like this:

clip_image002

But it's the little things that are causing Slack to feel so mature on many levels. For instance, those weird SharePoint and OneNote URLs are no issue as all. In fact, when you paste a URL, Slack will display the URL in the same fashion as Facebook does, including a nice little preview.

clip_image003


Posting a message to another channel (which is the Slack equivalent for a flow) is also a no-brainer, as well as using MarkDown to include nicely formatted code elements.

clip_image004

I can never find something back in Flowdock, so being able to use Outlook-style keywords is a big reliever.

clip_image005

Other notable features missing in Flowdock are the private discussions with more than one person and the micro-blogging platform that allows you to write little snippets of text with syntax highlighting as a starting point for a discussion.

clip_image006

So what's the catch here? Is it all shiny and new? No, definitely not, but it gets pretty close. The guys behind Slack are claiming they are working on it, but for now it lacks any kind of threaded discussions. After playing the please-use-the-reply-sergeant for over a year, I'm not willing to let go of that unique and essential feature.

clip_image007

Slack is a really promising, especially with them supposedly working on a Windows Phone and Windows 8 version as well. But for now, I’ll be sticking to Flowdock… 

Sunday, January 18, 2015

You don't know what you don't know

More or less since the start of my assignment at my current client, four years ago, we have had some form of a cross-team stand-up at 10:00 every day (often named Scrum-of-Scrums). But now that we have around 10 teams, we started to notice some issues lately. People joined too late or didn't even show up at all. And if they were there, some of them didn't share much or were clearly bored by the things people were sharing. Nothing is more painful than a few people standing in a circle, playing with their phones and picking their noses.

image

I found that pretty frustrating, especially since I really valued that stand-up. In my role as chief architect, I'm working mostly on technical projects and long-term architectural guidance. Only when teams have to complete architectural changes as part of bigger functional user stories, I get involved. So spending 10 minutes a day on hearing what people are doing is a great investment for me. The only other colleague who felt the same was our support and release manager with which I collaborate a lot, often on cross-team topics like these:

  • Detecting dependencies between teams on both architectural level as well as on release level
  • Detecting teams working on the same things or overlapping on certain aspects
  • Detecting problems one team has that we know the other has already solved or is solving
  • Detecting problems or challenges that we or somebody we know can solve
  • Hearing about some story we need to review to see if it aligns with the architectural vision
  • Pick opportunities to adapt or improve the development process

I had a hard time accepting that people wouldn't be as interested in this as me, so after consulting with our in-house agile coach, we decided to interview all scrum masters individually in the hopes of getting some usable feedback. In short, we asked them what kind of value they would like to get from that sync-up and what topics they would be interested in. Here's a summary of the topics people proposed.

  • Reminders on writing a blog post (which we use internally for sharing technical and functional changes) or blog posts that require special attention by certain teams
  • Reminders of upcoming deployments, unresolved support issues
  • Sharing something a team is working on
  • Upcoming code merges that they don’t realize might affect other teams
  • Upcoming process or development environment changes
  • General announcements, new hires, important client stuff
  • F#?k-up stories that you might mention for those that are interested
  • Experiments and outcomes that were done in a team
  • Successes and failures and what we learn from that
  • Discuss upcoming large and/or complex stories

Are you're noticing this at well? Those are a lot of great things to discuss. So apparently nobody had any real objections on the contents after all. They just wanted all participants to be sharing something rather than standing there with sheepish eyes. The biggest annoyance was caused by people not showing up (ironically by those exact same people). But what really reinforced my believe in the standup was a remark that one of the quality engineers made. She said "You don't know what you don't know". And with that she nailed the very purpose of a daily stand-up.

With that renewed insight we decided to reboot the standup with a very clear agenda (which we’ve put on the wall at our regular standup location), a reminder of the startup time, and explicit 'rules' on who should be there and what to do if he or she couldn't be there. Now each team shortly shares:

  • What problems worth mentioning happened yesterday
  • What large and/or important stories/epics they will be working on today
  • Which impediments exist they need help with

Next to that, we will always consider whether any of the following is worth mentioning

  • Upcoming merges, releases
  • Any blog posts or process changes worth emphasizing
  • Any f#?k-up stories to mention
  • Experiments and/or outcomes
  • Any successes and failures we can learn from?

We're just four weeks further, but I think it's working very well, especially after we decided to tune down the frequency to three stand-ups per week. Everybody has plenty to share and many dependencies and conflicts were detected since then. But are we done? Of course not. I'm pretty sure this isn't the last time we talked about this.

So what do you do to regularly align teams? Let me know by commenting below or tweeting me at @ddoomen.

Wednesday, January 14, 2015

The curious case of a deadlock in Autofac

It has been more than two years since we switched from Microsoft Unity to Autofac and we haven't regretted this a single day. Not only is the resolution performance much better than Unity, but it’s the feature set, in particular the relation types, that makes a world of difference. In terms of concurrency, there's not much to think about it. Autofac's concurrency model has been designed to be thread-safe from the ground up. In fact, there's only a single scenario in where you have to be careful what you do. And that's exactly where we went wrong…

The case this post is about involves the ContainerBuilder's fancy factory registration API. Consider the following statement.

1 var builder = new ContainerBuilder();
2 builder.Register<IQueryProcessor>(ctx => new QueryProcessor()).SingleInstance();
This tells Autofac that every time my code needs an instance of IQueryProcessor (either through a constructor or property dependency or through an explicit call to Resolve), it should return the same instance of QueryProcessor initialized with a particular storage option. So far so good, but imagine that my QueryProcessor class has a dependency on the imaginary ICachingStrategy abstraction that has been registered upfront. I can change my registration to this.
1 builder.Register<IQueryProcessor>(ctx =>
2 new QueryProcessor(ctx.Resolve<ICachingStrategy>())).SingleInstance();
The ctx variable gives me access to the container so that I can resolve any other dependencies from it. If you carefully read the concurrency section of Autofac's wiki, you'll notice that this ctx variable represents a temporary copy of the actual container. In other words, this container is only available during the invocation of the lambda expression. And that's exactly how Autofac manages to be so thread-safe. Any locking that would normally happen in the global container now happens in a local temporary container and will not affect any other resolutions, nor prevent reentrance.

Considering this temporary nature, the following might be very dangerous.
1 builder.Register<IQueryProcessor>(ctx => new QueryProcessor(ctx).SingleInstance();
Notice that I'm passing the ctx variable into the constructor. Now, it highly depends on what the constructor is doing here, but assume for now that it is storing that container reference in a private field and using that to resolve other dependencies at a much later stage. Didn't I just mention that we're dealing with a temporary container? Indeed. It's very likely that that resolution attempt will blow up in your face! So how do you fix this? Like this:
1 builder.Register<IQueryProcessor>(ctx =>
2 new QueryProcessor(ctx.Resolve<IComponentContext>()).SingleInstance();
Resolving the IComponentContext (Autofac's abstraction for a container) returns the actual global container that you can safely use at a later point of time. So to summarize, use the temporary container for resolving dependencies needed at construction time, but use the global container to resolve any run-time dependencies. Guess what we did wrong….

So what are your experiences with Autofac? Share them here or let me know by tweeting me at @ddoomen.

Sunday, January 11, 2015

How Flowdock helps you get better cross-team collaboration

Is your inbox also filling up with loads of emails all part of some kind of discussion where each reply contains the entire history again? Do you also get all kinds of notification emails from build servers, source control systems, and other things to which somebody is supposed to react? Do you often run into an email discussion that you think other people should see as well, but you’re not sure who to include?

Well, that's why we've been using Flowdock at my client since the beginning of 2014. It's a web-based collaboration tool that aggregates discussions and integrates with loads of online services. It’s a brilliant approach to cut down on email considerably. You can define different private and public flows per topic, can tag topics (like in twitter), refer to people using their handle and track discussions using the colored icons. Both my current client and my own employer Aviva Solutions use it, so I thought it would be sensible to use it for Fluent Assertions as well. The screenshot below shows my current dashboard.

clip_image001

On the left, you can see some of the discussions I had with Adam, one of the most active Fluent Assertions contributors ever. You can click on an message to see the discussion in isolation, which is particular useful for long running discussions. On the right hand side you can see the flow’s inbox with tweets related to this project, the build results from TeamCity, the MyGet package feed updates, GitHub commits and pull request and even the StackOverflow posts related to my project. For me, that’s an invaluable source of information, all combined in a single web page. And if no built-in integration exists, you can subscribe to RSS feeds as well or send tagged emails directly to the flow. Oh, and you can have discussions on inbox items as well. In fact, the Flowdock people wrote a nice post on how they abandoned email altogether. And did I mention first-class keyboard shortcuts?

At my current client, we use Flowdock with more than 120 people, but it took me a lot of persuasion and coaching-on-the-job to get people to use it properly. I believe tools like this are only going to work if you really try to use it as it was meant to. Although Flowdock will send you an email if you don’t respond to a discussion in which you are tagged, you need to get people to get used to start it in the morning. But the people that made an effort are really happy. It just takes a single discussion in which they get a brilliant response from a colleague they wouldn't even consider to include in the traditional email they used to send.

So is my search for the ideal collaboration tool over? No, of course not. I wouldn’t call this blog The Continuous Improver if I weren't keeping my eyes open for something better. So what's the pain right now?

  • I don’t like the inbox model as a separate flow. It tends to get ignored and causes nobody to really care about its contents. 
  • Sometimes I'd like to send a message to another team's flow. Currently I have to join that flow first, which is not always desired or possible, especially if the flow is private.
  • No support for Markdown in technical discussions, although it does support fixed-font formatting of code blocks.
  • It doesn't properly handle SharePoint and OneNote URLs. You could blame Microsoft here for using non-standard URLs, but the fact of the matter is that a lot of companies are using those products.
  • No per-flow notification settings (e.g. when to receive emails and from which flow)
  • The search functionality became very unintuitive after the UI redesign last summer
  • No Windows Phone app (not even an unofficial app) and no Windows desktop version. We're currently running Flowdock as a Chrome Application, but that’s not quite it.

So although Flowdock is an essential product in our agile project, and I couldn't imagine working without it, I was expecting more innovation. Slack for instance, has gone through a huge growth spurt in a single year and feels very mature. I'm currently trying it out and it looks pretty promising. But that’s going to be another post…

So what tools are you using for (cross-)team collaboration? Let me know by commenting below or tweeting me at @ddoomen.

Friday, August 15, 2014

The C# Coding Guidelines are now open-source!

The ability for an organisation to request the original Microsoft Word files and adapt them for internal use has always been an important recommendation of the C# Coding Guidelines. Since I first published the PDFs on CodePlex in 2009, I have received numerous requests for that, but the process has always been a bit cumbersome. Hence my decision to convert the guidelines into MarkDown and to push them to a new GitHub repository.

The corresponding license, based on one of the template licenses provided by Creative Commons, allows you to fork, adapt and distribute that modified version within your organization as long as you refer back to the original version on GitHub. It's not required, but you would make me a very happy man if you credit me as the original author. And if you have any great ideas, recommendations or corrections, either submit an issue, or even better, fork the repository and provide me with a pull request.

Notice that I decided to use some of the features provided by Markdown Extra because that allows me a bit more control on the generated PDF that I will ultimately publish back on the current landing page on CodePlex. I know that GitHub will not render everything correctly and page breaking in the generated PDF sucks, but that's the closest I could get to the original version.
Some of the things I'm planning or considering:
  • Splitting the guidelines into two separate documents; one on coding practices and one on design practices.
  • Introducing some of the guidelines proposed by Object Calisthenics.
  • To setup a new landing page through GitHub's pages and drop CodePlex completely.
  • Convert the cheatsheet into a Markdown file.
  • Start evaluating the new C# 6.0 language features.
  • Update the proposed Static Code Analysis rule sets for Visual Studio 2012 and 2013.
  • Verify the ReSharper style sets
  • Evaluate ReSharper's pattern matching expressions to see if they can be used to detect a part of the guidelines. 
So if you have any ideas, go fork my repository and send me some nice pull requests…