Bill Blogs in C# -- Technology

Bill Blogs in C# -- Technology

Created: 1/5/2016 4:41:43 PM

This is my second post about the changing year. In this post, I look at the areas where I will invest my time in the coming year.

.NET Everywhere

The .NET Core platform is a version of the .NET stack that runs on OSX and Linux in addition to Windows platforms. This is a pre-release project at this time, but there is enough there to beging experimenting.

As this platform matures, .NET truly becomes cross-platform. You’ll be able to use C#, F#, VB.NET, and the bulk of the .NET Base Class Libraries to create software that runs on multiple platforms. The Roslyn compiler platform provides one of the key building blocks by running on OSX and Linux. That means the managed portions of the .NET Framework can be compiled on these platforms, and will run effectively. The remaining work is primarily to make the unmanaged portions of the CLR and the libraries run on other platforms.

Some of the work here is technical in nature. Other work is to ensure that the licenses used by the .NET framework components are compatible with a cross-platform strategy. Most of the components are released under either the Apache 2.0 license, or the MIT license. Check each library for details. (Notably, the previous restrictions on earlier MS-PL licenses for Windows only support has been removed from anything related to .NET Core).

While this work is going on, there is a parallel effort to build out learning materials for .NET Core. This project is also open source, and accepting contributions. (I’ve had a couple PRs merged here already).

I’m really looking forward to the date later in 2016 when a production ready .NET environment runs on Windows, Linux, and OSX.

C# 7 designing in the Open

This will be a very interesting version of C#. The team is using GitHub issues to openly discuss language features and their ramifications.  Go aehead and participate in the discussions. It is really exciting to see the community participate with such passion for different features that they would like to see in their favorite language.

As I discussed in the last post, the compiler is Open Source. If you want to experiment with some of the new features, you can try. There are experimental branches for some of proposed features. (The maturity of the implementation varies.) It’s also important to understand that the features haven’t been formally committed to. Do not use those branches in production applications (yet).

Clouds, Containers, and Devices

We’ve entered a world where our web-based applications are managing more data, and scaling to ever larger numbers of users.

OK, this trend has been in place for a while, but it’s only accelerating and growing.

We have new ways to deliver and scale web-based software. We have cloud platforms that enables us to change the number of instances running. We have docker containers. And, on a related trend, we can offload more and more processing to the client device. That may mean platform specific mobile applications, or SPA style browser based applications.

We will be doing more and more work with software that needs to scale by running multiple copies of your application in different configurations. There are many different options for this, and wise developers will learn a bit about each of them.

Rise of the Machine (Learning)

Machines are good at examining very large datasets. Machines are also good at running lots of different scenarios.

Put the two together, and I see a trend for more machine learning in the future. The applications we use generate tremendous amounts of data every day. As machines observe and analyze that data, more insights can be gained then ever before.  Machine Learning and related algorithms can enable us to play ‘what if’ with more and more different scenarios and make better decisions based on larger and larger data sets.

The Era of Big Data means Small Applications

Our data is a bigger and bigger part of our lives. The software necessary for us to interact with that data is smaller (in relation). This trend affects the ‘stickiness’ of any given platform.

This trend has a huge impact on how network effects work for modern systems.

As an example, consider music applications. Every platfrom has an app that can play music. But, what’s important to users is that they can play the music they’ve already purchased. If you already have an iTunes subscription, you want to play your iTunes music. If you have a Microsoft Groove subscription, you want to play your Groove music.

The important feature is access to the data (music) that you’ve already purchased (or subscribed to, or created).

That impacts the ‘stickiness’ of a platform. Finding and installing programms for a new device takes a fraction of the time (and possibly money) of updating every subscription to a new platfrom. I believe this portends an interesting trend in the network effects for different applications. Namely, changing device platforms will be a trivial exercise, compared to changing the provider of cloud based data.

