HackDay
On Friday we had our first Hack Day. Chris and Pete had heard of a company that took every third Thursday, downed tools and did a project for a single day. This didn’t have to be related to work, had no boundaries on scope and only had 3 rules, Nothing to put the Co Made name into disrepute, we can’t just disappear down the pub and we have to work on the project together.
Prior to the day we set about talking about what possible projects we could work on and left the table thinking about lots of different things that we could do on the newly christened Hack Friday. We had to think over ideas and turn up on the morning fresh as a daisy ready to take on a new challenge, with a plethora of ideas in tow.
The day went as follows:
9:30 – After a bit of admin and the usual morning procrastination before everyone has finished messing around with coffee, tea and overnight admin, we sat down for a meeting to discuss our ideas.
We wrote all of the ideas about what projects that we could do / start today. Although I am not going to go into the details of the ideas, we really did have some interesting ideas. Of these 15-20 ideas that were discussed with a brief presentation of what the idea consisted of, we did dot votes on the ideas (three votes each to distribute as each individual sees fit, then the winner is the one with the most votes) and decided on a DataBuilder builder.
Gary has been a massive advocate of these for a while, if you haven’t heard of them in the past then they are simply a wrapper class that you can use for creating objects that you wish to test. The idea is that the wrapper assigns default values to the items that are required as a bare minimum to make the object valid. Each property then has a method that is nicely named to allow you to create objects in very pretty syntax that is very readable and will allow the developer to create objects that satisfy the minimum criteria by writing something along the lines of:
var x = new ATestClass().WithAnId(123).WithAName(“Item Name”).Build();
We all liked the syntax, however creating the data builder class is fairly laborious and tedious and something that quite simply should be able to be auto generated, as approximately 90% of the code is derived straight from the class that it is building for.
The other thing that was decided in the idea phase was that we should do this as an experiment in Mob Programming. (see here http://pichdude.wordpress.com/2013/09/15/get-a-good-start-with-mob-programming/ and here http://www.youtube.com/watch?v=p_pvslS4gEI for more details)
10:30 – Tea’s in hand we broke into different groups to research which direction we should take for the day. One group went and researched doing this as a Visual Studio plugin and the other started researching how to develop a ReSharper plugin.
After 50 minutes we decided that we needed to reintegrate the group to a mob and decide on a single direction. After the allotted time the VS group had a menu link to run some code and not much else. The resharper group had a plugin running that included a context menu that popped up an alert box.
The executive decision was made to go down the resharper route as we wanted results within the day that we had and it was concluded that the resharper route would produce a working result faster, even if it limited the market place once this item has been created.
11:30 – Tea’s in hand and my desk de-ergonomised to a disgraceful extent, we downloaded the SDK for the correct ReSharper version that we had installed on the communal machine and got on to developing something (what we were all waiting for!).
We started down the track of getting a context menu to present itself and start looking at what we were passed as a default to the method when we right clicked and selected out new item.
This was all well and good, we had a guide that Phil had found whilst researching stuff which gave the gist of creating a plugin for ReSharper, however we soon realised an issue that developing a ReSharper plugin for the Visual Studio is not so simple when you are using Visual Studio to test the plugin.
When you have a build that you want to test and see what it does on a web project, a quick F5 is all that is needed (maybe with a hard refresh on the browser) and it takes you straight to the latest version and you can instantly see the changes you have made. When developing a plugin for ReSharper in order to test it you need to replace a file in a folder within the ReSharper install. Easy, post build step on the project and it’ll just replace the file and we’ll be able to test it – WRONG! The file is in a protected location, so launching VS in admin mode worked the first time, however we swiftly realised that if we do that, ReSharper still has claim on the file which won’t release it without stopping Visual Studio. So everytime we had to rebuild we had to go through the arduous process of stopping R# within VS, closing VS, deleting the file fromt he R# directory, restarting VS with admin privileges and then allowing R# to run again. LONG!
This immediately put a massive hurdle in the way and made development progress slow.
After a little bit of time playing around with this with the stupidly long build and getting nowhere, we went to add a new project for some reason and found that installing the SDK had given us a load of templates that we could use. This allowed us to have a working version almost immediately that we could then build on and make a leap forward in the project.
15:00 – By this time it was about 3 o’clock in the afternoon, we continued developing trying to get some code to be rewritten with code and put into the class that we have selected with our R# clicks.
In the end we got to the point where we could programatically create a lump of code that resembled a class that had been implemented by creating an interface and changing it, and we were able to add a couple of properties to it. Exciting stuff eh?!
Take-Aways from HackFriday
After every different and new activity, it is fairly standard for Co Made to run a retrospective on the events. We had an hour to deliberate what had been gained from our day so that we could decide whether we would do it again and if so what would make it better if we were to do it again. It builds on the old adage about hindsight being a wonderful thing, however we can then use all that lovely, wonderful hindsightedness to make things more productive and generally better for everyone involved.
These are our retro findings …
We should have either more time or make the project more realistic to be able to do it in a day – Everyone was fairly disappointed that we didn’t have some kind of finished product by the end of the Hack Day. Certain things could have been done quicker to enable more time, but the overriding theme of this was that we should have had a Pivot/Persevere mentality and possible enforced this by making a commitment to certain review points throughout the day.
Sprint format in a day – This would not only benefit the developers with practice for everyday development, but would help us to have kept the day structured. With a BLR and a sprint review and a demo at the end we might have realised earlier that we were flogging a dead donkey earlier on in the day and changed tack to a more reasonable and productive pivot.
We learnt a new technology – Having spent the day working with ReSharper we knew certain parts of it and managed to get things working within the plugin that we were trying to develop, however the bottom line was that the documentation for R# SDK is appalling and it is a wonder anyone can program plugins for it.
The combination of the project and the learning of new technologies was actually a lot to take on for just one day, and in hindsight the project was doomed – however we now know that developing in R# is a bit of a pig and that if we were to decide that we wanted to make a new R# plugin, we would definitely think twice before committing to it.
Learnt about and experienced Mob Programming first hand – This is something that we had previously discussed being a way we could tackle small projects and gave us some first hand experience with this to enable us to work out how well it would work for any subsequent projects. The general consensus was that it was ok, it was good for learning and observing the way other people develop, however it was considered a bit of overkill with a bit of duplication at points and it might take a fair bit to get used to. This is something that we want to put in a different blog post, so I won’t go into it too much at the moment.
More warning needed for idea percolation – Owing to the fact that Chris and Pete only decided on doing this on the Thursday afternoon, we only had an evening to think about things. It also then meant that the ideas were very much individualised – lending to people liking their own ideas the most and making the decision making process longer than it should have been.
We discussed about whether we should make the decision on the day or before the day. The idea of the project being all in one day is fairly central to the proposed ethos, so we decided that it should be on the day, however we should have time to lobby our ideas and try and gain support before the day so that the decision is easier to make.
Do we do HackFriday again? – Definitely, the day was fun, challenging and brought us out of our standard project comfort zones, forcing us to collaborate and build on the foundation of what the company prides itself on being able to do well, communicate.
The idea of doing it again on a Friday was not as popular. We all agreed that if we had been closer to an end product then we would have liked the opportunity to finish it even if we had to stay later than we normally would have done; Friday’s don’t lend too well to staying late as we all have drinking or driving to do.
Conclusion
As a result of this activity we all learnt something new, tried something different out and got some new experience with a new technology and a new way of working. It was unanimously met with excitement and we all had a good time and thought the idea was excellent. As a company we would like to make it so that the time can be afforded to the team for the Hack Day at least once a month.
If you were looking to do this for your company, selling it to the powers that be could be a tough sell, however if we were to have a result at the end of the day – i.e. if the DataBuilder builder had been finished, we would have had a product that could be useful and would be able to be sold / distributed to allow other people to start working in a similar way – this would have raised the profile of the company, potentially made them a little cash to offset against the time spent on the project.
This product itself would have automatically generated a chunk of code that is boring and laborious to create, but is immensely useful for everyone using it – which would have been a huge benefit to the company in developer time. As a quick example we have a specific class that we created a data builder for and it took approximately 2 days of my time as it was huge and I didn’t really know how to do it at the time, multiply this by the 5 developers and you already have the time we have expended on HackDay, with this tool it would have been done in less than 10 seconds. Plus, I haven’t even mentioned the amount of time it saves in creating a MVP class that can be used in testing without looking up what needs to be put in every time and having to write all of that code too and then theres the time it takes for new devs to understand what is going on that would be dramatically shortened thanks to the inherent increased readability of the code.