Committing to Software Trials

As you will be able to see if you go back a few posts in my Blog I have an unhealthy dislike for TFS. Most of it comes from a belief, that rubbed off on me in a previous position, that if a product is not easy and enjoyable to use people will not use it. TFS issue tracking is not easy to use. It is really little more than a single database table that you can define custom queries against. I am pretty sure that you could achieve 90% of the functionality using Microsoft Access. So imagine my joy when I finally managed to get my boss to give JIRA a try.

JIRA is both fun and easy to use provided you use their workflows. With the GreenHopper plugin you can move things around in the backlog just by dragging them (you can do this in TFS 2012 but that's not what we're using), drag tasks around the workflow to indicate progress, drag issues from one release to another and so on and so forth. All the charts you really need are also bundled in with the Green Hopper plugin including a real-time burn down (not just a daily summary like TFS), cumulative flow and more. There are also easy prioritisation and voting tools to help project managers prioritise work.

Despite the awesomeness of JIRA I am not enjoying our trial. Unfortunately for Atlassian it is not their fault and there is not a lot they can do about it. You see the original plan for the trial was to switch our small team from TFS to JIRA for a sprint so that everyone could marvel at it's wonder. Being an eager beaver I was on it from the start and had the next sprint of items from the backlog into JIRA in no time. But then things went wrong. Product Management were not aware we were using the new tool and there was a hold up getting usernames out to the other developers. This lead to the abysmal  situation of me, and the other developers as they joined, having to keep both JIRA and TFS up-to-date with progress. It also meant that there were 2 places to look for activity feeds (my twitter like group and the feeds in JIRA) and that if a PM made a change it was in TFS not in JIRA. So now the development team are left disliking JIRA because it is just more work for them to do, project management are still oblivious to it's existence and the whole thing has really been a waste of time.

This is actually a common mistake with trialling new procedures and software. If you are trying something new you should just go for it. Don't try out a new system while maintaining and old one because even if you spend 90% of the effort maintaining the old system you will dislike the new one for giving you more work. I see this a lot when I recommend ReSharper to people too. They don't trust the quick fixes and hints so they don't use them. If they don't use them they just see them as cluttering up their environment and completely miss the point of the product!

Visual Studio 2012 - At a Glance

I saw someone else install Visual Studio 2012 today - yes I quite literally mean a glance - and I felt so strongly about it that I am writing this blog post. I am warning you now that this is really just me grumbling so don't expect to be enlightened.

I suppose I have to start with the lovely grey interface that has been the talk of the town since it was released. I know that the world and his wife has already had their 2 cents about this but I really don't understand why they made this decision. I have heard it said that the reason they chose it is because they think that the colourful nature of previous versions is too distracting. I honestly don't know who they were observing to draw this conclusion. It is simply ridiculous. Go into any UK office on a grey day and I would bet that everyone is glummer than they are on a sunny day. I generally see that if people are happier they work better and grey things do not make people happy. So in my eyes all that they have achieved is to make office life that little bit more miserable. Luckily for me I can make it pretty with a plugin so I will survive - although it doesn't change the icons.

Does anyone else see the resemblance?

Loading times appear to be just as slow as, if not slower than, 2010. It also crashed after we opened it the first time so we had to sit through it twice. The creation of an MVC project took a whole second to add each file that would be in the new project before we could do anything. I could tell because there were handy status notifications for each one. I am starting to think that this is a trend with Microsoft products. The main difference I noticed between Office 2007 and 2010 seems to be that the later takes twice as long to load. They have tried to disguise this by giving you status updates on how loading the application is coming along but I am not fooled. But who cares about load times anyway? It's not like we need to open and close Visual Studio all day so I think I could let it off for that.

The thing that I really don't like, and you are welcome to call me petty, is the shouty capitals. If the colourful icons were too distracting then I am sure being constantly shouted at will be too. I really hate them. Luckily you can turn them off so that one shouldn't be a problem either.

So now I have got that out of my system all I need to do is get over it and start using it because lets face it... I don't have much choice.

Computing talks in Herts

The British Computer Society are putting on a series of free talks in Hertfordshire that may be of interest to anyone who lives around the area who works in the indusrty.

Twitter as a Development Tool

Today I introduced the idea of tweeting to our development team at work. We don't actually use twitter but the basic concept is the same. Someone tweets and other reply, like or share. You can also mention topics and people.

It actually works really well in a development team. It is like having a continual start of day that lasts all day. If an impediment or question is raised everyone in the team will see it at once. If anyone has a question they can post it and anyone in the know can answer at their leisure. This means you don't need to disturb people while they are in mid-flow. Even better the team leader knows exactly what is going on at all times and does not need to ask.