I believe this means that future platform stickiness will be based on your cloud based data, not your device. Do you want to switch between mobile platforms? That will be easy, as long as your data can come along. If that means recreating or resubscribing to a service, its going to be a non starter.

That leads me to the concluson that the clould is more critical than the device.

What’s next for HTBox?

In the coming year, we’ll be focusing on reaching the 1.0 milestone (not beta) for the apps currently in development. We’ll also be ading new applications as the year progresses.

I’m excited for the progres, and I’d be happy to see more participation. If you are interested, head over to our home page on github and check out our projects.

Created: 4/10/2013 4:23:43 PM
I’m really happy with the response we got from the first night of the Humanitarian Toolbox hackathon at DevIntersections. We’re creating innovations that have a real human impact. WP_20130409_001 We didn’t really know what to expect.  Would conference attendees give up a free night after a day of learning new technologies to build more software?  Thankfully, the answer was yes.  We had a great team of developers helping us start building a crisis checkin system for disaster relief workers.  I’m confident that if we get some of the right people to attend tonight, we have a chance to make significant progress on the user stories for our first sprint. It was great to see developers that hadn’t even met each other sit down, discuss designs, create code, and help us build software to make disaster response more effective. There were three key events that make me very excited about where this can go:
  1. We were starting from nothing, and this morning we have working software.
  2. The folks that came wanted to apply what they’ve learned at DevIntersections to this project (more below).
  3. We continued to get commits after we all left at 10:00 pm.
One of the main sessions yesterday was JavaScript Jumpstart, where he explained his HotTowel template to attendees.  Our first app is using the HotTowel template. Thanks to John Papa for creating a great framework, and inspiring the team. The big goal is that this is the start of something.  It’s not a one time event.  We need to continue building software, creating real applications that real relief workers have asked for.  We’re using innovation to create real impact in real disaster situations. We’ve got another session tonight at DevIntersections, where we plan to finish the user stories that are in progress. If you’re at DevIntersections, please come by and help.  If not, don’t worry.  After this hack-a-thon, we’re going to open the source control system and the task board to everyone. We’ve got a few tasks to get done to make that happen, but we’ll get it done. Overall, I’m really impressed with the beginning we made.  I’m constantly impressed by the commitment, dedication, and contribution the software development community will make.  We are asking developers to give up their free time to build software that aids relief workers. We are getting great response.  I’m excited to see what we’ll build next.
Created: 3/28/2013 7:50:04 PM

I've always found that developers are very interested in contributing their skills and their time to help others.

I'm excited to be part of a new opportunity for developers to help others: The Humanitarian Toolbox.

The Humanitarian Toolbox  is the brain child of Richard Campbell, of .NET Rocks fame. The concept is to have developers create Open Source software projects that solve real problems for disaster relief organizations. A group of people, including Richard and I, have been working with global relief organizations to determine what they need most. We've already got a list of more than a dozen application ideas.

It's time to start building. We've picked the first project: a relief worker check-in system. This system would enable relief workers and volunteers to check-in and check-out at a disaster site. The field coordinators would have better information about the skills and the availability of relief workers, enabling them to better deploy the people that have volunteered their time to help. Relief workers and volunteers would get assignments and locations directly on their smartphone. The end result will be that relief workers are more efficient while on site, and more lives are saved.

We need developers that want to build this app.

Humanitarian Toolbox is hosting a hack-a-thon at DevIntersections. I'm working to organize the event, and help organize developers (like you) interested in participating. We plan to create a small proof of concept for the relief worker check-in system during the hack-a-thon. After the initial hack-a-thon, we want to enlist the broader community to continue building the app.

What's our deadline? We'd like it in place before the next natural disaster happens. We don't know when that will be, so we'd like to keep building and have it ready as soon as we can.

