Monthly Archives: September 2017

Software development

Motivation for async/await in C#

9 Comments

Introduction

In .NET 4.5, the async and await keywords were introduced. They are now a welcome and ubiquitous part of the .NET developer’s toolkit. However, I often run into developers who are not familiar with this concept, and I have had to explain async/await many times. Thus, I felt it would make sense to write up this explanation so that it can be accessible to all.

async/await is really just syntactic sugar for task continuations, but it makes asynchronous, I/O-bound code very elegant to work with. In fact, it is so popular that it has been spreading to other languages such as JavaScript.

As far as I can remember, async/await was introduced mainly to facilitate building Windows Phone applications. Unlike desktop applications, Windows Phone had introduced a hard limit in which no method could block for more than 50ms. Thus it was no longer possible for developers to resort to blocking their UI, and the need arose to use asynchronous paradigms, for which tasks are a very powerful, but sometimes tedious, option. async/await makes asynchronous code look almost identical to synchronous code.

In this article, I will not go into detail about using Tasks in .NET (which deserves a whole series of articles in itself), but I will give a very basic explanation on how to use them for asynchronous processing. More advanced usage is left for future articles.

Sidenote: Rejoice, for this is the 200th article published on Gigi Labs!

Motivation

Although async/await can be used in all sorts of applications, I like to use WPF applications to show why it’s important. You don’t need to know WPF for this; just follow along.

Let’s create a new WPF application, and simply drag a button from the Toolbox onto the WPF window:

Double-clicking that button will cause a click event handler to be generated in the codebehind class (MainWindow.xaml.cs):

        private void Button_Click(object sender, RoutedEventArgs e)
        {

        }

Now, let’s be evil and toss a Thread.Sleep() in there:

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            Thread.Sleep(15000);
        }

Run the application without debugging (Ctrl+F5) and click the button. Try to interact with the window (e.g. drag it around). What happens?

The UI is completely frozen; you can’t click the button again, drag the window, or close it. That’s because we’ve done something very, very stupid. We have blocked the application’s UI thread.

Let us now replace the Thread.Sleep() with this Task.Delay() instead (notice there is also that async in the method signature, and it’s important):

        private async void Button_Click(object sender, RoutedEventArgs e)
        {
            await Task.Delay(15000);
        }

If you run the application now, you’ll find that you can interact with the window after clicking the button, even though the code appears to be doing practically the same thing as before. So what changed?


Image taken from: Asynchronous Programming with Async and Await (C# and Visual Basic)

The way control flow works with async/await is explained in detail on MSDN, but it may feel a little overwhelming if you’re learning this the first time. Essentially, to understand what is happening, we need to break that await Task.Delay(15000) line into the following steps:

  1. Task.Delay(15000) executes, returning a Task representing it. It does not block since it does not necessarily execute on the same thread.
  2. Because of the await, execution of the remainder of the method is temporarily suspended. In terms of method execution, it’s as if we’re blocking.
  3. Eventually, the Task finishes executing. The await part is fulfilled, and the remainder of the method can resume execution.

async/await with HttpClient

Using a simple delay is a nice way to get an initial feel of async/await, but it is also not very realistic. async/await works best when you are dealing with I/O requests such as sockets, databases, NoSQL storage, files, REST, etc. To this effect, let’s adapt our example to use an HttpClient.

First, let’s install the following package via NuGet:

Install-Package Microsoft.Net.Http

We’re going to repeat the same experiment as before: first we’ll do a silly blocking implementation, and then we’ll make it asynchronous.

Let’s work with this code that gets the response from the Google homepage:

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            var baseAddress = new Uri("http://www.google.com");

            using (var httpClient = new HttpClient() { BaseAddress = baseAddress })
            {
                var response = httpClient.GetAsync("/").Result;
                var content = response.Content.ReadAsStringAsync().Result;
            }
        }

If we run this and click the button, the window blocks for a fraction of a second, and we get back the HTML from Google:

Google has a very fast response time, so it is a poor example for visualising the problems of blocking code in a UI. Instead, let’s use a website that takes a very long time to load. One that I’ve written about before is that of the Malta Tourism Authority, which takes over 20 seconds to load. Let’s change our base address in the code:

            var baseAddress = new Uri("http://mta.com.mt");

