Hi, I’m Ben and I just completed 7 months of work experience as a noobie software developer at Global-Roam.

I have to be honest: this is the first blog post I have ever written. It’s probably not very good and I know that it’s too long. Nevertheless, I promised I would compile a post on my experiences at the company, and when I make a promise I always deliver (at least 50% of the time, and anyway, Todd threatened to mark my “post on the blog” task as failed if I didn’t). Hopefully this chronicle of my adventures at the company (a tragedy, mostly) will be at least mildly entertaining, capture some of my insights, and give a sense of what it’s like to be a Global-Roamer (at the moment anyway – it’s changing fast). It is a great place to work if you are motivated, open to learning and trying new things, love customers and have a burning desire to be remarkable (like my colleagues, who seem to believe they are a collection of spies, wizards and gods that make it rain – just check their business cards).

My journey began on a sunny day in November 08 when I walked through the glass doors of Global Roam’s office, and into my first real job as a software developer. On my desk sat my two new widescreen monitors, a quad-core desktop, my very own business cards, a copy of The Seven Habits of Highly Effective People (by Stephen Covey) and a requirements document. Not bad! A sheet of glass separated me from the rest of the development team (5 developers at the time, though most of them were either on holidays or working from home that day).

As the requirements document sitting on my desk proceeded to tell me, my job was to build a replacement for the company’s existing licensing system. This system was to be a small component of the much larger BUSINESS. MANAGEMENT. SYSTEM. (BMS), a semi-mythical construct that would automate all processes conceivably possible for the company (and probably the entire world). My heroic colleague, Kim, was responsible for architecting the system and kindly delegated the implementation of the licence system to me. The licence system was the first component to be developed beyond a concept, and so I had grand illusions that my design and implementation would influence the remainder of the project.

From speaking with everyone and reading the document it soon became clear that the new licensing system needed to be composed of three parts:

1. A library written in NET 1.1 that would be included in our installed software to enforce licensing. It needed to present the same interface as the existing licensing library so it could be swapped in easily.
2. A website that clients could use to manage licences and which Global-Roam staff could use to modify most aspects of the database without risk of destroying everything.
3. A licensing web service for handling all the business logic and data persistence.

All other decisions, it seemed, were up to me. The previous largest program I had ever written was a UNIX shell (or maybe that flash game I wrote back when I didn’t know what a function was), so I was overwhelmed, to put it mildly. The plan was to finish the system up before I returned to uni in three months.

It is important to point out at this point that my boss, Paul (who also happens to be the CEO), is very big on self-management. Which is great, if you know how to manage yourself. Not so much for me, whose management style mostly involves pouring vast amounts of time into something until it’s 5x over the word limit, exceeded my imaginary time estimate by 300% and generic enough to end poverty and pwn at WoW. Which is why asking me to create a large unknown system all on my own is probably a bad idea – but I was quietly hopeful that this was my chance to turn over a new leaf.

Young and naive, my first step was to dive into the old system. With barely a dozen functions in its web service interface the system was hardly menacing (although in that regard it was a bit like an iceberg) but it will always hold a special place in my heart as my first official exposure to legacy code; it was half a decade old, undocumented, half-written in managed C++ and weighed down by some unfortunate design decisions. It was also rather tightly coupled to the company’s order system (probably something to do with the order system being hacked into it). Needless to say I didn’t get very far (I just needed to understand the code interfaces), but from the periphery I got the sense that it was very impressive. To be honest, I was more than a bit intimidated by my predecessor’s l33t design skillz.

The smart thing to do next would have been some of that requirements elicitation that I kept hearing about at university; I needed to figure out what my clients wanted (that would be Paul and the rest of the development team, and probably some actual people out there in the real world as well). Unfortunately, as I mentioned earlier, Kim made the unwise decision of providing me with a semi-complete requirements document and a database (what was she thinking!). This made it very clear to me that all of the requirements that needed eliciting had already made themselves elicited. All I had to do was write code and maybe draw some pictures. OK, I’m not really that bad, but it was definitely an influence– the last thing I wanted to have to do during my time away from uni was write a big boring document about problems and motivations and other esoteric things (as it turns out, this probably isn’t what should go in such a document, but I didn’t know that at the time). I wanted to make something! Besides, I didn’t know the first thing about data persistence or web services or security or designing something with layers, so I could hardly do a good job of requirements elicitation or design; I had no idea what I was talking about. My only course of action was research.

