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.