Dream big in 2011

23 December 2010

The EndGame Moleskine

Nothing shows potential like a blank piece of paper.

It can hold words, thoughts, sketches, eureka moments, hard won conclusions.  Given the right treatment it can even fly across the room.

So … what could happen if you filled the blank pages in this journal with your words, thoughts and sketches?  If you dreamed for a bit, then picked up a pencil, what could you design?  What is waiting to be built?  What investment could lead to something great?

Dream big in 2011, then design well, build well, invest well.

Happy Christmas and God bless.

Andrew, Jamie and Simon.


SCM with Accurev

3 November 2010

Starting a new software project (or company!) gives you the opportunity to have a clean slate with the tools and processes you’ll use. Starting EndGame – I figured that to be genuinly agile, we needed to have agile tools, not just agile ideals. I adpoted the YAGNI policy when it came to tools and our development environment and only introduced a tool when we absolutely needed it. It took us 5 months before we needed an issue tracker – until then, google docs did the trick.

One thing we did implement on day 1 was AccuRev, and its changed the way we build and deploy software. AccuRev is a software configuration management” system that allows an agile approach to development and lies at the heart of our entire development process. I’m going to describe how we’ve deployed AccuRev across the 10 or so projects we’ve worked on this year, but first – a few definitions for the pre-AccuRev readers:

Depot: a depot is like a repository and we have one per product/client. A depot represents a walled development environment – allowing product and client work to be kept separate from other depots.

Stream: Accurev has streams instead of branches. Streams represent your work environment, with stage downstream from production and development downstream from stage. To push a change package to stage, you drag it from the development stream to the stage stream, and like-wise to push it live.  All changes flow automatically downstream, so its like an automated merge between branches everytime you promote.

Promote: like doing a check-in, promoting pushes your source code upstream. In the first instance, you promote to the development stream you’re working in, and from there we promote to a staging stream, then to production.

Change package: a set of source code files that have been changed due to a work issue.

Here’s how we’ve got it working for us:

1. The roadmap
Everything starts on a whiteboard or with user feedback and makes its way into a backlog. From there, we plan out our time across various projects and clients using Hive – the project scheduling tool we’ve been developing this year. Hive allows us to plan out milestones and high level goals and make sure we’re not over-resourcing.

Using the Hive API, we then pull out the milestones to provide a high level roadmap on our project dashboard.

2. Work and Issues
Once we’ve decided on high level goals of the next cycle(s), we convert it to work/enhancement/defect issues using AccuRev’s built in issue tracker – AccuWork. We looked at whether to use a third party issue tracker and integrate it, but Accuwork is quite a powerful system and is fully integrated with AccuRev. To provide an integrated project dashboard, we built a UI over Accuwork so that work issues can be linked to hive milestones and hooked into project documentation. It also allows our project dashboard to track progress in a cycle of work done vs budget.

3. Documentation
We’re pretty light on documentation – most revolves around a whiteboard and visual designs, however there’s always need for some level of written requirements and specifications. Within our project dashboard, each work issue can be linked to a page in our Wiki, so the spec is only one click away. The flip side is that when viewing a page in the wiki – all related issues can be listed. Once in the wiki, each page is has a variety of related pages, so its easy to jump between related specs. Our wiki uses Zoho docs and spreadsheet editors inline to provide an OK rich editor.

4. Accurev streams
Streams are where Accurev really stands out. For each product, we setup a new depot and create streams for production, stage and dev. Because we’re a small team we usually only need one dev stream, but Accurev supports multiple downstream and parallel streams. Development happens in personal workspaces and work is promoted against an issue number in to the dev stream. From there, we can promote issues to stage and from stage to live. By promoting an issue, it pulls all source changes with it. This allows us shift a change package associated with a single issue from stream to stream just with a simple drag and drop. We may have 10 change packages on stage and pull just 5 to our release candidate site. After another check of the RC, those five issues can be drag-and-dropped to the production site to deploy them.

5. Promote triggers
When we promote to dev, stage, or live – an Accurev trigger fires automatically and updates the status of all issues that have been promoted. When promoting to stage or live, release notes are created with a list of issues and promote comments (and posted automatically to our Yammer feed and project dashboard). This keeps the issues up to date and also provides a record of what we’re working on – again, giving customers more visibility of progress on their project.

6. Automated build and deployment
Automating builds and deployments changes the way you work. We use CruiseControl.NET to deploy to our stage and live sites and it works beautifully with AccuRev. Because of AccuRev’s streams, CC.NET is only deploying the change packages in a stream. So, where you typically might have an integration branch that you’re developing into, rolling to stage and eventually rolling to live – in AccuRev you’d have three streams instead. The live site is built and deployed against the live stream, so will only include change packages that have been promoted to live. Same for stage. So, building and deploying a site is now independent of what developers are checking in – its all about what is being promoted upstream (and sometimes demoted again!). For a small dev team, we’d never go to the effort of separating all these steps into separate branches, so AccuRev gives us a process that is incredibly robust without massive overheads.

7. The project dashboard
I’ve mentioned a few times about the project dashboard. This is a web app that we’ve built that pulls everything together and gives visibility to the team and the customer. It includes:

– Trackers of cost vs budget, pulled live from our time tracker (Freckle)
– Trackers of work completed, pulled live from AccuWork
– Trackers of google analytics, twitter, sales metrics and usage metrics for each app
– Summary of the roadmap, pulled live from Hive
– Work issues, pulled live from Accuwork
– Wiki
– Status updates