If you run the application now and click the button, you’ll see that it will be stuck for a fairly long time, just like before. We can sort this out by making the request asynchronous. To do that, we replace each .Result property with an await. In order to use await, we have to mark the method as async. In order to get a notification when the response actually comes back, I’ll also toss in a message box:

        private async void Button_Click(object sender, RoutedEventArgs e)
        {
            var baseAddress = new Uri("http://mta.com.mt");

            using (var httpClient = new HttpClient() { BaseAddress = baseAddress })
            {
                var response = await httpClient.GetAsync("/");
                var content = await response.Content.ReadAsStringAsync();

                MessageBox.Show("Response arrived!", "Slow website");
            }
        }

Run the application and click the button. You can interact with the window while the request is processed, and when the response comes back, you’ll get a notification:

If you put a breakpoint and follow along line by line, you’ll see that everything happens sequentially: the content line will not execute before the response has arrived. So async/await is really just giving us the means to make asynchronous code look very similar to normal sequential execution logic, hiding the underlying complexities. However, as we’ll see in later articles, it is also possible to use this abstraction for more powerful scenarios such as parallel task execution.

The Importance of Asynchronous Code

While I have not really explained how to work with async/await in any reasonable depth yet, the importance should now be evident: making I/O calls asynchronous means that your thread does not need to block, and can be freed to do other work. While this has a great impact on user experience in GUI applications, it is also fundamental in other applications such as APIs. Under high load, it is possible to end up with thread starvation when blocking, because all threads are stuck waiting for I/O, when they could otherwise be processing requests.

For pure asynchronous code, blocking isn’t actually ever necessary. When an I/O request such as HttpClient.GetAsync() is fired, .NET uses something called I/O Completion Ports (IOCP) which can monitor incoming I/O and trigger the caller to resume when ready.

We have merely scratched the surface here. There is a lot to be said about async/await, and likewise there are a lot of pitfalls that one must be made aware of. This article has shown why asynchronous code is important, and future articles may cover different aspects in more detail.

Software development

The Adapter Design Pattern for DTOs in C#

5 Comments

In this article, we discuss the Adapter design pattern, which is part of the book “Design Patterns: Elements of Reusable Object-Oriented Software” by Gamma et al. (also known as the Gang of Four).

We will discuss the motivation for this design pattern (including common misconceptions) and see a number of different ways in which this pattern is implemented in C#.

TL;DR Use extension methods for your mapping code.

Defining the Interface of a Class

The above book summaries the Adapter pattern thusly:

“Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.”

It is fundamental to interpret this description in the context in which it was written. The book was published in 1994, before Java and similar languages even existed (in fact, the examples are in C++). Back then, “the interface of a class” simply meant its public API, to which extent “client code” could use it. C++ has no formal interface construct as in C# and Java, and the degree of encapsulation is dictated as a result of what the class exposes publicly. Note that a class’s interface is not restricted to its public methods alone; C++ also offers other devices external to the class itself, and so does C# (extension methods, for instance).

Given today’s languages where interfaces are formal language constructs, such an interpretation has mostly been forgotten. For instance, the 2013 MSDN Magazine article “The Adapter Pattern in the .NET Framework” illustrates the Adapter design pattern in terms of C# interfaces, but it slightly misses the point. We can discuss the Adapter pattern without referring to C# interfaces at all, and instead focus on Data Transfer Objects (DTOs). DTOs are simply lightweight classes used to carry data, often between remote applications.

An Example Scenario

Let’s say we have this third party class with a single method:

    public class PersonRepository
    {
        public void AddPerson(Person person)
        {
            // implementation goes here
        }
    }

The interface of this class consists of the single AddPerson() method, but the Person class that it expects as a parameter is also part of that interface. There is no way that the third party could give us the PersonRepository (e.g. via a NuGet package) without also including the Person class.

It is often the case that we may have a different Person class of our own (we’ll call it OurPerson), but we can’t pass it to AddPerson(), because it expects its own Person class:

    public class Person // third party class
    {
        public string FullName { get; set; }

        public Person(string fullName)
        {
            this.FullName = fullName;
        }
    }

    public class OurPerson // our class
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public OurPerson(string firstName, string lastName)
        {
            FirstName = firstName;
            LastName = lastName;
        }
    }

Thus, we need a way to transform an OurPerson instance into a Person. For that, we need an Adapter. Next, we’ll go through a few ways in which we can implement this.

Constructor Adapter

One way of creating a Person from an OurPerson is to add a constructor in Person which handles the conversion:

    public class Person // third party class
    {
        public string FullName { get; set; }

        public Person(string fullName)
        {
            this.FullName = fullName;
        }

        public Person(OurPerson ourPerson)
        {
            this.FullName = $"{ourPerson.FirstName} {ourPerson.LastName}";
        }
    }

