Take a good look at any big IT system and you can usually trace its roots to one of two places. The first is the one that all of us like to work with: the Greenfield project. In essence this is brand new work that has been born out of a requirement that didn’t exist before or a complete rethink of a current implementation. Talk to any consultant who’s trying to sell you some new tech and you can be guaranteed that they’ll be looking to sell you a greenfields solution, mostly because it’s cheaper and much easier for them to implement.
Sadly, and especially for those of us employed by the government, the majority of the projects that us IT guys will work on will never be greenfield situations and will usually be encumbered by some form of legacy system. This poses greater risks and constraints on what work can be done and ultimately you’re probably working to fix problems that someone else created. It’s been rare that I’ve been given the privilege of working on a project that was aimed at fixing my own mistakes, but I could put that down to my insatiable appetite for job hopping.
My own projects are a different beast as they are all my own work and thus all my own mistakes. Take for instance my intial foray into the world of web programming, Geon. Initially I decided that I’d code the whole thing in ASP.NET mostly because I could do it in C# (something I’m very familiar with) and there appeared to be a whole lot of resources available for doing the things I needed to do. For the most part that worked quite well and I was able to get the majority of the components up and running within a few weeks. Sure some of the subtleties of the design I had in my head didn’t quite work but for the most part I was able to get what I needed done, and even launch a few improvements along the way.
However after a while the limitations placed upon ASP.NET became painfully apparent. Coming from a background of desktop programming it became obvious that the majority of the functionality I was used to using was either simply not available or hidden behind a wall of mysterious Javascript. Whilst I’ve had some experience with Java in the past I wasn’t too happy about having to relearn another language in order to be able to accomplish what seemed so simple in my head. After blathering around for a while I came across Silverlight and whilst I knew that it was just Microsoft’s answer to Flash the promise of being able to code for the web as if I was coding for the desktop was just too good to pass up and I relegated myself to transitioning to it.
The transition was in fact a greenfields approach to the application. The initial iteration of Geon in Silverlight was, for the most part, a like for like system built upon a completely new code base. Whilst they share a common language the frameworks available and the UI design are wildly different. Still with a little effort I was able to replicate Geon into Silverlight in less than a weekend and everything seemed right with the world.
Then one day I had a fit of inspiration about a new layout for Geon. I quickly fired up Visio and started playing around with visual elements and cobbled together a better design. Everything seemed to be falling into place and I could see how it would be so much easier with this new design. Unfortunately this meant that the current code I had written for Geon in Silverlight was effectively unusable as the visual elements drove the underlying objects and thus couldn’t be used. The internal logic of some parts remained though and the new design took considerably less time to develop.
You might be noticing a couple patterns here. The first is (I’m going to start with the good here) that for the most part a lot of what I’ve created is reusable which is a classic example of modular programming at work. There was a bit of massaging between ASP.NET and Silverlight but thanks to Microsoft’s libraries this was fairly minimal. The second is I’m getting into a bit of a habit with starting a fresh each time I think of a new and better way of doing something, despite the amount of work that that entails.
I put this down to a form of analysis paralysis. In essence every time I’ve taken a long hard look at my code after a break from it the first thing I start to notice is how difficult it will be to get everything working just the way I have it in my head if I want to keep the current code. It stems from the way that I work on problems, by intensely focusing on a single problem until I have the solution. Whilst this usually ends up with an adequate solution to the problem I’ve often found myself spending a good 10 minutes on a function figuring out how exactly it does something. Repeat this for every function and in the end it becomes easier to just start over again instead of trying to rewrite everything so it fits together perfectly.
This all came to head when I started looking at the layout of Geon and realised that it had some inherit problems with viewing large amounts of information. Subsequently I’ve drawn up yet another design that is, you guessed it, almost wholly incompatible with the way I’m doing things now. I’ve since dedicated my weekend to developing the design and seeing how it works out but as you can imagine when I’m looking at dropping the code base for the 3rd time I start to question whether I’m really making any progress. Or maybe I’m just avoiding coding the real meat of Geon because it’s, you know, hard.
The good news is that the project manager in me isn’t going to be happy with feature creep and deadlines falling by the wayside so I firmly believe that this iteration of Geon will be the last major UI redesign before its final release on the world. This time I’ve made sure to include those “little things” like a user control panel which were strangely absent from my last 2 designs and hopefully I’ll achieve my goal of making the information much more visible than it currently is.
It really doesn’t help that my to-play list of games is getting longer every day either 😉
