Whilst I haven’t had a real programming job in the better part of a decade I have continued coding in my spare time for various reasons. Initially it was just a means to an end, making my life as an IT admin easier, however it quickly grew past that as I aspired to be one of those startup founders Techcrunch idolizes. Once I got over that my programming exploits took on a more personal approach, the programs I built mostly for my own interest or fixing a problem. I recently dove back into one of my code bases (after having a brainwave of how it could have been done better) and, seeing nothing salvageable, decided to have a crack at it again. This time around however, with far less time on my hands to dedicate to it, I started looking for quicker ways of doing things. It was then I realised that for all the years I’ve been coding I had been suffering from Not Invented Here syndrome and that was likely why I found making progress so hard.
The notion behind Not Invented Here is that using external solutions, like in the case of programming things like frameworks or libraries, to solve your problems isn’t ideal. The reasoning that drives this is wide and varied but it often comes down to trust, not wanting to depend on others or the idea that solutions you create yourself are better. For the most part it’s a total fallacy as any one programmer cannot claim to the be the expert in all fields and using third party solutions is common practice worldwide. However, like I found, it can manifest itself in all sorts of subtle ways and it’s only after taking a step back that you can see its effects.
I have often steered clear of many frameworks and libraries mostly because I felt the learning curve for them would be far too steep. Indeed when I’ve looked at other people’s code that makes use of them I often couldn’t make sense of them due to the additional code libraries they had made use of and resided myself to recoding them from scratch. Sometimes I’d do a rudimentary search for something to see if there was an easy answer to my problem but often I’d just wrangle the native libraries into doing what I wanted. The end result of this was code that, whilst functional, was far more verbose than it needed to be. Then when I went back to look at it I found myself wondering why I did things in this way, and decided there had to be a better way.
Fast forward to today and the new version of the application I’ve been working on makes use of numerous frameworks that have made my progress so much faster. Whilst there’s a little bloat from some frameworks, I’m looking at you Google APIs, it’s in the form of dlls and not code I have to maintain. Indeed much of the code that I had to create for handling edge cases and other grubby tasks is now handled much better by code written by people far more experienced with the problem space than I will ever be. Thus I’ve spent far less time troubleshooting my own work and a lot more time making progress.
I have to attribute part of this to the NuGet package management system in Visual Studio which downloads, installs and resolves all dependencies for any framework you want to install. In the past such tasks would fall to the developer and would often mean chasing down various binaries, making sure you had the right versions and repeating the whole process when a new version was released. NuGet broke down that barrier, enabling me to experiment with various frameworks to meet my end goals. I know similar things to this have existed in the past however I really only begun to appreciate them recently.
There’s still a learning curve when adopting a framework, and indeed your choice of framework will mean some design decisions are made for you. However in the short time I’ve been working with things like HtmlAgilityPack and Json.NET have shown me that the time invested in learning them is far smaller than trying to do what they do myself. I’m sure this seems obvious to seasoned programmers out there but for me, who was working with the mentality that I just needed to get things done, it never occurred to me that my approach was completely wrong.
I guess where I’m going with all this is that should you find yourself attempting to solve a problem the first thing you need to do is see if its been solved by someone else first. Chances are they’ve gone through the pain you’re about to put yourself through and can save you from it. Sure you might not understand fully how they did it and they might not do it the way you wanted to but those things mean little if they save you time and emotional capital. I know for myself if I had to redo everything I did previously I would be no where near where I am today and likely would get no further.
Looking back over my short 6 year career I’ve noticed that I’ve never really worked for any smaller organisations. Probably the smallest team I ever worked for was a group of 20 people on the National Archive’s Digital Preservation Project but even there I was technically part of the larger group of 200 or so people responsible for archiving things of interest for the Australian public. Probably the largest team I was in so far was at Unisys with my team consisting of around 30 people and the section I was a part of had well over 400 staff catering to all aspects of IT for a large government department. Working in such large environments has its benefits, such as lower amounts of responsibility and the opportunity to heavily specialize, but these are easily overshadowed by the drawbacks of needing that many people: managing the lot of them.
For the most part though I’d agree that its required. The last thing you need in a large environment is some cowboy system administrator making wide reaching changes which end up affecting thousands of people or loose process definitions which end up confusing the heck out of anyone trying to get some work done. Once you reach a critical mass of users and staff formalizing your procedures and policies starts to bring tangible benefits and is the basis for the industry buzzterm Six Sigma. However it seems that organisations that are intent on strangling themselves to death with rigid frameworks seemingly looking upon the horror they’ve created with rose coloured glasses.
Take for instance change management. At its heart it’s all about making sure that you don’t go changing things that will inadvertently affect other things and ensuring that all required stakeholders are informed of these decisions. When I was trained in ITIL I instantly recognised the benefit of such processes and was quite thrilled to see it accepted at the first real workplace I had ever landed a job at. Once I had become familiar with its implementations though my view of the glorious world of ITIL compliant processes was tainted with the harsh reality that for the most part it’s completely unachievable.
My current workplace is a glorious example of this. In what supposed to be a relatively progressive workplace (they had 1.0 revisions of blade servers here, a risk very few took) the change process is still done manually. I.E. if I need to change something in the environment I need to fill out a change request (fine, that’s part of ITIL), print it out (hmmm ok sure), take it around to all the service owners and get them to sign it (ummmm what?), get the Global Service Delivery manager and CIO to sign it (argh, why are they never in their office? Oh right they have more important things to do) and then give it to the change manager (total time spent doing this, around 2 hours). The Change Advisory Board (which contains all the service delivery managers) then meets once a week to discuss the changes they’ve already signed and so spend 30 minutes confirming that they actually signed the changes. Oh and they might ask how the previous changes went, maybe.
The above example demonstrates quite aptly how a vision of a process becomes horribly bastardized in the hands of those who don’t really understand it. Worse, even though the process is known to be horribly flawed, nothing has been done to change it in the many years it has been implemented. It seems everyone is content to gripe about how bad it is yet when improvements are made they amount to nothing more than rearranging the deck chairs on the Titanic, giving the impression something is being done when really its not (*cough*management theater*cough*). Couple that with the apparently abhorrent idea of scrapping the entire process and rebuilding it anew and you’ve got a recipe for one bad idea to exist for eternity, right up until the whole organisation collapses upon itself in a flurry of industry buzz words and frameworks.
Many people who’ve come from smaller organisations and start ups often tell me this is a symptom of larger organisations, where bureaucracy reigns supreme. I can’t refut this position as I’ve never worked in such a situation although I’m doing my darnedest to get there. Logically it holds true as the fewer people you have to consult to do something the less time it will take to get it done, and the less likely that one of them will want modifications to your idea. After seeing so many organisations hang themselves on the ITIL/Six Sigma/Lean noose I’ve got to wonder if its the frameworks themselves are flawed and the smaller organisations are immune to their tragedies simply because they haven’t tried to implement them.
Maybe I’m just sour because I’ve never really been in a position to change these processes. Ever since I started working I’ve seen ways that things could be improved only to be told that they just wouldn’t work, no matter how I spun it. There’s the very true possibility that my view of the world is total crap and all my ideas would generally not work but evidence is mounting that non-traditional approaches to business work, especially in our information rich Internet world. The time is fast approaching for me to put up or shut up and hopefully my ideas will work out for the best.
Or I’ll fail miserably and come crawling back to the world of IT support, secretly crying in the corner of server room somewhere 😉