It is not hard to see why this is a really bad idea. It forces Person to have a direct dependency on OurPerson, so anyone shipping PersonRepository would now need to ship an additional class that may be domain-specific and might not belong in this context. Even worse, this is not possible to achieve if the Person class belongs to a third party and we are not able to modify it.

Wrapper

Another approach (which the aforementioned book describes) is to implement OurPerson in terms of Person. This can be done by subclassing, if the third party class allows it:

    public class OurPerson : Person // our class
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public OurPerson(string firstName, string lastName)
            : base($"{firstName} {lastName}")
        {
            FirstName = firstName;
            LastName = lastName;
        }
    }

Where C# interfaces are involved, an alternative approach to inheritance is composition. OurPerson could contain a Person instance and expose the necessary methods and properties to implement its interface.

The disadvantage of either of these two approaches is that they make OurPerson dependent on Person, which is the opposite of the problem we have seen in the previous approach. This dependency would be carried to wherever OurPerson is used.

Especially when dealing with third party libraries, it is usually best to map their data onto our own objects. Any changes to the third party classes will thus have limited impact in our domain.

AutoMapper

A lot of people love to use AutoMapper for mapping DTOs. It is particularly useful if the source and destination classes are practically identical in terms of properties. If they’re not, you’ll have to do a fair amount of configuration to tell AutoMapper how to construct the destination properties from the data in the source.

Personally, I’m not a fan of AutoMapper, for the following reasons:

  • The mapping occurs dynamically at runtime. Thus, as the DTOs evolve, you will potentially have runtime errors in production. I prefer to catch such issues at compile-time.
  • Writing AutoMapper configuration can get very tedious and unreadable, often more so than it would take to map DTOs’ properties manually.
  • You can’t do anything asynchronous in AutoMapper configuration. While this may sound bizarre, I’ve needed this in the past due to terrible DTOs provided by a third party provider.

Standalone Adapter

The aforementioned MSDN Magazine article simply uses a separate class to convert from source to destination. Applied to our example, this could look like this:

    public class PersonAdapter
    {
        public Person ConvertToPerson(OurPerson person)
        {
            return new Person($"{person.FirstName} {person.LastName}");
        }
    }

We may then imagine its usage as such:

            var ourPerson = new OurPerson("Chuck", "Berry");
            var adapter = new PersonAdapter();
            var person = adapter.ConvertToPerson(ourPerson);

This approach is valid, and does not couple the DTOs together, but it is a little tedious in that you may have to create a lot of adapter classes, and subsequently create instances whenever you want to use them. You can mitigate this a little by making them static.

Extension Methods

A slight but very elegant improvement over the previous approach is to put mapping code into extension methods.

    public static class OurPersonExtensions
    {
        public static Person ToPerson(this OurPerson person)
        {
            return new Person($"{person.FirstName} {person.LastName}");
        }
    }

The usage is very clean, making it look like the conversion operation is part of the interface of the class:

            var ourPerson = new OurPerson("Chuck", "Berry");
            var person = ourPerson.ToPerson();

This works just as well if you’ve converting from a third party object onto your own class, since extension methods can be used to append functionality even to classes over which you have no control.

Summary

There are many ways to apply the Adapter design pattern in mapping DTOs. Extension methods are the best approach I’ve come across for C# because:

  • They don’t couple the source and destination DTOs.
  • The conversion occurs at compile time, so any repercussions of changes to the DTOs will be caught early.
  • They can easily be used to append functionality even to third party classes for which the source code is not available.

The Adapter design pattern has little to do with interfaces as a formal OOP language construct. Instead, it deals with “the interface of a class”, which is embodied by whatever it exposes publicly. The Adapter design pattern provides a means to work with that interface by converting incompatible objects to ones that satisfy its contract.

Rants

On Stack Overflow

6 Comments

I love Stack Overflow. As a software developer, I think it is one of the most important and useful resources ever made, helping me quickly resolve countless issues in my work and side projects.

I also hate it with a passion, and think it can be a royal pain in the ass. My main reasons for this stem from the community, especially those with moderation powers, being made up of a bunch of kids (not necessarily in the physical sense) who are addicted to the gamification system and will do anything to ramp up their reputation.