Treating bug/feature ids and key words as topics starts to build up a knowledge base that can be searched so that the same questions need not be re-answered. It also helps organise the tweets into useful streams of conversations.

While this is a very new idea to most of my colleagues it is not really that new in the software development world. Issue trackers like JIRA have in built activity streams that allow tagging of users and issues. We are just being left behind because we use TFS.

Team Foundation Server

The company I am working for at the moment uses TFS for source control, project management and bug tracking. Here is a list of things I hate about it (in no particular order):

• The web interface does not work in Chrome
• The My Work list on the web homepage lists all the work I have ever done and I can't seem to change the query.
• When you move PBs and Bugs to different sprints the tasks do not go with them.
• Queries that span multiple projects cannot be exported.
• The web interface is slow (granted probably not all Microsoft's fault).
• When you are looking at a change-set everything comes out at you as a modal popup so you can't get back to the actual code.
• Every now and again the modal popups decide to launch a browser window instead of a Visual Studio one.
• The query windows close when you select close all open tabs.
• If you edit a task while it is in the results of another open query you have to close the whole lot down if you choose not to save.
• 2 users cannot change a task at the same time even if one of them is TFS linking a change-set.
• The combination of the previous 2 is incredibly annoying when you have just checked in and then cannot update your work item as TFS is attaching the changeset.
• All attachments are downloaded with the same file name rather than their actual name - something like 'AttachmentHandler.aspx'
• The reports are really complicated to process and require a 'cube' to create the simple reports that all other systems seem to be able to create in real time.
• There is no support for evidence based scheduling.
• The workflow diagram's layout engine is ludicrously bad at laying out.
• The builds on the build server are given a completely different file structure to those on a dev machine making it much harder to write post build and packaging events.
• There is no in build auto increment version number feature.
• Scheduled reports don't know about the current sprint so have to be reconfigured every sprint.
• You cannot copy the PB number and name in one go - actually I did it once but it was by accident and I can't work out what I did.
• Unit tests have a different structure on the build server so they can't find any of the test resources unless they are embedded.
• The source location on your local machine is logged on the server so if someone else has ever used that machine you cannot check code into the same folder that they did.
• Get latest version is unreliable and I often find that I have to overwrite my local code to get the actual latest version.
• It uses visual studio to work out what changes you have made so actions like excluding a file from the solution ends up deleting it from version control... if I wanted it deleted I would have selected delete.
• It can't tell if I edit a file outside visual studio.
• The source control is not distributed.
• Cannot export certain queries if there is a space in your TFS collection name.
• The build workflow is complicated and not something you can just go in and tweak.
• It seems that every issue about it that I Google gets me to an Microsoft forum that starts off with them denying the problem and ends with 'we are looking into it'.

My friends who work for other companies all seem to think that I am being too harsh on TFS. They believe it's better than what they have at the moment. Their main argument is that it is all integrated but that doesn't wash with me. In my first start-up we started off with mantis bug tracker and SVN and it took less than an afternoon to get them integrated. You could reference bugs in your commit messages and view the associated changes from a bug. Nowadays you can integrate build servers like team city with most VCS and planning applications very easily.

Entity Framework Bug

If you are using Entity Framework in .NET I advise you not to trust it's SQL. Today I discovered that:

joinedSc.NullableBoolProperty != true

Is executed as:

cast(1 as bit) <> [Extent1].[NullableBoolProperty]

When in fact it should be (depending on your database settings):

[Extent1].[NullableBoolProperty] is not null  

or cast(1 as bit) <> [Extent1].[NullableBoolProperty]

Well done Microsoft!
 

Literate Programming Once Removed

So the Jeff's next chapter... Oh just go and read it yourself already.

As I mentioned in my last post the annoyance about Literate Programming is that you write a lot more and end up with the same amount of code (though it may be of a slightly higher quality). This old article puts forward a view very contrary view to the one I made in my last post by saying the comments are mostly just clutter. The funny thing is that until I tried this literate programming thing I would have probably just gone ahead and agreed with him.

I still do agree with basically everything he says. If you write in a language surely you should be able to read it too? If you can't then it is probably because the paragraphs, grammar and punctuation are all in the wrong places. The only thing I will say is that he brushes the times that comments are useful off quite lightly.

1. In the styles of Javadoc, RubyDoc, et cetera for documenting APIs others will use.

Yes it is most important that you document your API methods for external users but they are not the only users. If you write even a private method it is likely that people in your team are going to be using it before long. I would suggest that they would spend less time reading the intellisense than reading the method contents (or asking you how to use it).

4. Explaining why the most obvious code wasn't written. (Design decisions) 

I believe this one should include explaining why any of the code was written in the first place. The best code is already written, it does exactly what it should do, it's been tested and it does not need changing. When I read code I can usually tell exactly what it does at a glance. The hard thing to understand is why it does it. Sometimes there are business rules that are buried in a two year old spec somewhere, other times it is a severity 1 bug fix that never got documented and sometimes it is just a lack of thought when it was written.

When you write your reason for writing a piece of code you validate it's existence. Every bit of code is written for a reason and where better to document that than in the code itself. I think that is the thought that spawned literate programming and that is why I still think literate programming is still worth considering. Usually I find that the answer to this sort of issue lies somewhere in the middle of the two extremes.

Literate Programming

In the next chapter of Jeff Atwood's Effective Programming: More Than Writing Code (spoiler alert) he basically explained that if you don't try to get better at your job you won't. Taking the bait I have read all sorts of internet noise over the last few days and one particular article, which I have unfortunately misplaced, caught my attention. It was about Literate Programming and I immediately thought to myself 'what the fig is that?'

It turned out that some guy named Donald Knuth once had a thought that code was not really all that easy to read when you compared it to a novel (at least that's what Wikipedia said). He reckoned that you have to write the code differently in order to make it easily understandable. You should write it as a narrative where the code is more of a foot note than actual content. A utility application should pull the code out of the novel and reassemble it into source code which can then be compiled. To me this sounded a very convoluted process, especially if you introduce a bug. How would you reference back to your novel from a stack trace? So I decided that I would try and have a go at writing code in a Literate style using no more than regular comments.

My first attempt really turned out to be a small amount of code with lots of narrative comments. Some of the advantages were apparent immediately. Writing code comments as if you were actually writing a novel requires you to explain and justify even the smallest decisions. I found myself writing comments like:

/* First I check the parameter for null because it is good practice and I don't want to get some obscure NullReferenceException later on. */

And:

/* The previous implementation of this involved such and such which was a bad idea because ... */

Maybe I just hadn't commented my code well enough before but I was sure the next developer to change that code would appreciate knowing that we already tried said approach. I even found myself double checking my most basic assumptions because I knew people would be scrutinising my choices in the future. The obvious drawback was that it took me a lot longer to write the code.

Another less obvious advantage was that writing Literately encourages code reuse. If you write a code novel every line of code has to be explained as otherwise it is there for no reason. Things don't tend to happen in novels unless the author has written it. I may not mind repeating a very simple function in a couple of places in code (that's a lie I mind it very much) but I really don't want to be documenting my choices for doing it over and over again - and then maintaining that documentation in the future.

Really though I have only scratched the surface. Don't worry if you are a Literate Programmer and think I have completely missed the point. I am very aware that what I have done so far is simply commenting my code verbosely. There is much more to Literate Programming than lots of comments and I will be diving deeper into it you mark my words. The point is that if I had not read Jeff Atwoods chapter I would still be completely ignorant of it's existence so thanks Jeff.

Cash Back Galore

I having been using cash back credit cards for quite a while now. My favourite is the American express with 1.25% cash back on everything. It is accepted at most petrol stations so at the time of writing that is like getting 1.7p off per litre. If you fill up at Tesco you can get club card points on top of that.

I believe that Amex are charging an annual fee to new customers so if you want a cash back card I would check Money Saving Expert for the best cash back credit cards. You must also always pay the card back in full every month because any interest you have to pay them will be around 20 times the cash back they give you.

Further to this I have recently discovered online cash back sites like topcashback.co.uk. These sites allow you to click through to all the usual internet sellers like Amazon and Play and shop as you would normally. The difference is that when you go through these sites they will give you some or all of their referral fee as cash back. The going rate on these sites seems to be about 3% so if you then pay with your cash back credit card you are getting 4.25% back in total and that is not to be sniffed at. If you are really hard core at cash back you may be interested in Money Saving Expert's cash back site comparison tool.

Just to let you know I am not a financial advisor and this article is not advice. Never rely on cash back as it often takes a long/unpredictable amount of time to come back to you.

The Need to Write

I have started reading Jeff Atwood's Effective Programming: More Than Writing Code and I am finding it incredibly annoying.

In his book Jeff says that one of the reasons for creating stack overflow was to trick developers into communicating with each other. He says that if you do not use your writing skills enough, whether it be through a blog, stack overflow or another medium, you are not likely to be a very good communicator. Further to this he sets the challenge:

If you're not writing because you're intimidated by writing, well, you're likely to stay that way forever.

When I first read this I thought that it was a good point and ran home to write a blog post immediately. Unfortunately I couldn't think of anything to write. So I went onto StackOverflow to impart some knowledge onto my peers.

I do not get on with StackOverflow. As far as I can see it is a platform that allows lazy people to get their work done by those with too much time on their hands. It seems that 90% of the content is made up of two types of questions:

• The ones written by people who just don't know how to code and haven't bothered to learn. These can be answered by just about anyone for easy rep.
• The ones about weird and complex bugs or design decisions that other people have to go away and investigate. I have better things to do than investigate other peoples bugs.

On the other hand the remaining 10% is a gold mine of information for developers so I feel bad about knocking it. In any case being neither lazy nor frivolous with my time I could not muster more than a couple of answers. This started to get me worried. Maybe I am not a good communicator. If I cannot find something I enjoy to write about then I will be stuck like that... forever...

Luckily for me it is much easier to moan about things than to come up with a constructive article and my growing annoyance at Jeff for setting me a challenge I was not able to complete gave me the inspiration to write this post!

Amazon Discounts

Just found this page that will let you find all the best deals on Amazon. Just specify the department and the amount you want discounted and it will show you what's up for grabs! Amazon Discounts

Tesco Value?

Either tesco are not very good at maths or they don't want you to buy lynx.
If this really were £2 per 100ml it would be £5 not £1.

MVC DataGrid

MVC is a fantastic improvement on the old ASP.NET web sites. It completely gives you back control of your website and no more ViewState! The one thing that does not come out of the box in MVC is a datagrid implementation. You can create tables in no time at all but when you want to start paging, filtering and sorting it starts to seem a bit like hard work compared to the good old ASP.NET DataGrid. But do not despair this jQuery grid can be up and running in no time.

In its simplest form you can just dump all your data in a html table and call the datatable method. But it is also very quick to implement server side paging, sorting and filtering too.

The grid is fully skinable with default styles for paging, sorting and a throbber making it very quick to develop with. It also supports custom column rendering to suite your every need, though if you are using server side you have the option to do it on the server.

DataTables is made available under both the GPL v2 license and a BSD (3-point) style license. You can select which one you wish to use the DataTables code under.

Resharper Plug

If you are a .NET developer and you do not use ReSharper you are going to get left behind in your field. If productivity were measured in key strokes and mouse clicks I would say that ReSharper has at least quintupled my productivity. I am sure I will rant about it a lot if I continue to write on this blog so I will try to be concise but here is an example to back up my above statements:
Using an object that is in a different namespace

I have an object, lets say BowlingBall, and I want to use it in my new code.
Without Resharper

1. Type the full name of the class 'BowlingBall' in your code block and look for the Visual Studio icon to add an import statement.
2. Wonder why it hasn't come up and get frustrated.
3. Delve into the solution explorer to try and find the class.
4. Finally find the class and see that the person who created it has made an unfortunate typo and that it is actually called BowelingBall - I will leave renaming for another day.
5. Curse the idiot who made the typo.
6. Return to your original code file and correct the typo.
7. Use visual studio to add the relevant import statement.

Around 25 clicks and strokes assuming you know precisely where to find the file and the solution explorer is pinned.

With Resharper

1. Type 'BB' into your code block.
2. Press Shift+Alt+Space
3. Select from the short list of classes displayed (also including BouncyBall and BreadBoard).
4. Laugh at the unfortunate typo and those doing it the manual way.  

About 6 key strokes.

Man Riding a Pig

In clearing out my old files I stumbled across this image which I created to show my flatmate that Britain looked like a man riding a pig. I thought I would upload it in case I need to explain this theory to anyone else.

Wellies

In 2011 we had a lot of snow and rain and in honour of the muddy dog walks a pair of wellies in a rocky road pile of mud seemed appropriate.

Tilly

In 2010 I created a perfect likeness of our pet dog Tilly in cake form.

The Fiesta

In 2009 the cake was another work of art if I do say so myself. Its even got windscreen wipers and door handles, though I couldn't quite manage the registration plate.

The Dalek

I made this cake for my girlfriends birthday in 2008, she likes chocolate by the way! It's not my recipe but one I tweaked having found this fantastic article at Chocablog.com. Is hard to appreciate the size of the cake in this image but to give you some perspective the base (with the maltesers on) is a chocolate sponge cake.

Airbox Aerospace

I have just been reading that the Airspace Aware device is still winning awards nearly 2 years after its launch, the latest being the Honeywell Bendix Trophy for Aviation safety.


It has also won the Royal Institute of Navigation’s prestigious award for Technical Excellence, been recognised by the CAA as an outstanding contribution to flight safety and been credited with a major role in reducing Airspace infringements.


All in all I'm pretty proud of that little project.

Lack of Posts

Obviously it was a really great idea for me to start a blog seeing as I have so much to say!