If you're going to be a DevIntersections, join us. Contribute your talent and help relief workers save lives. If you're not going to DevIntersections, there's still plenty to do to help. Follow us on twitter: @htbox or the hash tag for the event: #HtBox. We'll have plenty more software to build after the hack-a-thon. For us to be successful, we'll need to keep building and enhancing software for relief workers to battle the next crisis.

Write some code, help the world. Contribute to Humanitarian Toolbox.

Created: 3/5/2013 4:49:13 PM

Hat tip to Stephen Toub for discussing this with me and helping to describe the solution.

At my CodeMash precompiler, I mentioned how the C# compiler ensures that methods marked with the 'async' keyword that contain 'await' expressions never throw synchronous exceptions. Instead, those methods will return a Task (or Task<T>) that will be placed in the faulted state if the method throws an exception. The compiler does the work to add the appropriate try/catch clauses to your methods, and translates any exceptions thrown during your method's execution into returned faulted task.

Jon Skeet was concerned by this strategy. He felt that API designers would prefer throwing synchronous exceptions for obvious programmer errors (things like ArgumentNullException and so on). I mentioned that the language specification defines that async methods will returned faulted tasks; they will not throw synchronous exceptions.

Of course, there is a way around this. You have to separate your public async APIs into two pieces: A public synchronous API that does parameter validation and state validation. This synchronous method then calls an internal async method that does the asynchronous work.

As an example, consider this (rather contrived) async method:


         async Task<string> FizzBuzzAsync(int val)
    if (val <= 0)
        throw new ArgumentException("We can't fizzbuzz negative numbers, or 0");

    await Task.Delay(250);
    var rVal = string.Empty;
    if (val % 3 == 0)
        rVal += "Fizz";
    if (val % 5 == 0)
        rVal += "Buzz";
    if (string.IsNullOrWhiteSpace(rVal))
        rVal = val.ToString();
    return rVal;


Calling this method with a negative number is a programming error. We'd like to have that condition throw a synchronous exception. We can achieve this by separating the method into two parts. The first part is a synchronous method that performs the parameter validation and state validation. The second part is an internal method that performs the asynchronous work.  The first method will throw exceptions synchronously. The second will report errors using a faulted task.


         Task<string> FizzBuzzAsync(int val)
    if (val <= 0)
        throw new ArgumentException("We can't fizzbuzz negative numbers, or 0");
    return FizzBuzzAsyncImpl(val);
private static async Task<string> FizzBuzzAsyncImpl(int val)
    await Task.Delay(250);
    var rVal = string.Empty;
    if (val % 3 == 0)
        rVal += "Fizz";
    if (val % 5 == 0)
        rVal += "Buzz";
    if (string.IsNullOrWhiteSpace(rVal))
        rVal = val.ToString();
    return rVal;

That ensures that your public async methods conform to both important rules.

First, TAP (Task Asynchronous Pattern) methods do not allow synchronous runtime exceptions. They must return errors by returning a faulted task.

Second, to make it easier for callers to detect and correct programming errors, simple programming errors will throw synchronous exceptions.

Created: 2/22/2013 5:04:02 PM

Let me start by saying that much of the content at the Microsoft MVP Summit is covered by the NDA MVPs sign with Microsoft in order to participate in events like the summit. This recap necessarily leaves out any information that was covered under the NDA. Specifically, as a C# MVP, much of my time was spent with the C# and Visual Studio teams. There is a tremendous amount of work going on in those areas. I'm not blogging about any of those sessions, because all of those were NDA sessions. My silence on the future of C# is for that reason and that reason only.

There were a number of sessions and discussions around the async features added to C# 5. It was really valuable spending that much time with Stephen Toub  and Lucian Wischik discussing common mistakees people make when writing async code. In addition, Lucian and Stephen gave solid, actionable recommendations on good practices for async programming. I say 'good practices' not 'best practices' because these features are new enough that it's a bit arrogant to think we've figured out what's 'best'. We have good ideas, but they will still evolve. One of the async presentations was not covered under NDA, and Stephen has posted it on the pfxteam blog. I really like Lucian's explanation here on the state machine and event-based async programming (slides 23-25). This is a great explanation and example on how async, await, and the Task Based Async APIs can enable you to write async code that much more clearly represents your designs.