Given that I ask about as many questions as I answer, the result was that I have seen many of my legitimate questions closed and/or downvoted for various reasons such as “not constructive” or “duplicate”. Many times, the people casting such judgement would not actually understand the question.

One of my biggest frustrations with the site came when I asked the question “Task.Factory.FromAsync with CancellationTokenSource“. A troll with very high reputation (read: mod_powers++) marked this question as a duplicate of another question which had nothing to do with mine. When I challenged him, he went as far as to edit the unrelated question such that it did answer my question. He actually admitted this in the comments to my question (which have by now been cleaned up by moderators after I reported the matter, but I have conveniently kept screenshots), and even asked me to offer a bounty so that he could get more points:

As a regular user of Stack Overflow, I was highly put off at not being able to ask any reasonable question without it being closed down.

Answering questions is just as frustrating. Typically, when a question is asked, a barrage of short, two-sentence answers will appear. These will be progressively edited into better answers, but as long as they can get something in initially, they will start accumulating points. This is a common tactic and discourages spending the time to write well-thought answers for relatively little reward. Not that I believe that the reward system is more important than the quality of the questions and answers. But alas, many people do, and that is the reason for this sort of phenomenon.

And you can tell that something is really messed up when you get entire courses, such as this 6-hour Pluralsight course, explaining how to use something that is supposed to be a Q&A site.

But in fact, what I am describing is nothing new, and has been going on for many years. In fact, around 2013, Michael Richter wrote a very informative post about the problems plaguing Stack Overflow. It has disappeared from its original location, but can still be read (along with around a couple of weeks’ worth of comments) thanks to the Internet Archive.

I am reproducing Mr. Richter’s article below for ease of future reference. Aside from the issues with Stack Overflow, I would also like to emphasise the story around his “goto” answer, which reverberates a problem I encounter extremely regularly with developers being too religious about what they have been taught, and not using their head to adequately reason about techniques in the particular context they need.

Update 1st June 2019: “Why StackOverflow sucks” is another interesting example of moderator abuse on the site.

Without further ado…

“Why I no longer contribute to StackOverflow” by Michael Richter

I was active in the StackOverflow (and the broader Stack Exchange) community for a while. I no longer am. Here’s why.

Introduction

I have an account at StackOverflow. Follow the link and check out a few stats:

  • I’ve been a member for almost four years at the time I’m writing this.
  • I’ve scored over 14,000 points in their gaming system.
  • I’m in the top 3% of their contributors overall as of this writing.

I point this out not to brag but to make sure it’s clear that I’m not writing this because of “sour grapes” or because I’m not getting the recognition I think I deserve. Indeed, to be blunt, I’m getting way too much recognition, but more on that below.

Overview

If you’re a software developer of any kind, and if you haven’t been sleeping under a rock, you know of Joel Spolsky and Jeff Atwood’s StackOverflow (and broader StackExchange ecosystem). For the rest of you, allow me to lift up your rock a little and explain what the site is.

In brief, you ask questions related to programming and other people answer them. The site is “gamified” (what an utterly horrendous neologism, that!) so you score points for asking questions that get voted up, answering questions and getting voted up, for doing book-keeping tasks and a variety of other things. You can also earn “badges” (gold, silver and bronze) for accomplishing certain things.

The intent of the system is to provide some form of recognition for people who help others with software development problems. It sounds innocuous, but in the end I find it vaguely distasteful and off-putting.

I’ve been asked more than a few times now why I think this, so today I will commit my explanations in writing once so I can just point to this page instead of repeatedly saying the same thing.

The problems

The problems I see with StackOverflow are summarized in this list:

  1. Poor pedagogy
  2. Poor reward system
  3. Poor community

I’m willing to engage in discussion of any of these flaws. Comments are turned on for this post. They are, however, moderated so if you plan to simply spew bile at someone who dares say bad things about a site you like you:

  • won’t get your 15 seconds of Innarwebs Fame™®;
  • will add to this counter of people who contribute to point #3 above: count so far: 6

Poor pedagogy

As an educator, I find the StackOverflow approach to “helping” people unproductive and contrary to any kind of real learning. For illustration, go back and take a look at my profile. Specifically take a look at the tags tab. See the #1 tag there? Java. Most of my answers (and most of my points) come from Java-related questions.

Now comes a confession.

I’m not a Java programmer. I’ve only ever briefly programmed in Java professionally. I hated the experience and I hate the language. I certainly don’t consider myself a Java expert. Yet I managed to get the bulk of my points from Java. How is this possible?