And research I did. I learnt about data access layers and asmx Web Services and Windows Communication Foundation (WCF) and DataTables and serialization and Object-to-Relational Mappers and Entity Framework and a whole host of other technologies. I thought about when to throw exceptions and how to write modular business logic and the best way to structure the different components of the BMS (like the licensing and order systems) so they could chat to each other easily and efficiently. I didn’t just research of course; I also prototyped. I got .NET 1.1 service clients talking to .NET 3.5 WPF web services and then took it to the next level by having exceptions serialised automatically. I modified the Entity Framework so database queries could be decomposed and reused and included Microsoft’s Enterprise Libraries to leverage their configurability. I prototyped everything I thought the licence system, and the BMS as a whole, would need.

This work took months. Throughout it all I had no concrete idea about the non-functional requirements (ie. the importance of efficiency, scalability, security, etc.) of anything, so I considered everything. This was obviously a big mistake. Unfortunately, my perfectionism and indecision combined so that my decisions were like merry-go-rounds – every day the pros and cons of a different technology or design seemed more appropriate. It was fun at first. But it left me sick and disoriented. In hindsight I really should have consulted with the entire development team, made a decision and stuck with it. There would have been problems with the decision, but as I now know, that is just part of software development: you don’t know the best decision to make until you’ve finished.

To feel like I was actually achieving something during this period I began implementing the one thing I had no choice about: the library that would be used by installed software for licensing. I had to implement it in .NET 1.1 – oh the humanity! – and then gut the existing C++ licensing dll and make it call into the new library using COM. The one upside of this was that I got to use the adapter pattern (from GoF) which made me feel smart. I also started documenting my ideas in a diary and using a calendar to log my work. I even spent an hour adding tasks to the company’s task management system (JIRA) before I gave it up as impossible.

This entire period was incredibly depressing; I knew I was doing it wrong, but I didn’t know how to fix it. It wasn’t particularly helpful that during this initial work experience all the developers were product managers (so they were focussed on developing their own product), Kim was struggling to gather requirements for the remainder of the BMS, and Paul was focussed on marketing. Everyone was busy. Nevertheless, I really should have asked for help sooner; I should have presented my ideas to the developers and asked them to tell me what to do. It would have been the only way to stop me from bouncing from one idea to another. Unfortunately, this didn’t happen. It got to the point where I asked Paul to stop paying me because I felt like I was achieving nothing. Of course, he didn’t stop paying me. Instead, he encouraged me and gave me some pointers on how I might manage myself better.

After three months of this cycle it was nearing the end of the Christmas holidays and university was about to start again. Rather than smack me over the head and send me on my way, Paul asked me to defer for a semester and continue work; after all, I was in the best position to finish the licence system. Sadly, this probably wasn’t a great idea, and I’m sure if Paul had been aware of the full reality of the situation he would have tried a different approach to developing the licensing system. This wasn’t deliberate deception on my part, but I’m sure it didn’t help that at any point over my 6 months of work experience I genuinely believed that I could complete the remainder of the work in the next month (which is what I reported at meetings). I could kick myself for being so unrealistic.

Nevertheless, now that I knew how one might go about building such a system I was in a much better position to properly figure out what the system needed to do and what the priorities were. I really should have just started again. Unfortunately, despite this realisation, lack of experience and a large helping of panic got the better of me. So I did the worst thing possible and started implementing on top of my prototype designs; I was running out of time, and anyway, I knew how to build the system (I had my prototypes to prove it). And so the cycle continued.

The only way I knew of to cope with so many of the BMS components being unknowns was to go all out with modularity. I split the new database up so the licensing data was on its own, created a code library for the licence system and stubs for the future systems and then broke these libraries up further into layers which I gave special names like “Business Access Layer” (it encompasses the Business Logic and Data Access layers – cool huh?). I hid the entire BMS behind a collection of web services and modified the installed code library to call into the service.

Throughout this process Kim, Paul and I had many long meetings about the licence system. After these meetings I would diligently update the databases, and the data access layers, and the business logic, and the web services and the installed code library to reflect our new ideas. And then one day I tried to make a change and realised my current architecture made it impossible. I almost had a panic attack on the spot. Unless I wanted to be working on the system for the rest of my life and defer my studies indefinitely I was really running out of time now. Then again, all I had to do was redesign everything.

Resigned to failure and with barely a month left (which was paradoxically more than enough time) I nevertheless began completely redesigning the backend so that each component of the BMS was completely isolated behind a web service. This required new technologies and new designs. I returned to university and still kept working on it. Finally, Kim stepped in to ease my suffering and told me to stop. Right up until the moment when I dropped working on the licence system and focussed once more on university, I was sure I would complete it. But I never did.