Test your own knowledge and take the async quiz at the end of the slide deck.

You probably saw the announcement on Git support in Visual Studio. There were a lot more discussions on Open Source development at Microsoft. Publicly, you can see the Azure support for Node.js is Open Source. ASP.NET MVC development is open source and accepting contributions from the community. For the past several years, there are more and more Open Source announcements at the MVP Summit, and those are always welcome news. I do hope it’s a trend that will continue, and next year's Summit brings even more announcements.

Like every conference, the Hallway Track is always valuable. Other MVPs have other focus areas. Even in SRT Solutions, Patrick Steele and I are C# MVPs, and Dennis Burton is an Azure MVP. It's incredibly valuable to discuss different areas of development with so many smart people from all around the world. The hallway track is where I can ask questions about ASP.NET development, Azure, Windows 8 development, XAML, and all the other areas I understand, but not as well as I do the C# language. I also get to catch up with the future of Visual Studio's ALM tools. (See Git Support above, I'm happy with what I learned).

Finally, a world wide conference with a bunch of developers can make you feel very hopeful about the future. Different regions show their pride in their home with what they wear. All the Canadian MVPs have Team Canada hockey jerseys. (I have one. It's a gift from Peter Ritchie, so I'm an honorary Canadian). The Brazilian MVPs wear Team Brasil football (soccer) jackets. Russian MVPs have Russian Olympic warm up jackets. It's all in fun, and great conversation starters. There are social events every evening, where we can chat with old friends and new acquaintances from all over the world. The final night was another attendee party at Century Link field. The organizers had setup one end for soccer and the other for American football. I learned a bit more about "real football" from some European friends, and taught a few of them how to throw a tight spiral with an American football. And, of course, there were bands and rockeoki (kareoke but with a live band) on the concourse. The quality of the singers varied greatly, but we all had fun. I’m sure some embarrassing YouTube videos will appear shortly.

I can't wait for next year.

Created: 2/20/2013 5:23:06 PM

In this post, I'll drill a bit into the final of the 3 areas SRT is investing in for 2013: Continuous Client Experience.

Users are now expecting that their experience, their work, and their data follows them from one device to the next. It's not enough to have a presence on mobile, web, and desktop. It's important that users have a seamless experience as they move from one device to the next.

One high profile example is Netflix. I can start a movie on my laptop. When I get home, I can switch to my Roku and have the movie pick up in exactly the same location. My picks are the same on my phone as on the living room device. We just expect that experience to move from device to device.

OneNote provides similar behavior as a productivity application. My notes automatically sync in the cloud. As I move from machine to machine, or to my phone, all my data just follows. The newest version of OneNote doesn’t even have a “save” command. My work just moves to the cloud on a regular basis.

All the applications we are now writing for business users demand the same kind of synchronization. It's driving several design decisions.

We're putting data in the cloud, where it's accessible from multiple devices. We're putting more effort into how we synchronize data. We're putting thought into server side data crunching and client side rendering. We're designing applications that have more and more of their algorithms in the cloud. That lets us develop more and more of the functionality for a single server platform. Each client has a smaller footprint and less device specific code. That lowers the cost of creating a great experience on each device. Finally, we're investing in making great offline experiences that synchronize data when the device notifies applications that a network is available.

Put all these areas together, and we believe we're well positioned for an exciting 2013. There are major shifts underway in our industry, and we intend to stay at the forefront.

Created: 2/18/2013 3:41:40 PM

As I wrote last week, Single Page Web Applications are another area where we're investing in 2013. The term "Single Page Web Application" is probably familiar to most of my readers. But, for those that are not, wikipedia defines Single Page Applications as:

A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.