It’s possible because I did what many of the people whose questions I answered (and got points for) should have done for themselves: I saw a simple Java question, hit Google, read briefly, then synthesized an original answer.

There’s an old cliché in English: give a man a fish, he eats for a day; teach a man to fish, he eats for a lifetime. StackOverflow is filled to the brim with people giving fishes. The people asking are learning nothing useful beyond the shortest of the short terms and the people teaching are not helping in any but the most trivial of ways. In the long term, I submit, StackOverflow is probably holding back the development of programmers (and thus the entire field of programming).

Poor reward system

Incidentally, my #2 tag is C++. There was a time I would cheerfully have called myself a C++ expert. These days I still likely know more about the language than most people working in it, but I have, if it’s at all possible, an even deeper abiding hatred of the language than I do for Java.

So why, if I hate Java and C++ (and several other languages that score well on my tags list), do I bother answering questions on those topics? This is because of the second problem I have with StackOverflow: the reward system is ludicrously designed.

The high school “cool kids table”

The very nature of StackOverflow’s structure has it such that only those who answer simple questions of the most popular programming languages will get a reward. To illustrate this, look at the difference between this Java-related answer and this non-Java one.

The Java answer scored me 460 and took me probably under a minute to write. The one about operating systems scored me 60 points and likely took about fifteen minutes to write.

If you’re going for points (and that’s the entire raison d’être for gamification!), are you going to waste time like that for 60 points when you could fit in a dozen 460-point answers? Of course not! You’re going to go wherever the points are, And the points are the low-hanging fruit of trivial questions from popular languages. The way StackOverflow is structured rewards people who put as little work as possible across as many simple questions as possible within only the most popular segments. Spending thought (and thus time) on answers interferes with points- and badge-mongering. Answering questions outside of the top ten languages similarly interferes.

This “cool kids table” problem has a very real effect. Look again at my profile. 218 answers. 10 questions. Why is this? I could arrogantly claim that this is because I know more than everybody else, but the real reason is that getting answers on any question that requires thought is a non-starter. As my approach to scoring points (Google + hasty rewrite) shows, I’m quite adept at answering trivial questions myself. For a prime example of the problem, consider this question. It got five answers (one of which you probably can’t see), only one of which even really answered part of the question. Why? Because answering the whole question would have taken a lot more work than most people in StackOverflow would be willing to put in. There’s just no percentage in spending time on difficult questions when you can hoover up a cool thousand points in a fraction of the time.

Broken scoring

Even if the “cool kids table” wasn’t an issue at StackOverflow, the system is still largely broken. Remember how I have over 14,000 points as of this writing? Two years and a bit ago, when I decided to stop participating in StackOverflow, this was not the case. I was “only” at OVER NINE THOUSAND! and several hundred points shy of getting moderator status. In well over two years I have contributed nothing to StackOverflow: no questions, no answers, nothing. (Well, that’s not true. When my score went over 10,000 I tried out the moderator powers for a couple of edits, just to test them out.) Over one third of my reputation was “earned” from me doing absolutely nothing for over two years. Indeed I went from the top 4% of contributors at my time of departure to the top 3%, despite, you know, me not doing anything.

Any scoring system that allows this to happen is simply broken in my opinion.

Poor community

And now my reputation score will go down!

Petty children

As of this writing my score was, as mentioned above, over 14,000. (14,076 to be precise.) I predict that this is going to go down as more people find out about this blog entry and start voting down my questions and answers in petty revenge. How do I know? I’ve been on the receiving end of sudden bouts of negative votes before. Consider this question about ‘goto’ constructs, for example. As of this writing it has 72 up votes and 13 down votes. It is simultaneously one of my most popular answers as well as one of my most hated ones.

The people who hated it weren’t content, however, with merely voting it down. No, after I posted that answer I had a mysterious downward turn in my reputation as downvotes appeared all over my answers. People got so upset at my mocking one of the Holy of Holies of computing that it wasn’t enough to just downvote the answer, they had to punish me. (Their selected means of punishment was as highly amusing as it was highly ineffective.) This is not the way a community of mature users acts.

Creeping authoritarianism

That kind of behaviour is, of course, inevitable in any kind of Innarwebs™® interaction. Pseudo-anonymity makes doorknobs of otherwise-normal people. There is something else, however, in the whole Stack Exchange hierarchy that bugs me: the creeping authoritarianism.

