Are Daily Status Meetings Still Needed?

/

I'm sure you're used to this scenario in your career by now: you start a new project and the manager instantly schedules daily standup meetings for everyone on the project to give their status. However, how many times has that meeting gone longer than the supposed no longer than 15 minutes? How many times has the discussion gone very off-topic taking even more of everyone's time? Quite a few times I'm sure.

I'm going to propose right now that I believe these mandatory daily meeting slots are no longer required for developing software using Agile.

It has long been said that meetings are usually a waste of everyone's time that has to be in them. If you look at the origins of these daily meetings, you will note that it was first brought up in the late 80s and into the 90s. It was then further developed in the early 2000s. At that point I can understand the use of them. Everybody was in the same office and there weren't any tools at that time that they can use to reduce or eliminate thier time in these meetings.

A lot of my thoughts in this post are going to resonate with a post Zach Holman did a long while ago about asynchronous communication. A good reason to use this type of communication is that people aren't commiting a specific block of their time. They can be in the best state of their entire career for programming thoughts to flow, but then they get a notification from their calendar that they have a status meeting in 15 minutes. This will definitely take them out of their flow state, take a few minutes to figure out what they need/want to say in the status meeting, then go to it.

From my experience these meetings always last longer than their intented length. It is said that they should only take 5 to 15 minutes total, but of course they usually go longer than that. And they usually go longer due to random, off-topic discussions. Whether it's about something with the project that came up and can be totally done over email or something about what the local college football team did the night before.

If the team is entirely remote then things get a bit more complicated. I agree with most things Jason Fried and David Heinemeier Hansson suggest in their book, Remote: Office Not Required. Being remote should allow the employee the freedom to handle things at home at the time it happens. One example was that if you need to get groceries at 10am then you should be allowed to do that. Then you come back home and continue to work. Personally, if I need to take someone I care about to the doctor at that exact time, I shouldn't have to worry about whether or not I need to make it to a status meeting.

Communication Tools

I explained the reasons why it isn't the best reason to continue holding daily status meetings, but what can be done as an alternative? Communication tools are getting much better as time goes back. The company I currently work for has adopted Slack. While we can make a channel for each project that we have and say our status there, there are also bots that can be integrated to do this for us.

Email is still used widely for communication. However, in these times of instant gratification, folks tend to think that we should instantly get a response after sending an email. That's definitely not the case as email is still a tool of asynchronous communication. People will respond when they can to email. In fact, if people are following the advice from the The 4-Hour Workweek book, then they will only check email two or three times a day.

Again, communication tools, especially for remote workers, are getting much better as time goes by. Slack may get beat by another tool or company that comes alone in the future. Join.me, Zoom, or Screenhero are great tools for screensharing or pairing. There are even sites that can help you find coding help instantly if you don't mind paying for it.

With the current state of tools these days and the growth of remote workers, having daily status meetings should be going as a thing of the past. Hindering employees flow state and taking their precious, and often expensive, time are too high of a price to pay for software projects. When daily statuses can be just a few minutes of typing at the leisure of the person giving the status, I really believe that having mandatory meeting times are a thing of the past.

Wintellect F# Blog Post Collection

/

I know it seems I've been MIA lately, but the truth is I've actually been blogging quite a bit on F# at my spot in Wintellect for a little while. Below is a collection of what's currently out there.

There will definitely be more in the future so keep an eye out there for more posts on F# and there may even be a few on Xamarin with F#.

Introduction to Paket

/

Paket has been quite the talk lately in the .NET community, and for very good reason. It is essentially another way to manage dependencies in your .NET projects.

But why replace NuGet?

Paket is basically a NuGet replacement so I'm sure you're wondering, "why would we need to replace NuGet?" Paket essentially just takes the functionality of NuGet and adds some extra nice features.

For one thing, Paket makes it able for you to control exactly what's happening with your package dependencies. No more conflict between different packages if those packages reference different versions of the same dependent package.

Another really cool thing Paket does is that it can reference a single file from GitHub. How many times have you needed that and just wound up downloading what you needed and using it that way? If a new version of that file comes along, you'll have to repeat that process.

But I'm already using NuGet