Providing some confidence around price and a roadmap can be hard with an agile process. At the beginning of a project, or a cycle, the client usually wants a price and we plan it to the best of our foresight. The question then becomes whether this is a fixed price or an estimate of time & materials. We work with a mixture of both – typically a fixed price for a small project that is a single dev cycle or a license and estimates for the larger projects. This raises the issue of how does the customer have some confidence that they’re going to get what they are paying for. An approach of “we’ll work down the prioritised list until we run out of budget” is fairly risky and relies on trust. This is where our project dashboard comes in as an attempt to give the client full visibility of what’s happening in the project – in realtime.


That’s a snapshot of how we do SCM as of 3 November 2010.  I’m sure it will be improved by the beginning of 2011, if not by next week.  If you haven’t used a system like Accurev before, I can recommend joining one of their webinars and seeing just how important it is to have agile tools as well as agile intentions.  www.accurev.com.

What we’ve been up to this year

14 October 2010

I haven’t talked much about the projects we’ve had and have on the go this year – but I intend to!

In the meantime, we’ve finally got ourselves a simple website (minty!) that highlights a few of the projects we’ve done this year. If you’re interested, have a look here: http://www.end-game.com.

Managing Javascript & CSS source files

3 September 2010
Early on in the development of Hive, we realised we needed a better way to manage javascript and CSS. As the javascript files got bigger we started having source code merges (shudder) and we occasionally would ship a version with debug code still in it.

There are some really good systems out there for optimising javascript & CSS, but we thought we’d start simple and see how it went. We’ve now rolled this system out over four applications and its working great.

To avoid source code merges, small and frequent check-ins are good, so using a source control system like Accurev where each developer has their own workspace is perfect. Its also easier to maintain code and avoid merges if you can have one javascript class per file – but you end up with lots more files, which can make loading a page slower.

To solve this, we create as many javascript and CSS files as we need, then merge them on the fly. This allows a single url /scripts?version=x to download all required scripts and an XML file manages which scripts will be merged and returned. We also threw the Yahoo YUI library in there to minimize the javascript and CSS and reduce the overall size.

The other issue we were having was with debug code, swapping between debug and production libraries and remembering to remove console.log commands. To solve this our XML file specifies a target, so the web.config can control which javascript files will get included. We also use some REs to strip out debug commands on the fly.

Overall, a dead simple solution to solve 5 problems:

1. More files means easier to maintain and fewer source control merges
2. On-the-fly merging means only one javascript & one CSS per page, resulting in faster page loads
3. Minifying the code means smaller javascript and CSS
4. Stripping out console.log and other debug code means we can leave it in and not worry about it in production
5. Swapping between debug and production versions of libraries is automatic

We can highly recommend the YUI compressor for .NET – which we use in this code snippit:

public string GetJavascript()
        // Get the files from the XML index
        List<string> scriptFiles = GetJavascriptFiles();

        // Load the contents and put into a string
        var javascript = MergeFiles(scriptFiles);

        // Optimise
        if (_Target.ToLower() == "live")
            // Strip out console.log, etc
            javascript = RemoveDebugCode(javascript);

            // Minimise using Yahoo YUI
            javascript = JavaScriptCompressor.Compress(javascript);

        // return the result
        return javascript;
    catch (Exception e)
        return e.Message;

Business Cards!

1 September 2010

We’ve been in business for 7 months so its about time we got some business cards printed, especially since we’ve finally settled on a logo!

The company is called EndGame, so for a bit of fun we thought we’d put a maze on the back of the card.  The point of a maze is to get to the end, ie that’s your EndGame.  Beautiful.  The logo is sort of half isometric, so we figured the maze needed to be isometric so that it could join up with the logo as the finish point.

Anyway, one thing led to another and soon I’m playing with a depth-first algorithm to create the maze, a winding number algorithm to keep the maze inside the right space and drawing lines at 30 degrees in SVG.

But that wasn’t enough, if we can draw one maze, then why not draw 1,000 mazes, so every card can have a unique solvable maze.  Everyone’s EndGame in life is different, so this seemed like a good idea.  To quote our printer, “that is out there and very different haha “awesome” and no -one has ever done this in my 20 + years of printing so your a first … “.

That’s it.  If we’re the first, then there’s no going back.

Hive in BETA

26 August 2010

Its a relief to see Hive finally out there in BETA and to see the feedback starting to flow in.  Hive is a project we’ve been working on this year and has been a lot of fun.

Hive is a SaaS app for scheduling projects and people.  Its perfect for people with a team and a bunch of projects to manage.  Its based on the premise that most people hate project management and hate project management tools even more.  Hive lets you do in a visual, fun and collaborative way what people revert to spreadsheets for – to get visibility of what projects are on the go, who is working on them and to make sure you’re not over (or under!) capacity.

Hive is built as a one page web app and its always fun to run it in full screen mode and have people not believe its a web application.  We’ve had a lot of fun working with Darryl Gray who designed this stunning application.  Its been nice to have a project where we can make use of  the shiniest new CSS and javascript techniques with lots of drag-drop and animations, integrating SVG and wiring it all up to give a seamless user experience.  Seamless except for the bugs of course – but that’s what a BETA version is for!

As far as features go – the best of Hive is still to come.  Under the hood we’ve implemented live collaboration and its quite fun watching another user’s changes animate on your screen (this isn’t available in the current version).  We toyed with allowing viewstate changes to be sync’ed across users too – which is fun, but I’m not sure if its that useful.  Because Hive is based on an event model, we’ll be adding undo and redo support soon, but I’ll have to save details of that for another blog post.

We’ve also got some great reports, sharing, publishing and integrations planned, but the most important features to add going forward will be the ones asked for by users, so make sure you sign up at www.tryhive.com, have a play and send us your feedback.

p.s. The screenshot above features a slightly older version of the UI.  The latest version is even nicer.

Finishing – part 2

11 August 2010

“The end of a thing is better than its beginning, and patience is better than pride.”

Put another way, finishing is better than starting.

So true and yet so hard.