The “flavour” of StackOverflow today is entirely different than the flavour it had when I started. When I started the community as a whole still had a bit of a sense of humour. Sure sometimes questions and/or answers would be a bit off-topic or a bit irreverent, but it gave more of a community feel that way, even if it was on occasion less-than-“professional”.

This changed slowly but surely in the way that all “community moderated” things change. Here is the recipe that all such “community-driven” approaches almost, but not quite, invariably follow:

  1. A wide-open community based on “merit” is built.
  2. The community gets a kernel of users who build up “merit” by virtue of, basically, being obsessive twerps.
  3. As this kernel of “serious” users builds up its influence, they start to modify what the standards of the community are to match their own desires.
  4. These standards get enforced on other members of the community who lack sufficient “merit” (read: who have a life outside the site) to fight back.
  5. The tenor of the community changes to match the notions of the obsessive, but “meritous” minority.
  6. Lather. Rinse. Repeat.

This happened at Wikipedia and it’s happened at StackOverflow. StackOverflow was once fun. It is no longer. StackOverflow once had a tolerance for things a little outside of the norm. It does no longer.

Take a look at the site now. Some of the most popular questions and/or answers are now locked down and only kept for “historical reasons”. Consider this answer. It’s likely the best-known and most-loved answer on the entire damned site! It’s funny and it’s informative. But it’s something that makes the current powers-that-be at the site crazy and thus it is locked and we have this ominous note appended: “This post has been locked while disputes about its content are being resolved.”

What. The. Fuck!?

TL;DR

There are a number of reasons why I stopped contributing to StackOverflow. I am disquieted by its poor pedagogical value, I think its scoring system is fundamentally broken and rewards the wrong things, and I think its community lacks maturity even while it becomes more and more pointlessly authoritarian. So what would I recommend as an alternative?

How about learning? You know, that thing that puts information in your head that you can apply later at need. Use Google. Use Wikipedia (if you must). Use RosettaCode for code examples. (Contribute there too!) Engage with other users of the tools you use in the form of user groups, mailing lists, web forums, etc. Learn foundational principles instead of answers to immediate questions.

Management, Rants

On Daily Standup Meetings

6 Comments

Agile development methodologies such as Scrum, Kanban and XP have taken the software development industry by storm. By now, most companies have drunk the kool-aid – first the decision-makers, then the developers – and follow it with a manner of religious zeal.

It seems like this exciting new “agile” way of working has made traditional hierarchical management and reporting lines obsolete. Agile has by now entrenched itself deeply within the fabric of software companies, and it seems like we’ve forgotten the old ways.

We are now faced with the conflict of fixed-backlog sprints and shifting requirements, burndown charts that never converge, armies of full-time scrum masters babysitting developers to death, and the progression (or regression) of the Daily Scrum into… the Daily Standup Meeting.

While I understand this article may be controversial and may touch a nerve in a large number of people, I find it much more important to work efficiently and to challenge harmful norms than to mindlessly conform to them. My hope is that at least some people might read this article with an open mind, break out of their stupor, and start questioning these established practices. In order to improve, it is necessary to first acknowledge problems, and then take active steps towards addressing them.

What is the Daily Standup Meeting?

Image credit: taken from here

The Daily Standup Meeting is a “ritual” (quoting Jason Yip’s comprehensive article on the topic) in which the development team (and possibly other stakeholders) gathers to report on the progress of each individual member. They must in turn answer three questions:

  • What did you do yesterday?
  • What are you going to do today?
  • Are there any obstacles hindering your progress?

Let’s take a look at the meaning of each word, aside from “Meeting” which is obvious enough. As a “Daily” meeting, this happens routinely every day at a specific time. All those involved must stop what they are doing and participate, whether it is productive or not.

What I have just described is nothing new: I have participated in Daily Scrum meetings of this nature for years, and I’m pretty sure this goes back much father than my personal experience can account for.

A more recent twist, though, is the Daily “Standup” Meeting. The idea is to force people to stand up in order to keep meetings short, by having the physical discomfort as a disincentive to letting the meetings drag on unnecessarily.

Standing Up

This factor, on its own, speaks volumes. Rather than solving the problem of pointless meetings that are a complete waste of time, we choose to make people feel uncomfortable in the hope that the meetings will be kept short.

The first problem with this is how ridiculous and humiliating it is. Not even in church are you obliged to stand up, and perhaps at school there may have been instances where some posture was enforced in punishment (a practice that is probably considered barbaric by today’s standards).

