The merits of best practices

For many years now I've had a dislike for best practices. This isn't the fault of the best practices themselves, but because people adopt them without thinking just because they've been told that they're best practices. I'm far from blameless in this regard too.

My view is that the merits of adopting should be questioned before proceeding. Unfortunately the problem with best practices being blindly adopted isn't going away no matter how many times myself and others talk about it. With that in mind I propose a new meta best practice:

Evaluate the merits of a best practice before implementing it.

Feel free to evaluate the merits of the above :)

How do you feel about best practices

Why I blog

I started writing this blog post on the above topic earlier in the year and had almost finished it, but I was never happy with the result. Now my original reasons don't apply anymore so I thought I'd post about what's changed in a few short months.

The original reasons I started my blog were as follows:

1) putting down my thoughts in writing helps me solidify them.
2) to get feedback from others in the community.
3) to let me review my previous thoughts and see how I have changed over time.
4) to improve my writing skills.

Overall it's been a positive experience and I don't really have to self promote it anymore, but one thing has been bothering me and that's the amount of feedback I've received from the community.

If you go back through my archive you'll see a number of comments but compared with the site traffic it's a small drop in the ocean. Don't get me wrong, I thoroughly appreciate everyone who has taken time to comment but I'm craving more discussion so that I can learn.

Moving on to the present. Though my original intents for blogging are still valid, these no longer apply to the blog itself. Since July, Google+ (G+) has been my substitute for my blog. When I post there, I am closing the feedback loop considerably and am getting more feedback than I have here. I'd love to be proven wrong about this but I feel my time is best spent posting on G+.

Now onto my current reason to blog. Basically I'm still using it as a place for my thoughts, but the content I'm creating is replicated from G+. I'm not doing it for every post, only the ones I want to highlight to others. This highlighting is one thing that G+ doesn't do well.

I'm interested in what others are doing with their blogs. Do you still blog? What are your reasons for doing so?

I don't build software I create it

This title might seem like pretensious nonsense to some or that I'm splitting hairs, but bear with me and you can tell me whether it is/I am in comments below.

I'm a great believer that the words we use form the way we think about things. With that in mind, I want to state that I don't build software, I create it, I write it, I design it.

I use these words to describe an activity that is extremely creative. We don't lay down bricks and mortar to a predefined pattern or build a car which has already been designed and tested, we take ideas from our clients and turn them into reality.

I don't see creating software as construction, it has more in common with product design, and research and development.

To me when looking at a well designed, highly maintenable application I see the beauty, creativity and art behind it.

Developers themselves are generally creative people. How many do you know that play music, write books, do photography, etc?

For a long time software has been stuck in a construction metaphor. I think it's time to move on.

Process smell: Hardening sprint

Many people have discussed a hardening sprint in the past, some for and some against. I'm definitely in the latter category.

I've been in teams that have haven't had them and ones that have introduced them.

Hardening sprints tend to get introduced for the best of intentions. The team has spotted that they are having problems with quality and want to do something about it. Great, but the first thing that generally comes to mind is to do lots of testing before every release. This fixes the symptoms but not the underlying issues. Also what happens if you have to release unexpectedly? These underlying issues really need to be uncovered and dealt with, but that isn't the focus for this post.

Hardening sprints point to a process smell. The team should be dealing with their quality issue as the code is being written, not well after. There should be a whole team and company commitment to quality. Having these sprints can cause us to defer quality until just before release. It also breaks the completed stories should be potentially releasable rule.

There are numerous things a team can try without resorting to a hardening sprint.  I've listed a few below:

Take a look at implementing TDD.
Have testers and developers collaborate more as the code is being written.
Pair test.
Have acceptance criteria before planning which form the basis of acceptance tests.
... and more.

Do you have a hardening sprint before release? What are the benefits from having one?

Personal ideal working hours vs team working hours

Ideal working hours are the hours during which you are the most productive. This can be at any time of the day. For some people this time is in the evening, for some the morning.

The challenge comes when balancing your own ideal working hours with those of the members of your team. If you are in a truly collaborative team, the most productive time is when everyone is in the office.

Some companies completely disregard ideal working hours and mandate that everyone be in the office between certain times. Others allow everyone to set their own working hours. The former sacrifices the individual for the team and the latter sacrifices the team for the sake of the individual.