You've probably used this type of application already today: Gmail, Facebook, and are all common examples. The latest version of the Azure developer portal is another great example of a Single Page Application.

These application types bring a desktop-like experience to web applications. Users do not have their workflow disrupted by pauses while the application posts to the web server and redraws an entire new page of content. Of course, these applications do send requests to the server, and receive new data. What's important is that these applications do that work using client-side code. These applications provide a true stateful application experience to the user. The web now becomes more of an application platform.

Single Page Web applications provide the mechanisms to give your users a better experience when using a browser based application. You'll see more and more adoption of these techniques, and the companies that adopt them well will be the companies that succeed in the marketplace.

We're making strong investments in this area to help our customers leverage these techniques. We've even launched a self-guided training lab: Choose Your Own Application so that developers can learn more about the toolkits that can be used to create these modern applications.

Created: 2/15/2013 10:27:21 PM

Last time I gave an overview of the areas where we’re making significant investments in 2013. In these posts, I’ll go into some detail on each of the areas where we’re investing. This is somewhat difficult, because our view is that all these areas work together to provide the right experience for users and customers. I’ll return to that in my final post on our investments this year.

The first area I mentioned was Mobile. Mobile applications help you reach your customers in more places and for more time. Your customers are on the move. They are using multiple devices.  To deepen your relationship with this customers, you need a quality presence in all the places your customers are.

But, creating a mobile presence isn’t simply recreating your entire application presence on a phone. If you’re going to smartly leverage Mobile, you need to reimagine your application, or your web presence in terms of a mobile device.

The main goal of a mobile application is to reach your customers where ever they are. The only way to succeed in that is to reach them with what they want to do when they have that device. Are they going to do the same tasks they perform when at your website? Or a subset? Or are there tasks that only make sense when they are using the mobile device?

We try to create mobile apps that have these properties:

  • It provides an authentic experience on the target platform: It fits on the device.
  • It grows the customer’s relationship with the brand: Customers want to spend time with it.
  • It adds value because it is native to the mobile device: Mobile users can do things desktop users can’t.

Only when a new mobile application exhibits these properties does it justify the investment. We don’t create mobile apps just to mark the checkbox. They must provide true value on the platform.

Created: 2/11/2013 7:06:03 PM

At SRT, we continuously examine the overall technology landscape and make decisions on where to invest more time, what should stay the same, and what should be getting less investment. The change is actually quite fluid. We are always looking at what can help our customers achieve their goals, and what technologies seem to be getting less emphasis in the future.

But, the beginning of the year seems to be the right time to make a statement for the coming year. Here goes:

We’re seeing three areas that deserve big investments this year:  Mobile, Single Page Web Applications, and the seamless integration of user experiences.

Let’s start with mobile: We’ve been building mobile applications for years, and demand continues to grow. There is obvious growth for iPhones, iPads, Android Phones, and Droid tablets. Windows Phone 8 and Windows 8 tablets are adding strong competition as well. There are a number of questions relating to how much market share each of these platforms will enjoy. But there is no question that the overall market for mobile software is growing, and growing quickly.

But mobile is only half (or one third) of the story.

Our customers demand that users access applications from their main computer as well as from their mobile device.  Modern web applications, termed “Single Page Applications” behave more and more like desktop applications everyday. Facebook and Gmail are the two most popular examples. These web applications provide an almost native experience in the browser.

This gets to the final and encompassing strategy decision:  Applications we’re building now must be available to users on any device, at any time. Data must be available on the web, on mobile devices, or on the desktop/laptop. The best apps can move seamlessly from device to device.  That requires building applications that are part mobile, part web, part cloud, and always available from anywhere.

We’ve positioned ourselves to build those applications.  We’ve got strengths on mobile platforms, web platforms, cloud platforms, and most importantly, building applications that span those different environments.