But no. We are fully grown adults, who have been working for several years in the industry, and there is a perfectly comfortable sofa behind us, but we cannot use it, under pain of menacing glares from everybody in the room.

This also has no regard for any physical issues that the participants may be undergoing that may make this practice more uncomfortable than for the average human being. Such people should not have to disclose their personal problems to the team in order to waive the enforcement of a certain posture on the job, something that nobody has the right to enforce in the first place.

The second problem is that, well, it doesn’t work. Standing up or not, the tendency to ramble on is a lot more powerful than the discomfort (which most people can just as well get used to). Which brings us to the next section.

Excessively Long Standups

Do you remember what we’re supposed to do in standups? Basically, answer the following three questions, and then get on with our work:

  • What did you do yesterday?
  • What are you going to do today?
  • Are there any obstacles hindering your progress?

It is much harder than you would think, to stick to the plan. Despite having been brainwashed into enthusiastic and excited participation in this drudgery, people’s overexcitement tends to take over. There are many different scenarios which result in deviation from this template, and in turn cause Daily Standup Meetings to drag on. These are just a few of the most common I’ve encountered:

  • People want to justify their job and show that they are doing something, so they read out a whole list of every little detail they worked on since the last Daily Standup Meeting.
  • Stakeholders ask a lot of questions to the development team. They have a right to be answered, but the Daily Standup Meeting is not the right place.
  • Developers going off on a tangent and having a technical (or other) discussion between two or three people, but keeping everyone in the room.
  • Lots of people in the room, so it takes a while to go through what everyone has to report. This is mainly a problem when developer teams are large, but it can also be a result of participation of a lot of stakeholders who join the Standup. With 20 people in the room, it’s hard to keep meetings efficient.

Broadcasting Information

The format of the Daily Standup Meeting is such that the development team and any other stakeholders are present (whether physically or otherwise). It allows everybody in the room to be kept up to date with progress (in theory) and to be able to help remove any obstacles (again, in theory).

Personally, I believe that this is one of those cases where too much transparency is a bad thing. The main reason for this is that there is no reason why each person should need to broadcast their progress to so many people in the room. Typically, you work with one or two direct colleagues, and report to your manager. There is no need to keep a whole crowd in the loop.

Rather than focusing on what each of us needs to do, we instead feel the urge to get involved in what the whole team is up to. A consequence of this is that it becomes necessary to involve everybody in the team in order to take the slightest technical decision, which is really the opposite of the empowerment that should be enabled by giving developers such autonomy.

In practice, keeping everyone on the team updated has no real benefit. They may know you’re working on something, but they would not understand the business or technical decisions, and as a result, they would not be able to take up the task you are working on, in your absence.

Another problem is the direct access to the development team from higher-up stakeholders. Part of a manager’s job is to manage expectations, both to his superiors and to his subordinates. And yet, higher-level stakeholders and members now suddenly have full access to the fine details of what the development team is working on.

A real problem here is when members of the development team are cornered into publicly answering uncomfortable questions, possibly by external stakeholders or maybe even by members of their own team. Such things should really go through a manager or scrum master rather than being laid out in a public shit show. It is not uncommon for such meetings to degrade into blame games.

Even in the absence of such situations, it is often uncomfortable for developers to speak (let alone report their progress) in front of a small crowd, even if it consists of their own direct colleagues. While the stereotype of anti-social developers may be questionable, in my experience I have observed that most developers feel intimidated when speaking in front of people, just as they feel uncomfortable when someone (even a direct colleague) sits next to them while they work. It is thus quite easy for developers to go on the defensive if challenged about their work during the Daily Standup Meeting.

And this, of course, is something that should be completely avoided. As any manager worth his salt would know, you should never, ever reprimand someone in front of other people. This is also a fundamental flaw of retrospective meetings, although that is beyond the scope of this article.

Finally, the routine of the Daily Standup Meeting makes it convenient for people to provide updates and feedback during the meeting itself, rather than spontaneously as needed. Communication should be spontaneous and immediate; that is what keeps things efficient.

A trend I have seen is for companies with poor communication to turn to agile ceremonies to try to resolve the problem. Little do they realise that they are making it worse by adding more ritual baggage and introducing more middlemen. There is no substitute for real and effective communication.

What Alternative is There?