Like everything else in life I believe there should be some balance between these two opposites.

An interesting discussion to have with your team is around each persons ideal and then setting core working hours based on that discussion. This should allow some flexibility for the individual and established team time too.

Again like everything else in life, you're not going to always be able to please everyone.

As a final point, sometimes an individual may have to sacrifice their own ideal working hours due to their personal situation. This us true in my case, when I work best in the evening but for my personal situation it's best that I start work early in the morning.

What are your ideal working hours?

ScrumMasters: if you're stuck, ask the team

Sometimes being a ScrumMaster can feel a little lonely especially in a small company, but you are not alone. You're there to help the team, but the team can also help you. Sometimes is feels like you have to have an answer to everything, but no-one is expected to know everything.

There will be times when you get stuck. If you do, ask the team for help.

Today our team had our bi-weekly retrospective. Going into it I felt unprepared as I couldn't think of a particular focus area. I asked the team beforehand if there was anything they wanted to focus on, but no-one could come up with any ideas.

I'm not a big fan of doing a general retrospective as they can be pretty scattershot and don't really do a deep dive into anything. Instead we started out with a brainstorming session on ideas for a retrospective focus. After some time and silence team members suggested a few topics. I decided to add one which was basically about generating focus ideas. The team voted and agreed on my focus idea. From there we generated some great action items around collecting more data that we can focus on. Amongst other things we're going to capture information about events within the sprint as they happen. We're also going to start collecting each team member's mood rating on a daily basis.

The team recognised the fact that a clear focus area isn't always obvious, especially if the sprint has gone well. I feel that the ideas that were generated will go a long way to improving our retrospectives in the future.
The team was able to help me on something I was stuck on.

First impressions of CoffeeScript

I first heard the word CoffeeScript banded about by a few people in the agile circles I run in a while ago. I heard that it was a language that compiled down to JavaScript but was more succinct and had better syntax. This instantly peeked my interest.

I've been coding Javascript for about 14 years and frankly I've always hated it. The advent of JQuery has made it more bearable, but it hasn't changed my feelings about JavaScript and don't get me started on JavaScript inheritance :)

I figured that anything that could improve on the syntax would be a good thing, so I decided to give it a shot.

Scott Hanselman recently posted about a plugin for VS.NET, called Mindscape Web Workbench, which allows realtime compilation of CoffeeScript to Javascript so I installed it and was off to the races.

Whenever I learn a new language I like to reimplement code I have written previous. This allows me to get the syntax down without worrying about logic. In this case I decided to rewrite a JQuery plugin, in our product at work, that I had worked on in the past.

I have to say that after some initial high hopes and early wins I'm rather disappointed.

I'm disappointed because the CoffeeScript syntax isn't too far removed from the way our Javascript is structured already and only slightly more succinct. We make heavy use of Knockout which is an MVVM framework. I'm not going to go into depth about Knockout, but if you want more information you can visit the Knockout website.

Here's an example of how our Javascript models are structured:

var exampleModel = {
    selection: ko.observable(""),
    text: ko.observable(""),
    isEverythingEntered : function () {
        return this.text().length > 0 && this.selection() > 0;
    }
};

Now here is that same code in CoffeeScript:

exampleModel:
    selection: ko.observable("")
    text: ko.observable("")
    isEverythingEntered ->
        this.text().length > 0 and this.selection() > 0

As you can see, they are very similar. This is a contrived example, but the more complex ones aren't any different.

The pros as I see them so far are as follows:

• No more missing semicolons at the end of a line. Though Firefox and Chrome are robust when it comes to malformed JavaScript, IE isn't and will throw script errors if there's a missing semicolon's. Same goes for additional commas at the end of a block.
• -> looks far nicer than having to write function() { }

The cons are as follows:

• It relies on tabbed indenting. The rest of our codebase is space indented. At this time I'm not sure if this is a problem with CoffeeScript or with Mindscape Web Workbench.
• I'm not a fan of the if then else syntax instead of a ternary operator.
• Large Javascript files cause VS.NET to lag a bit. This isn't to do with CoffeeScript, but to do with the plugin.

Right now I'm not sure the pros are enough to adopt CoffeeScript.

I'm curious what your experiences are. Am I missing something?