Personal Opinion VS What's Good for the Company

There are a few dinosaurs at my work. Very intelligent people, but they have very strong views on what the future direction of the company should be. Now I've been the occasional evangelist in my time supporting the likes of C++, PHP and Perl when it seemed appropriate, but not necessarily putting these opinion's ahead of what the companies needs would be. For example. My department is heavily developing in .NET technologies. I had the opportunity to move the department away from Microsoft and into alternative technologies for web and windows based systems. Instead of doing so I spent some time learning how to develop in .NET and applying it to the business. While I do not agree with a great many of the philosophies of .NET and Microsoft as a while, what they have produced is a framework where you can produce simple applications that are very easily supported by a small group of developers. This is typically suited to the work my department does and the technology we already have in place. Alternatives were also looked into of course and are not entirely ruled out. We use Perl for some unix based processing, C++ for some windows interfaces and SOAP web services, but to produce the main suite of web applications using another web tool would have taken 2 - 3 times the amount of time and in many cases produced code that would have been far more difficult to maintain. In our current situation, we may be tied to Microsoft but we can hire a developer off the street who would likely do an adequate job at understanding our code. I am however under constant scorn from the dinosaurs for this line of thinking. One of them goes so far to install linux on his work computer instead of the SOE Windows environment believing that there is no need for Microsoft in our company. This is correct of course, my company could survive without Microsoft tools. However the cost that would be involved in replacing such an enormous amount of technology would send them broke and they would struggle to find support technicians or developers for any of these new systems in an environment where people with good technical skills and good communication skills are terribly difficult to find. Open technologies are a great idea and they have to start somewhere if they are to succeed, however sometimes propriety technology is a necessary evil.

ITIL Certification

I have recently become ITIL certified. It was an initiative my company had created to help better the IT processes internally. Interestingly it was a requirement that everyone takes the course but it was not a requirement that you pass. If you fail, there were no repercussions. Of course everyone in my group had already taken the course and passed and i was the last so failing would have been terribly embarrassing. The course itself is actually quite good. It provides some very useful concepts, most of which I already learned during my engineering degree and by picking up best practices around work places I've worked so far. What it did do was place definitive terms on all these ideas and place a formal structure around them. It's a course I would highly recommend to any medium to large business that concerns itself heavily with IT. The processes it teaches are tried and tested and well known to be one of the most effective methods of IT management, but rarely are they followed. This is due to a lack of cohesive structure in the most part and while most IT professionals may know of the processes, unless they are implemented they aren't much good and everyone will go about implementing bits and pieces of what they interpret as correct as they see fit. Having a corporate wide decision to follow the ITIL steps in a structured manner will definitely help most businesses manage their IT processes more effectively. It's an expensive process though, but if you're losing money due to inefficient IT processes and work flow, then I would say very much worth while. As for the certification itself, well I wasn't a fan. I found that the exam was testing your comprehension skills more than your knowledge of the ITIL theory. The questions were tricky and someone without excellent comprehension would definitely struggle. But I passed fairly easily, as did most people in the course. Funny enough, the ones that failed were not dull people. The were bright and either had a very difficult exam question set or just took the course lightly not caring of the result. A certification test should test your knowledge, not your interpretation of a question. Other than that, it was an excellent course that I would recommend to anyone in IT.

Performance Reviews in Development Teams - KPIs

Every year in the three I've been here at Salmat we've had a different performance review process. From a minimal and uncontrolled process of my first year where we were informed that our results would have no impact on our wage increase to this year where we had a good and indepth review where we were told that our results would directly affect our wage increase. Also worth noting is that the whole company has the same performance review process. This is an interesting scenario. These reviews almost always have KPIs of a quantitative nature. This works fine for some sections of IT, but in development it is very difficult define quantitative KPIs due to the nature of the work. Varying length of projects and the constantly evolving environment are the main reasons for this. For example you can't specify a number of issues for a yearly period. In one year you might complete thousands, and in another perhaps just one. This might be an extreme example, but it makes the point. So how do you define KPIs without quantative results? By having subjective KPIs. For this year I have discussed with my manager the use of subjective KPI ratings that we can discuss with my team during the year at regular review and at the end of the year. I don't know how well this is going to work, but as long as the reviews are regular we should be able to keep track of it during the year. An example of this would be a KPI to do with delivery time. The outcome is defined to be meeting 75 percent development deadlines. This sounds like it may not be all that objective if you track issues close enough, but in our environment there is so much change that deadlines are often redefined to meet the business needs. During our regular reviews we will review the projects for that month and the outcome of the development tasks assigned to each developer. I'd like to keep track of how this goes during the year and update my blog as I go. I'll try to get some feedback from my team as we go as well.

Issue Management

In this role recently I've been experiencing first hand the role of issue management and tracking in software development teams. When I started this role issue management was barely managed. For our .NET and web projects issue tracking was done through a custom software package written in classic ASP. This package was originally written because buying a package that is customisable is very expensive. I can't begin to imagine how much it would have cost to develop this software internally instead of buying a proven customisable package from an external company. For our other projects we use team track. I'm not usually a fan of closed source software, but this tool is fantastic. It's expensive, roughly 1200 per professional lisence, but well worth it. I have integrated the tool heavily into all aspects of our work now and our productivity has never been higher. We can track all the issue we work on quantitatively and all in one system that is so easily configured for each project or any processes that come up. Exposing this information to the business where required is also very easy and quite cheap as only the developers need full licenses and maybe the support team if they require a hand on approach to software development. I don't usually advocate software for no reason. What I'm getting at is that an adequate software solution to issue management is very important and productivity can really be positively affected by tight management and control of all issues.