In my next few posts, I’ll go into more detail on each of these three topics: why they are important, and how to learn more about each of these topics. In the meantime, what do you think? Are these where you’re investing? Do these ideas represent the kinds of applications you want to use? Leave comments.

Created: 1/30/2013 10:16:06 PM
UPDATE:  Jake Ginnivan pointed out an inefficiency in my code below.  I was awaiting the async method under test twice.   As I mentioned a couple blog posts ago, I want to write tests that provide reasonable examples for users of my libraries. I expect developers to copy my tests as example code and modify it for production code. That can be tough for async tests when the async method should throw an exception. Well, as I was busy laying the background, Phil Haack leaped ahead to the punchline in his recent blog post. My own solution was a bit different: public static async Task ThrowsExceptionAsync<TException>(Func<Task> func)     where TException : Exception {     try     {         await func().ConfigureAwait(false); } catch (TException) {         return; }     Assert.Fail("Delegate did not throw " + typeof(TException).Name); } And you'd use it like this: await ThrowsExceptionAsync<ArgumentException>(() => worker.GetMessage("   ")); Note that the worker.GetMessage() does not need to be awaited here, because it is awaited in the ThrowsExceptionAsync method. Most of the differences between my version and Phil’s are due to the fact that I didn't use any xUnit specific features. However, one part I will discuss in a bit more detail. Note the ConfigureAwait(false) extension method when calling the async method under test: That instructs the framework to avoid the extra work of marshaling the continuation (the code after the await) onto the calling thread. This is a good practice for library code that does not need to have its continuations execute on the UI thread. I'll discuss this in more detail in a future blog post. There's also a few big picture concepts to get across on this post. The first key practice is that that async methods should return Task, not be void methods. If your async methods are void returning, you can't determine if your async methods worked correctly, or failed. By returning Task, you can query that Task (or let the compiler generate that code) to determine if it succeeded, failed, or was cancelled. The second key is that you should await for the result of any async method that returns a Task or Task<T> (even in a lambda). That causes the compiler to generate all the code to check that returned Task and ensure that it completed successfully. If it completed in a faulted state, the compiler generates code to throw the exception during the continuation. Finally, don't Wait() for Tasks to finish. await tasks. The compiler generates much better code to handle continuations when you await. And, that code is asyncrhonous, not synchronous.
Created: 1/25/2013 4:35:35 PM

I try not to write posts that are simply links to other posts, but I had to make an exception for this.  I was quite happy to see Scott Meyer's post on writing an effective effective book earlier this week. I received an earlier version of this advice almost a decade ago when I first worked on the proposal and outline for Effective C#. That advice, and all of Scott's additional advice and counsel made all the books I've written for the Effective series better. His guidance and advice are a key reason why the Effective Series books are so successful, and so well-received. The the authors in the series receive this advice, and receive constant feedback on the content, the form, the advice, and the style that goes into an Effective book.

The advice I got from Scott helped in many areas beyond writing that book. It has helped me become better at writing in general. I'm also better at explaining difficult concepts when I'm speaking to developers, or in meetings with other technical leaders. I remember several review comments from Scott on my first manuscript that started, “I don’t know C# very well, but this doesn’t make sense to me. Will your readers understand this?” It made me rework several explanations for greater clarity, and to be more complete.

If you're thinking of writing a book, you must read this post. It contains many nuggets of information that will help you reach your audience. You'll explain your points more clearly, and you'll justify your arguments much better. Your writing will actually accomplish its purpose.

Even if you don't plan to write a book, you should read this advice. If you work in technology, and you ever explain difficult concepts to coworkers, managers, customers, or others, this information is very useful. You'll be more effective at work, and your advice and counsel will be taken more often.

If you've enjoyed the books I've written for the Effective Series, this post gives you a glimpse at Scott's advice to make those books as useful as they've been. It’s invaluable advice. Read it. It will help you as much as it helped me.