No problem at all! Paket has a nifty convert-from-nuget command to get you up and going.

I'm hooked...but how do I get started?

First, you need to include a .paket folder in the root of your solution. This will include paket.exe that will be used to install and restore packages.

Once that folder and its contents are there, you'll need to create a paket.dependencies file in the root directory of your solution. This file will be similar to the following:

source http://nuget.org/api/v2
nuget FSharp.Data
nuget FAKE

This file tells Paket what the sources are (NuGet or GitHub) and the package/file names so it can be downloaded.

You can then use a build.cmd file or manually call paket.exe like below.

\.paket\paket.exe install

This will create a packages folder that will include all the libraries.

From here you can always manually reference the libraries that you want, but Paket makes this easy as well. In each of the folders where you have a project file, create a paket.references file that contain the names of each library you want to be referenced, like below.

FSharp.Data

Note that FAKE isn't in the file since it won't get referenced. The paket.references file will only add to the project if the library is in a lib folder. FAKE is in a tools folder. This isn't a problem since it can be referenced manually in the build.fsx file.

To get Paket to use the references file, simply rerun the install command with the --hard switch.

\.paket\paket.exe install --hard

This will look at the paket.references file and use that to automatically reference the project with the appropriate libraries.

After that, you're good to get started on your project.

Conclusion

Hopefully this walkthrough will help you get started with using Paket to make your package management easier than before. This is still a young and very active project so I wouldn't be surprised if there are tons of things that this can do for all of our .NET projects.

Why F# for the Enterprise

/

I have gotten bit by the F# bug lately. After helping to release the F# portion of Exercism I've started to enjoy more and more of what F# has to offer. Of course, F# is a sort of "hybrid" language where you can do object oriented and procedural programming if you make it that way, but out of the box it's trying to get you to go more functional.

Several folks have posted as to why learn F# in the first place, but I figured I'd give some reasons why I think F# would be great for scenarios inside enterprise applications. While a few what others have mentioned as good reasons to learn F# in the first place, I believe these would also be the top reasons for enterprise development.

What's wrong with the current enterprise solutions?

Well, nothing, really. Of course, just because one solution works doesn't mean it's the most productive or easiest to maintain. For example, CSS precompilers like SASS and LESS do this with plain CSS stylesheets.

Why not use something that makes our lives, as developers, easier and helps to bring back the fun in developing again?

No More NullReferenceExceptions

While the above always tends to make me laugh, I'm quite sure each and every developer has fixed a production defect that involved this error. 

In F# there are is no thought of "null". You'll even get a compiler error if you try to use "null" in a pure F# program. For example, take a peek at the below code:

We're just defining some record types - Person and Employee - and let binding the Employee record with some values. Now, what happens if I set Person to null?

The compiler won't even let us try that...

Trying to assign null to a record type.

So this shows that, in pure F# code, the compiler won't allow us to set records as null which greatly reduces, perhaps even eliminates, NullReferenceExceptions.

What if we still need null?

There are some exceptions where F# will allow you to use null. Both of which involve using the .NET libraries.

  • As a parameter when calling one of the .NET libraries.
  • Handling if a call to a .NET library returns null.

Even using null in these scenarios can greatly reduce the NullReferenceException occurring in your application. To me, that's just one less thing I need to worry about.

But I still need it in my F# code

No worries! The language has you covered on that aspect as well. Allow me to introduce the option type. This is used if a value might not exist.

Let's take a small example of a bank account.

If the account isn't open yet or has already been closed, we don't expect a value. Otherwise, we do expect some value.

None vs null

How is this different than assigning to null? Remember that None is an option type. Because of that, the compiler will help us out if we may have missed anything. For example, in F# you can do pattern matching. Let's see how we can use pattern matching with the option type.

Good to go there. But, what if we happened to miss a match on None? We'll get this warning:

Pattern match warning.

Units of Measure

Units of Measure allow you to explicitly type a certain unit. F# does have predefined unit names and unit symbols in the Microsoft.FSharp.Data.UnitSystems.SI.UnitNames and Microsoft.FSharp.Data.UnitSystems.SI.UnitSymbols namespaces.