The whole experience was very difficult for me – I had never failed at anything that badly before. I did however learn an incredible amount about myself, and what not to do. What are some lessons from my failure? Well they’re all common sense really:

• Don’t be crazy. Also, don’t hire crazy people.
• If you’re an obsessive perfectionist like me, don’t be. Pragmatism is the way to go – you can’t get everything perfect straight away on a system that is so big system.
• Seeking constant feedback and criticism from people who know more than you is generally a good idea.
• Breaking work down into manageable tasks that can be estimated and consistently delivered can improve morale, relations with your boss and the chance of actually succeeding.
• Having a clear scope to your work and a manager that can offer feedback and accountability is incredibly beneficial, even if it does mean that you could be fired.

Ultimately my failure can be put down to lack of experience. Perhaps someone else in my position could have succeeded where I failed, but it probably wouldn’t have been very much fun. Amazingly, everyone at Global-Roam was incredibly understanding, even apologetic.

In fact, Paul was generous enough to let me return over the Christmas holidays of 2009-20010 for 6 weeks so I could complete my work experience requirements. Fortunately he didn’t ask me to continue developing the licence system, which would have worked out badly for everyone involved. Instead, everything had changed.

You see, while I was away the company had something of a renaissance (or possibly a revolution, though nobody’s head was cut off). From what I understand, a number of factors catalysed the change: the development time of NEM-Watch v8 blew out, the team was becoming increasingly concerned about efficiency and code quality, and growth was not meeting Paul’s expectations. The change began with “Autopsy 1” and then a few months later “Autopsy 2” (though don’t worry, nobody actually died) which were periods of significant self-reflection within the company. The outcome from my perspective was that Global-Roam started using “agile” techniques, began getting processes in place to improve efficiency and communication, and initiated the task of bringing more experience into the company through strategic hires (like the GM DDD WCW, ROFL).

The upside of this was that I got to work in a professional (and non-dysfunctional) team for the first time in my life. When I began, the team was just beginning to try out agile (extreme processes) and had completed perhaps three iterations. I knew all about fabricating tasks and burn-down charts from using scrum at uni, but I was keen to see if agile was any better in real life. The team had decided on the agile processes they felt would have the most immediate value: planning and testing meetings, correct usage of source control (yes, you do need to check things into source control), breaking work down into tasks stored in an agile project management program (JIRA or “JEE-RA”), developer sign-up to tasks, and time devoted to testing (it’s amazing how many more bugs you find when you actually test). This was a big change from each developer managing their own product – now only Stephen and Adam were managers – so there was lots of discussion of what was working and what wasn’t. We even had Steve Hayes, an agile guru, come in and help us out.

During my 6 weeks of work the team completed five super-short iterations: four on NEM-Review v6 and one on deSide. And boy was it good. I often times found myself actually having fun. I got to contribute ideas, choose tasks, chat with the other developers about solutions and then implement them. Every day I actually felt like I achieved something. I even got to play with fun stuff like threading issues and designing interfaces. Being able to deliver customer value each week provided a rather stark contrast to any work I have previously experienced (I’m looking at you, licence system). There was a real buzz in the air at work now, and I think everyone was excited with all the new changes.

A big change I haven’t mentioned yet is that we also decided to only have meetings on Fridays. Theoretically this was to help the more managementally challenged of us who can’t cope with a more flexible timetable. The truth is that our meetings were going for so long that they were at risk of overflowing into negative time and exploding the universe. With a single day of meetings there is only so far they can run overtime before it gets dark outside. And when Paul walks in and asks “What is your definition of creativity [and the meaning of life]?”, you know that it’s probably going to be a long meeting (although with Todd, Stephen, Adam and Paul all in the same room it’s probably going to be pretty entertaining). We also decided to have learning plans (a souped up version of the book reviews we used to do each week) which Paul has talk about extensively in other parts of the blog. In short, multi-disciplinary upskilling is very important at Global-Roam. As it so happens, you are being tormented by me right now because my task was to write blog posts to deal with my “performance anxiety” as Paul so nicely put it.

So anyways, I should probably stop writing now! All up, working at Global-Roam taught me a lot about myself, about software development, and about other people. I had some difficult times, and realised that software development may not necessarily be everything I want out of life. Nevertheless, I hope my experience with the licence system also contributed in some small way to making the company better (like no longer hiring crazy people). The group at Global-Roam are incredibly talented and fun to work with and it will be sad to leave. Since all us investors aren’t lying on a beach in the Bahamas yet there’s probably a long way to go. But give the Global-Roamers 10 years and I’m sure they will get there. I wish them all the best!