Created: 1/21/2013 7:38:43 PM
Last week I promised that I'd write a blog post on using Assert.ThrowsException() to test async methods. Before I get to that, let's go over some of the other issues that come up with testing async methods. First, let's look at a test to verify that an async method works correctly:   public async Task<string> GetMessage(string user) {      return await Task.FromResult(string.Format("Hello {0}", user)); }   One test that works could be written like this:   [TestMethod] public void SimplePathTest() {     var worker = new Worker();     var answer = worker.GetMessage("unit tests").Result;     Assert.AreEqual("Hello, unit tests", answer); }   I don’t like writing tests like that.  Calling “.Result” on a task is a code smell.  The test method blocks until the result is available. That’s probably OK in a test method (more on that in future blog posts), but I’m still concerned. Developers often copy code from unit tests into production code. (I’ve done it myself when I’m learning how a library works.)  For that reason, I want my unit tests for follow the practices I would use in production code. That means I want to ‘await’ the result, not block for it. You might try reworking the test like this: [TestMethod] public async void SimplePathTest() {      var worker = new Worker();      var answer = await worker.GetMessage("unit tests");      Assert.AreEqual("Hello, unit tests", answer); }   You’ll see one of two results from this change:
  • You may see that test disappear from your list of unit tests.
  • You may run the test and find that results are not reported for any code that follows the first ‘await’.
I actually prefer the first, because you’ll quickly figure out that there’s a problem. The problem is that you have an async method that has the void return type. There’s no Task returned for the test runner to examine for any exceptions that were thrown. If your test fails and the Assert expressions throw exceptions, no code is there to receive the exception and report the test failure. If you are using MSTest, or XUnit, you can fix this problem by declaring your async tests with the Task return type: [TestMethod] public async Task SimplePathTest() { var worker = new Worker();      var answer = await worker.GetMessage("unit tests");      Assert.AreEqual("Hello, unit tests", answer); } That’s it.  Now, your async tests are using the idioms that you’d want people to use in production code. Above I mentioned that this idiom is supported for XUnit and MSTest. NUnit 2.6.2 adds this support as well.  I haven’t had the chance to work with the latest version yet. I’ll write more blog entries about NUnit support for async tests as I work with them. Next time, I’ll finally answer that comment about how to test async methods that throw exceptions with a ThrowsException<> style expression.
Created: 1/16/2013 12:36:23 PM

One of our customers is grappling with how to manage a scrum process that involves multiple teams with multiple responsibilities. The larger organization produces a number of business applications, all built on a common library. They have teams for each application, and a framework library team.

I thought our recommendations would be of general interest, so I’m posting them here. This is still a work in progress, so I'd appreciate any thoughts from my readers.

Sprint Meetings

We recommended moving away from a process where every team attended one large sprint meeting. Every team planned their next sprint during these large meetings. Our customer was concerned that there was very little energy in these marathon meetings. The main reason was that for many attendees, over 75% of the content was not interesting: it was about other applications. The level of detail was too deep for members of other teams. By scheduling project-specific sprint meetings, each meeting had fewer people, and those people were engaged in the activity.

To make sure that the voice of the customer was represented, we recommended that one member of each application team attend the framework team's sprint meetings.

To make sure that the framework team knew of any issues relating to each application, we recommended that one member of the framework team attend each application team meeting. (Although not necessarily the same person. That would be a lot of meetings).

We made this recommendation because sprint meetings are in depth, and project focused. We feel it's important to have all attendees engaged for the entire meeting. We wanted to reduce the waste associated with attending meetings where someone is not really contributing.

It did raise the energy in the project meetings. It also brought some concerns.  Everyone felt this decreased the communication between application teams. That could lead to code duplication, missed opportunities for reuse, and siloes of knowledge.

On to Standups

Standups are a mechanism to communicate to everyone any progress, and any issues. We recommended having all the application teams and the framework team attend the same daily standup. That’s about 30 people, but it can still be a short meeting, if everyone follows the rules. We're finding two main advantages to this process.