Honestly, what was so terrible about the good old system of hierarchical reporting lines? Think about it:

  • You talk directly to your manager when you’ve finished your work and need to work on something new.
  • Your manager can ping you periodically for progress, but otherwise you can focus on your work.
  • If there are impediments, the manager can bring the right people on board.
  • If you need to talk to some direct colleagues (e.g. to integrate with their API), just do so. No need to have the whole team in a meeting for that.
  • Requirements and other outside interferences go through the manager first.
  • Feedback and criticism take place one-on-one with the manager.
  • Each manager reports to their manager. No need for crowds.

That just about solves all the problems I’ve described earlier: notice the contrast of involving only the people who are necessary, as opposed to everyone. The important factors to make this work are having a manager who is organised and has excellent people skills, and that everybody on the team is able to communicate efficiently and effectively.

Agile methodologies will remain a reality for many years to come. But are they really an improvement?

Update 11th September 2017: Here are some reactions to this article on social media (might require login):

Software development

RabbitMQ: Who Creates the Queues and Exchanges?

12 Comments

Messaging is a fundamental part of any distributed architecture. It allows a publisher to send a message to any number of consumers, without having to know anything about them. This is great for truly asynchronous and decoupled communications.

The above diagram shows a very basic but typical setup you would see when using RabbitMQ. A publisher publishes a message onto an exchange. The exchange handles the logic of routing the message to the queues that are bound to it. For instance, if it is a fanout exchange, then a copy of the same message would be duplicated and placed on each queue. A consumer can then read messages from a queue and process them.

An important assumption for this setup to work is that when publishers and consumers are run, all this RabbitMQ infrastructure (i.e. the queues, exchanges and bindings) must already exist. A publisher would not be able to publish to an exchange that does not exist, and neither could a consumer take messages from an inexistent queue.

Thus, it is not unreasonable to have publishers and/or consumers create the queues, exchanges and bindings they need before beginning to send and receive messages. Let’s take a look at how this may be done, and the implications of each approach.

1. Split Responsibility

To have publishers and consumers fully decoupled from each other, ideally the publisher should know only about the exchange (not the queues), and the consumers should know only about the queues (not the exchange). The bindings are the glue between the exchange and the queues.

One possible approach could be to have the publisher handle the creation of the exchange, and consumers create the queues they need and bind them to the exchange. This has the advantage of decoupling: as new queues are needed, the consumers that need them will simply create and bind them as needed, without the publisher needing to know anything about them. It is not fully decoupled though, as the consumers must know the exchange in order to bind to it.

On the other hand, there is a very real danger of losing messages. If the publisher is deployed before any consumers are running, then the exchange will have no bindings, and any messages published to it will be lost. Whether this is acceptable is something application-dependent.

2. Publisher Creates Everything

The publisher could be configured to create all the necessary infrastructure (exchanges, queues and bindings) as soon as it runs. This has the advantage that no messages will be lost (because queues will be bound to the exchange without needing any consumers to run first).

However, this means that the publisher must know about all the queues that will be bound to the exchange, which is not a very decoupled approach. Every time a new queue is added, the publisher must be reconfigured and redeployed to create it and bind it.

3. Consumer Creates Everything

The opposite approach is to have consumers create exchanges, queues and bindings that they need, as soon as they run. Like the previous approach, this introduces coupling, because consumers must know the exchange that their queues are binding to. Any change in the exchange (renaming, for instance) means that all consumers must be reconfigured and redeployed. This complexity may be prohibitive when a large number of queues and consumers are present.

4. Neither Creates Anything

A completely different option is for neither the publisher nor the consumer to create any of the required infrastructure. Instead, it is created beforehand using either the user interface of the Management Plugin or the Management CLI. This has several advantages:

  • Publishers and consumers can be truly decoupled. Publishers know only about exchanges, and consumers know only about queues.
  • This can easily be scripted and automated as part of a deployment pipeline.
  • Any changes (e.g. new queues) can be added without needing to touch any of the existing, already-deployed publishers and consumers.

Summary

Asynchronous messaging is a great way to decouple services in a distributed architecture, but to keep them decoupled, a valid strategy for maintaining the underlying messaging constructs (in the case of RabbitMQ, these would be the queues, exchanges and bindings) is necessary.

While publisher and consumer services may themselves take care of creating what they need, there could be a heavy price to pay in terms of initial message loss, coupling, and operational maintenance (in terms of configuration and deployment).

The best approach is probably to handle the messaging system configuration where it belongs: scripting it outside of the application. This ensures that services remain decoupled, and that the queueing system can change dynamically as needed without having to impact a lot of existing services.