Eight Tips For Your Programming Team's Standup Meetings

As my organization has gone further down the Agile project management path (from our original process of a lean waterfall), one of the things we've started doing is daily standup meetings. These are short (15 minutes or less) meetings in which each team member reports on what they have accomplished recently and what they are planning to do today. They've been a fantastic tool to keep our team on track and on time, and I'm rapidly becoming convinced that they're going to be (if they aren't already) an essential part of modern software development teams.

A development team conducting a standup meeting.

Standup meetings are fast, directed conversations between team members where everyone updates everyone else as their own status and what they are doing. My team has come to a point where we are fully comfortable conducting our standup meetings, and so I thought I'd share some of the tips we've discovered as to how you can conduct your standups efficiently and quickly.

1. Keep it short

I cannot stress this enough: developers are busy people, and we don't like being interrupted. If a "standup" meeting is longer than 15 minutes, it is not a standup meeting. My group (six developers including me, plus a manager) aims for our meetings to be seven minutes or less. Keep the meeting short so everyone can get back to work!

2. Do it every day

Yes, every day. Even days when half the office is out on vacation and there's pressing bugs that need to be fixed right NOW. If there are people working on that day, you should do the standup meeting.

3. Use a standard template

My team's template looks like this:

  1. Here's what I accomplished yesterday (including task numbers, bug reports, etc.).
  2. Here's what I'm planning to do today (including task numbers, work requests, etc.).
  3. Blocks (things I cannot accomplish without someone else's help).
  4. Lingers (things which I am waiting to be done by someone else but are not impeding my work).
  5. Task status (e.g. whether or not our TFS tasks are up-to-date).

4. Don't allow the conversation to drift

Only pertinent work stuff is allowed. If any other things besides what's in your team's template need to be discussed, they should be discussed outside the standup.

5. Everybody gets a turn

This is important because, after all, we're a team, not a group of individuals. We're only as good as the least of us.

6. Meet at the same time every day

The expectation is that this time will be when everyone is expected to be working. Late morning, before lunch, works particularly well for my team.

7. Have a designated meeting leader

In our company's case, it's the team lead (e.g. me) that directs these meetings. That means it falls directly on my shoulders to ensure that the meeting is short, effective, and gets everyone involved. This is critical because whoever this person is (and it does not have to be the team lead), they are responsible for ensuring that the meeting interrupts everyone as little as possible.

8. You don't have to actually stand up

My group does our standups over Slack, because many times people just aren't in the office but are still working (i.e. on work-from-home days).

The point of having a standup meeting is to prevent those soul-sucking hour long meetings where everything gets talked about but nothing gets done. Such meetings happen when people don't know what other people are doing, and so managers or team leads call meetings to discuss who's doing what. Inevitably, these kinds of meetings get derailed because in the three weeks (or longer!) since the last meeting more has happened than can be discussed in an hour, and so the meeting takes three hours and nothing gets resolved. Those kind of meetings are a drain on resources and team morale, and should be dragged out into the street and shot. Standups are a way for everyone to explain what they've done and what they need to do, as well as getting the team to talk amongst one another, so that you don't need the soul-sucking meetings in the first place.

In short, standup meetings should be quick, directed, and done. That way, everyone can get back to what they want to be doing in the first place: programming!

The standup meeting tips I've listed above are what works for my team, at my company, but our way is not the only way to run effective standups. What tips do you have for your team's standup meetings? I'd love to hear them, so let me know in the comments!

Happy Coding Standups!

Image is Equipe durante um stand up meeting (daily meeting), used under license

Decimal vs Double and Other Tips About Number Types in .NET

I've been coding with .NET for a long time. In all of that time, I haven't really had a need to figure out the nitty-gritty differences between float and double, or between decimal and pretty much any other type. I've just used them as I see fit, and hope that's how they were meant to be used.

Until recently, anyway. Recently, as I was attending the AngleBrackets conference, and one of the coolest parts of attending that conference is getting to be in an in-depth workshop. My particular workshop was called I Will Make You A Better C# Programmer by Kathleen Dollard, and my reaction was thus:

One of the most interesting things I learned at Kathleen's session was that the .NET number types don't always behave the way I think they do. In this post, I'm going to walk through a few (a VERY few) of Kathleen's examples and try to explain why .NET has so many different number types and what they are each for. Come along as I (with her code) attempt to show what the number types are, and what they are used for!

The Number Types in .NET

Let's start with a review of the more common number types in .NET. Here's a few of the basic types:

  • Int16 (aka short): A signed integer with 16 bits (2 bytes) of space available.
  • Int32 (aka int): A signed integer with 32 bits (4 bytes) of space available.
  • Int64 (aka long): A signed integer with 64 bits (8 bytes) of space available.
  • Single (aka float): A 32-bit floating point number.
  • Double (aka double): A 64-bit floating-point number.
  • Decimal (aka decimal): A 128-bit floating-point number with a higher precision and a smaller range than Single or Double.

There's an interesting thing to point out when comparing double and decimal: the range of double is ±5.0 × 10−324 to ±1.7 × 10308, while the range of decimal is (-7.9 x 1028 to 7.9 x 1028) / (100 to 28). In other words, the range of double is several times larger than the range of decimal. The reason for this is that they are used for quite different things.

Precision vs Accuracy

One of the concepts that's really important to discuss when dealing with .NET number types is that of precision vs. accuracy. To make matters more complicated, there are actually two different definitions of precision, one of which I will call arithmetic precision.

  • Precision refers to the closeness of two or more measurements to each other. If you measure something five times and get exactly 4.321 each time, your measurement can be said to be very precise.
  • Accuracy refers to the closeness of a value to standard or known value. If you measure something, and find it's weight to be 4.7kg, but the known value for that object is 10kg, your measurement is not very accurate.
  • Arithmetic precision refers to the number of digits used to represent a number (e.g. how many numbers after the decimal are used). The number 9.87 is less arithmetically precise than the number 9.87654332.

We always need mathematical operations in a computer system to be accurate; we cannot ever expect 4 x 6 = 32. Further, we also need these calculations to be precise using the common term; 4 x 6 must always be precisely 24 no matter how many times we make that calculation. However, the extent to which we want our systems to be either arithmetically precise has a direct impact on the performance of those system.

If we lose some arithmetic precision, we gain performance. The reverse is also true: if we need values to be arithmetically precise, we will spend more time calculating those values. Forgetting this can lead to incredible performance problems, problems which can be solved by using the correct type for the correct problem. These kinds of issues are most clearly shown during Test 3 later in this post.

Why Is Int The Default?

Here's something I've always wondered. If you take this line of code:

var number = 5;  

Why is the type of number always an int? Why not a short, since that takes up less space? Or maybe a long, since that will represent nearly any integer we could possibly use?

Turns out, the answer is, as it often is, performance. .NET optimizes your code to run in a 32-bit architecture, which means that any operations involving 32-bit integers will by definition be more performant than either 16-bit or 64-bit operations. I expect that this will change as we move toward a 64-bit architecture being standard, but for now, 32-bit integers are the most performant option.

Testing the Number Types

One of the ways we can start to see the inherent differences between the above types is by trying to use them in calculations. We're going to see three different tests, each of which will reveal a little more about how .NET uses each of these types.

Test 1: Division

Let's start with a basic example using division. Consider the following code:

private void DivisionTest1()  
    int maxDiscountPercent = 30;
    int markupPercent = 20;
    Single niceFactor = 30;
    double discount = maxDiscountPercent * (markupPercent / niceFactor);
    Console.WriteLine("Discount (double): ${0:R}", discount);

private void DivisionTest2()  
    byte maxDiscountPercent = 30;
    int markupPercent = 20;
    int niceFactor = 30;
    int discount = maxDiscountPercent * (markupPercent / niceFactor);
    Console.WriteLine("Discount (int): ${0}", discount);

Note that the only thing that's really different about these two methods are the types of the local variables.

Now here's the question: what will the discount be in each of these methods?

If you said that they'll both be $20, you're missing something very important.

The problem line is this one, from DivisionTest2():

int discount = maxDiscountPercent * (markupPercent / niceFactor);  

Here's the problem: because markupPercent is declared as an int (which in turn makes it an Int32), when you divide an int by another int, the result will be an int, even when we would logically expect it to be something like a double. .NET does this by truncating the result, so because 20 / 30 = 0.6666667, what you get back is 0 (and anything times 0 is 0).

In short, the discount for DivisionTest1 is the expected $20, but the discount for DivisionTest2 is $0, and the only difference between them is what types are used. That's quite a difference, no?

Test 2 - Double Addition

Now we get to see something really weird, and it involves the concept of arithmetic precision from earlier. Here's the next method:

public void DoubleAddition()  
    Double x = .1;
    Double result = 10 * x;
    Double result2 = x + x + x + x + x + x + x + x + x + x;

    Console.WriteLine("{0} - {1}", result, result2);
    Console.WriteLine("{0:R} - {1:R}", result, result2);

Just by reading this code, we expect result and result2 to be the same: multiplying .1 x 10 should equal .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1.

But there's another trick here, and that's the usage of the "{O:R}" string formatter. That's called the round-trip formatter, and it tells .NET to display all parts of this number to its maximum arithmetic precision.

If we run this method, what does the output look like?

By using the round-trip formatter, we see that the multiplication result ended up being exactly 1, but the addition result was off from 1 by a miniscule (but still potentially significant) amount. Question is: why does it do this?

In most systems, a number like 0.1 cannot be accurately represented using binary. There will be some form of arithmetic precision error when using a number such as this. Generally, said arithmetic precision error is not noticeable when doing mathematical operations, but the more operations you perform, the more noticeable the error is. The reason we see the error above is because for the multiplication portion, we only performed one operation, but for the addition portion, we performed ten, and thus caused the arithmetic precision error to compound each time.

Test 3 - Decimal vs Double Performance

Now we get to see something really interesting. I'm often approached by new .NET programmers with a question like the following: why should we use decimal over double and vice-versa? This test pretty clearly spells out when and why you should use these two types.

Here's the sample code:

private int iterations = 100000000;

private void DoubleTest()  
    Stopwatch watch = new Stopwatch();
    Double z = 0;
    for (int i = 0; i < iterations; i++)
        Double x = i;
        Double y = x * i;
        z += y;
    Console.WriteLine("Double: " + watch.ElapsedTicks);

private void DecimalTest()  
    Stopwatch watch = new Stopwatch();
    Decimal z = 0;
    for (int i = 0; i < iterations; i++)
        Decimal x = i;
        Decimal y = x * i;
        z += y;
    Console.WriteLine("Decimal: " + watch.ElapsedTicks);

For each of these types, we are doing a series of operations (100 million of them) and seeing how many ticks it takes for the double operation to execute vs how many ticks it takes for the decimal operations to execute. The answer is startling:

The operations involving double take 790836 ticks, while the operations involving decimal take a whopping 16728386 ticks. In other words, the decimal operations take 21 times longer to execute than the double operations. (If you run the sample project, you'll notice that the decimal operations take visibly longer than the double ones).

But why? Why does double take so much less time than decimal?

For one thing, double uses base-2 math, while decimal uses base-10 math. Base-2 math is much quicker for computers to calculate.

Further, what double is concerned with is performance, while what decimal is concerned with is precision. When using double, you are accepting a known trade-off: you won't be super precise in your calculations, but you will get an acceptable answer quickly. Whereas with decimal, precision is built into its type: it's meant to be used for money calculations, and guess how many people would riot if those weren't accurate down to the 23rd place after the decimal point.

In short, double and decimal are two totally separate types for a reason: one is for speed, and the other is for precision. Make sure you use the appropriate one at the appropriate time.


As can be expected from such a long-lived framework, .NET has several number types to help you with your calculations, ranging from simple integers to complex currency-based values. As always, it's important to use the correct tool for the job:

  • Use double for non-integer math where the most precise answer isn't necessary.
  • Use decimal for non-integer math where precision is needed (e.g. money and currency).
  • Use int by default for any integer-based operations that can use that type, as it will be more performant than short or long.

Don't forget to check out the sample project over on GitHub!

Are there any other pitfalls or improvements we should be aware of? Feel free to sound off in the comments!

Happy Coding!

Huge thanks to Kathleen Dollard (@kathleendollard) for providing the code samples and her invaluable insight into how to effectively explain what's going on in these samples. Check out her Pluralsight course for more!

Why Aren't You Blogging Yet? Tips for Getting Started

I've been writing this blog for about a year and a half now, and I firmly believe that every software professional should write a blog. It's an invaluable tool for connecting with other professionals, for getting your ideas out there, for making bad jokes making good jokes.

I've told this to several other programmers, and I'm always met with the same responses. Wow, you're such a good writer! I can't possibly write as well as you do! Once I've told my ego to calm down and eat a bagel, I start hearing all kinds of excuses: I don't have time, I don't know any good topics, nobody cares about what I have to say. Which is bull, but there you have it.

Writing a blog is not some ancient magic that I studied for years to master! It's a process, one which is becoming a part of me just as much as working or eating is. You can do it too!

Still don't believe me? OK then, let me first dispel some common myths about blogging. All of these are things I have heard from others about why they can't or won't write a blog.

Myths About Blogging

Nobody cares about what I have to say. You're telling me that in a world of 7 billion people, where almost everybody can have someone that looks like them, that no one will ever care about your ideas? I don't believe this for an instant. Someone, somewhere, will have the same problem you have, the same ideas you thought of, and will want to know that someone else out there is thinking the same thing.

I don't have time. Neither do I. I have a family, a career, a house to maintain. But I make time. Writing this blog is now just something I do, rather than something I have to do. My blog is my outlet, my window into new tech and new stories, and my way to communicate with other members of my profession. You can always watch less TV, or play less video games, or find other ways to make time.

I can't write. It's not a requirement to be a writer in order to be a blogger. Half the bloggers out there couldn't write their way out of a contrived plot coincidence wet paper bag! That doesn't stop them, it doesn't stop me, and it shouldn't stop you. Besides, how do you expect to get better if you don't practice? Nobody's asking you to write the next great novel.

I'm scared of what my coworkers/friends/peers will think. Ignore them! If they're gonna change their mind about you because you put yourself out there, do you want to care about their opinion? Nobody gets to influence you more than you.

I don't have any good topics to blog about. Everything you know, someone else doesn't know. Don't assume that because you know something, everyone else does too.

Everything I want to write about has already been written. This doesn't matter at all. Half the topics I blog about have already been blogged about by other people. The trick is to find a way to make it interesting for your readers, make it unique in some way that doesn't In my case, I use humor (to varying effect), simple sentences, and general topics to reach as many people as I can.

Why Should I Blog Anyway?

Glad you asked!

It helps your communication skills. Sitting down and thinking about a problem for long enough allows you to concisely and accurately describe that problem to others. Communication is one of the most (if not the most) important soft skill for developers, and writing blog posts will make you a better communicator.

It gets your name out there. Especially if you have a super common name like I do. Writing a blog gets your ideas out into the world for your friends, coworkers, even prospective employers to see.

It teaches humility. There's been quite a few times where I've screwed something up and some kind soul out there on the interwebs has pointed it out (always with respect, of course).

It teaches you to be thorough. If you're taking the time to write something, you'd better be pretty darn sure it's accurate; or else you'll have a hoard of annoyed internet dwellers ready to explain, in excruciating detail, why and how and where you are wrong. Repeatedly.

Hopefully by now I've got you convinced to try blogging out (or, at least not actively hostile to the idea). Here's a couple of tips for getting started with your very own blog.

Tips For Getting Started

Get your own domain name. Your own, custom domain name makes it much easier for people to find and refer back to your blog, plus it looks professional. I personally think the top-level domain (TLD, e.g. .net, .com, .whatever) doesn't matter at all, but I'd still get something people recognize.

Start small. Pick a small topic, write a clear, concise post about it, and post it.

Don't write novels. I've seen other bloggers recommend writing everything about a topic on one page, but for me (probably because I'm a distracted individual) seeing a huge wall of text on a page is cause for me to run screaming in terror (aka hitting the back button). If the topic is large, break it up into multiple posts.

Post often. I personally write at least one post per week. They don't have to be big, involved works; hell they don't even have to be good, just write something. The post you've published is better than the post you've written.

Use whitespace. Huge multi-sentence paragraphs are a big turn off to many readers; they look impenetrable, dense, scary. Use whitespace by making lots of small paragraphs, and cut out any words or sentences that don't clearly and concisely support the point you are making.

Allow comments. It boggles my mind that bloggers can write some huge, insightful post and not allow other people to leave comments on it. Comments are where much of the value in writing a blog lies! After all, the whole of humanity is generally going to be smarter than you.

Manage the comments. Of course, allowing comments means some extra work on your part. You have to make sure you don't allow spam, or ads, or abusive posters. But in my opinion the extra work involved in maintaining a comments section is heavily outweighed by the value it provides.

Make it something you just do. If you want your blog to be successful, make it something you do, rather than something you have to do. This is the truly difficult part of writing a blog, but that kind of commitment tends to shine through your writing, making it obvious that blogging is something you enjoy rather than tolerate.

Don't expect to make money, because you probably won't. Blogging is not something people do to make a living. Sure, some super-famous bloggers can do this, but for the vast majority of us we're lucky if we make enough money to pay our hosting costs. Don't blog if all you're after is money, because you'll be sorely disappointed.

I love writing. It's why I write stories, why I write tutorials, why I write at all. But you don't have to love to write to be a good blogger, and you certainly don't need to be a good writer to be an effective blogger (proof). To me, the benefits of blogging significantly outweigh the downsides, and the skills writing teaches (communication, humility, confidence) are useful in almost every facet of our lives, not just our professional one.

So go get started! Nothing's stopping you except you!

Happy Coding Writing!

Getting All Valid Enum Values in ASP.NET Web API

One of the commenters on my blog posed an interesting question on my article about serializing enumerations in Web API:

A comment on my blog, asking

He wanted to know how someone who is querying a Web API might know what possible values a given enumeration has. I didn't answer that in the post he commented on, so I'll do that now. How do we tell consumers what possible values an enumeration in a Web API app has?

Let's say we have the following enums:

public enum AddressType  

public enum AccessLevel  

We want to expose a query which returns these values for each enumeration. To do that, let's create a class for EnumValue:

public class EnumValue  
    public string Name { get; set; }
    public int Value { get; set; }

It's a pretty generic class, to be sure, but since all enumerations are is a name and a value it serves our purposes well enough.

The trick now is to create an extension which uses Reflection to get all the names for the given enum. In fact, we can even make that method generic, so it can be used for any enumeration at all.

public static class EnumExtensions  
    public static List<EnumValue> GetValues<T>()
        List<EnumValue> values = new List<EnumValue>();
        foreach (var itemType in Enum.GetValues(typeof(T)))
            //For each value of this enumeration, add a new EnumValue instance
            values.Add(new EnumValue()
                Name = Enum.GetName(typeof(T), itemType), 
                Value = (int)itemType
        return values;

Finally, we can use Web API methods that call this extension:

public class HomeController : ApiController  
    public IHttpActionResult GetAccessLevels()
        return Ok(EnumExtensions.GetValues<AccessLevel>());

    public IHttpActionResult GetAddressTypes()
        return Ok(EnumExtensions.GetValues<AddressType>());

When we call this method using Postman, we now get an appropriate response code (200 OK) and the data we were looking for. Here's the address types:

A Postman response, showing the three possible values for the enumeration AddressType

And here's the access levels:

A Postman response, showing the three possible values for the enumeration AccessLevel

Of course, this is just one of many possible solutions to this particular problem. I like this method because it's generic and reusable for all enumerations, but if you find a better method, please feel free to share in the comments!

That's all there is to it! Now any consumer can hit these methods and know exactly what values can be used for the AccessLevel and AddressType enumerations!

I also have a repository over on GitHub which stores the sample code for this post. Check it out!

Happy Coding!