If someone is stuck, a larger group of peers hears about the issue. That increases the chance that someone will say "I can help." Issues get solved quicker.

The framework team is becoming much more efficient. Imagine someone on an application team makes a feature request of the framework team at one of these standups. One of three outcomes are possible:

  • No one says anything. That likely means that no other app needs that feature. Maybe that feature is better implemented in the app team's code base.
  • Other App teams say they need (or will soon need) that same feature. That information helps the framework team prioritize requests.
  • Another App team says "we've already built that feature." Now, the work changes from a new feature to refactoring code (and associated unit tests) to move it from the application's codebase to the common framework. That avoid code duplication, and means the framework team can release the new feature more quickly.

It's working quite well so far.

What have you tried? How has it worked?

Created: 1/14/2013 4:45:43 PM
The Windows Store version of the Microsoft Test Framework does not include an ExpectedExceptionAttribute class. I’ve already received questions on how people should go about creating tests where the code under test should generate exceptions. First, a note on the seriousness (or lack of) for this change:  The existing .NET libraries for testing do not display this problem.  Your existing unit test libraries are fine. But moving forward, how are you supposed to test failures? Instead of adding the ExpectedExceptionAttribute, you should use the new method: public static void ThrowsException<T>(Action code) where T : Exception There are reasons for this change. ExpectedException is a course-grained check that can cause tests to pass that really should fail. Consider this test:   [TestMethod, ExpectedException(ArgumentException)] public void ExceptionPath() { setupTestEnvironment(); var underTest = new Worker(); setupTestObject(underTest); var systemParms = GenerateCollaborator(); underTest.DoSomeWork(systemParms); }   The ExcpectedException attribute means that this test passes if *any* code in this test method throws the expected exception. It may not where you expect. It may be that some of your setup fails, and the particulars of the failure mean that the expected exception is what's thrown. That could mask problems in your production code.  If the setup method setupTestObject() throws an ArgumentException, this test passes, even though it shouldn’t. Because of the nature of this issue, it can crop up anytime. You could be updating test code and you could accidentally introduce this error. It would masked because the test passed when you started, and the test passed when you finished. Assert.ThrowsException fixes this issue.  Here’s the new version of the same test: [TestMethod] public void ExceptionPath() { setupTestEnvironment(); var underTest = new Worker(); setupTestObject(underTest); var systemParms = GenerateCollaborator(); underTest.DoSomeWork(systemParms); Assert.ThrowsException<ArgumentException>(() => underTest.DoSomeWork(default(string))); } This different version of the test passes if and only if the DoSomeWork() method throws the ArgumentException. If the ExceptionPath() test method throws an exception anywhere else, this test fails. As it should. If you update tests as you add features, or change defined behavior, I recommend changing your failure path tests to make use of this technique. I wouldn't retrofit every test you have, though. That feels like a whole lot of busy work, with only small benefit. Next, we'll look at how to write tests for async methods that throw exceptions. There are many nuances there that can mask issues in your tests, and in your production code.
Created: 1/7/2013 7:48:28 PM
We’ve partnered with Microsoft to host “Windows 8 Unleashed” in Ann Arbor on Thursday January 24th. This is a free event, sponsored by Microsoft, and hosted by SRT Solutions. Windows 8 Unleashed is a developer event focused on people that want to develop apps for the Windows store. (Surely you’ve seen the commercials for Windows 8 by now). The format contains 3 sessions where Jennifer Marsman and I will be explaining the principles of Modern UI Application development (what we formerly referred to as “Metro style apps”).  The afternoon is open lab time for you to create your Windows Store Application.  Jennifer and I (along with a few possible unannounced guests) will be available to help you over the rough spots. The first link above provide information about the event (including prize opportunities, and who doesn’t like free stuff). The second link is the registration page. Registration is free, but it will help us ensure we have enough room, and food for everyone that attends.

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.