For example, say we wanted to use meters. Instead of assuming our application is using meters throughout all the calculation, which has a probability of being converted to another unit but still being represented as meter, we would just need to do the following:

Microsoft has included a few units of measure for us, as mentioned earlier, but we can definitely create our own. Say we had an application that dealt with different types of world currencies. We can easily define them as units of measure.

Now, what does this do for us exactly? Let's try to convert how many euros are in a dollar amount.

The first method we defined works just fine since we're using the units of measure. However, the second method generates a compile error since it can't infer what type "0.74" should be.

Since a unit of measure is typed, it will generate compile errors and reduce the amount of defects your application can cause due to a mismatch of units. This type of error does happen in real world applications...even to NASA engineers.

Type Providers

Type providers in F# is essentially a way to access all sorts of data. There are quite a few of them all ready for you to use now.

Just the SQL type providers alone are worth it for enterprise applications. Even better, you can even use them to access Entity Framework and LINQ to SQL.

Another important one that may be of great use to enterprise applications is the JSON type provider. 

Type providers provide an easy way to consume data within F# and, if you'd like, use C# to handle that data.

 

The above are just a few reasons of why I believe F# to be of great use to developing enterprise applications. Using the above, the risks of error would be greatly reduced and productivity would be increased. I know I'll be doing more F# in my applications from now on and I can only see it getting even better in the future as this language evolves.

Consuming the Jamendo API with AngularJS: Services

/

It took a little while to get back to this little project. After watching some nice stuff from NgConf the other week, it helped get me excited again for AngularJs. Plus, I was stuck on a problem for quite a while that I'll explain in more detail below that really slowed me down. After a bit of a break I got back to it and was able to figure it out.

Services

Before we looked at how to use the $http get method from AngularJS, but all of that was within the Angular controller itself. To separate things out and to help us test easier I moved the $http calls into an Angular service.

To recap, let's take a look at our controller currently:

As mentioned earlier, we have our $http call right inside of our controller. While that definitely works, it's better to separate that out into it's own service. Let's refactor this down a bit...

Now this looks a bit cleaner. We're first passing in the albumsService as a dependency into the controller. Of course, if Angular can't find that the albumsService is defined, it'll throw an error.

Next, we have the function definition of our getAlbums method. In here we extract out the artist from the scope and then call the getAlbums method on our service. In our call to the service we give it a function as a callback if the $http get was a success that we'll see later when we look at our service. This basically just gets the results and puts them into the scope.

Now let's take a look at our service.

Pretty straight forward as it's basically the same as what we had in our controller earlier. We inject in the $http Angular object and we create our getAlbums method while prepending it with this. 

When we call our success promise from the get method, I just pass in the callback method that we defined in our controller earlier. This makes it a bit easier on our service since the callback method was updating our $scope object and we don't have to worry about that here in our service.

I mentioned earlier that I had a bit of an issue that kept me from finishing this up. I kept getting an $inject error on my service that indicated that it wasn't defined, but I couldn't figure out why that was. After some fiddling around with it, it turns out that I was trying to inject the $scope object into the service and Angular doesn't like that. That's also a reason to use the callback.

Conclusion

Moving the $http get call to an Angular service is mostly just a small refactoring, but it's a good one to do. We will see later when we start to do testing how much easier it is to have that separated out.

Of course, this was just an introduction to Angular services so there's tons more to learn about them. I'll recommend Dan Wahlin's AngularJS in 60ish Minutes to anyone. In fact, I've referenced it a few times to remind myself about services. There's also the WintellectNow video from Jeremy Likness on AngularJS Services that goes into much greater detail of services.

You can play with the demo and, as always, you can play around with the code itself.

First Wintellect Blog Post + A New Series On Design Patterns

/

Just recently, I published my first blog post to the Wintellect (my awesome new employer) site. May not seem like much, but it's pretty exciting for me.

One of the things to keep yourself learning, I feel, is to tackle the stuff you feel you understand the least. For me, one of those things was the concept and implementation of different design patterns. I'm probably already too late in the game for this, but better than not learning it at all, right?

Head First Design Patterns - Part 1: Observer Pattern