Sunday, 23 March 2014

A new leaf for Project Snowflake

I've been a bit disappointed with the current state of Project Snowflake. It was (and is) much harder problem than I thought it be but I think I had determined the key parts of the solution at least three years ago. Coding is nowhere near as far as I thought it would be.

Sometime in January my wife sent me a link to a video by Anthony Robbins - someone who I would generally describe as a life coach. After confessing that his 20 minute talk was actually intended to be five minute talk, he was somewhat more verbose than needed but he did have a good point: making a significant change in your life require a change of habit. This is not a new concept, famously written about by Stephen Covey (7 Effective Habits), but it does help to get a reminder every so often. Importantly, he stressed the fact that bad routines contributed to getting you where you are now. I wanted to make change with the way I was  So I decided to have an honest look at my work to date and see where things might be going wrong...

  • I planned to work on Snowflake regularly, but didn't schedule other parts of my life. I was finding that when I wanted to code, often other things came up which needed to be resolved or attended to. This could be tasks around the house, errands, shopping for a gift, fixing things around the house, social engagements, exercise, getting married (well worth it but the eight previous months were major stress!) the list goes on.
  • Not keeping a regular log of my work. I aimed to keep a weekly report for myself but often failed to do it regularly. As a result, I was less conscious of the time I was spending on a particular task particularly when solving problems.
  • Not taking enough regular time out. Obviously I wanted to see the project moving ahead as soon as possible but I wasn't taking time out to relax regularly which caused stress and made me less productive
  • Too much reading, not enough doing - I had to do a lot of reading as there were many firsts on this project. But I feel there were many times where putting thing into practice sooner, would have advanced my understanding quicker, rather than reading more about the topic
  • Imagining technical problems I would face in the mid to long term. Like too many programmers, I spent too much time think about scalability, the merits of different APIs, version control systems, etc. It worth considering these things, but these future problems only became real if you had an application built, which I didn't. The real issues were learning how to build an application fit for purpose in my spare time.

So this year I decided to make some significant change to get things done

  1. Make a realistic schedule - One that includes making time for a personal life and relaxation. This is the single most useful thing that I've done.
  2. Keep that weekly log going - keeping track of what I've done helps me see quicker when I'm coming off track
  3. Stick to tried and tested technologies unless there's a really good reason. It's hard enough getting tried and tested stuff to do what you want without introducing other complications
  4. Keep the goals small - Ambition is too often the enemy of progress. It's easier complete small goals instead trying to complete a big one. It's also better for morale.
Work has definitely been more productive since I made these change and I feel positive about where I'll be six months from now. I've also decided to devote more time to this blog which has been much neglected of late so expect updates soon.

Tuesday, 1 October 2013

Does your company choose software because it looks pretty?

I've noticed that technical departments get a bit excited when they get the opportunity to choose new software. Once the budget has been signed off there's a feeling that all our woes will disappear with the arrival the New Software. The prospect of a new system monitoring, business reporting system or  version control system, or anything else can easily whip up heated debates fuelled by political, technical and economic visions within the company. Nevertheless, the word from management is that the New Software will save us all.

Yet, like the average Hollywood blockbuster, when it arrives it often fails to deliver. You can't do what you were able to do before, it seems more complicated, there's bugs, and worst of all, it may suck even more than the current solution. And while you're cursing the changes you have to make to get less done, you're thinking "How the hell did this happen?"

Here's my answers to this question.

1. A failure to fully understand the business problem.

This is probably the biggest mistake. People often complain about software, but are the problems more related to poor training or bad implementation? And what exactly does the solution look like? Sometimes people get carried trying to implement a vision of what they would like rather than solving business problems that they have.

2. Consulting with the wrong stakeholders.

For some reason, there is an understanding that managers are the best for determining software requirements. I think managers are probably best at being managers and it's not reasonable to expect them to have a detailed understanding the current problems with monitoring virtual infrastructure, ticket management, backups, etc.

If you need to understand monitoring, talk to Operations. If you want to understand ticket management, talk to the people who work with tickets all day.  It's not to say that management don't have valid requirements, but they must be taken into account with the people who actually use the systems on a day to day basis.

3. Going with the latest craze or marketing hype.

I remember when I was evaluating monitoring systems a few years ago and I looked at a relatively new product called Zenoss. One of the big marketing claims was that it "agent-less" so you didn't have to install any software on the client machines. Except the SNMP agent. Which doesn't have the capabilities of a decent monitoring client. So you had to create scripts that were triggered by SNMP requests or over SSH. Which as far as I am concerned, is worse solution than installing the monitoring clients in the first place.

There's always hype, but you have to keep focused on what's going to solve your problem and not the problem that some marketing is trying to convince you that you have.

4. Not testing with key users.

I don't always know what to say when the New Software has been worked on for months under stealth (be it for some political reason, or simply because the implementation team didn't know any better), is finally unveiled and the true awfulness of the solution comes to light. The shock is often compounded when I found out how much was paid for the turkey.

Tests should always be done with end users to make sure things keep on track. Users can often tell you quickly if a product is a wrong fit saving everyone time and money

5. Choosing the software with the best looking interface

I like good looking software and interfaces do play a part in being productive. But I am yet to find a correlation between the aesthetics of a user interface and the quality of the software. Sometimes these interfaces aren't actually easy to use, they just look pretty in the screen shots. And like the Sirens, it's only when you take the plunge does the nightmare truly begin...

You can only get caught out if you don't really test the software or don't have a good checklist of things you need the software to do.

Have I missed anything? Let me know...

Sunday, 25 August 2013

If it ain't broke, don't forget to upgrade it

Stable systems are great. Day to day, they require little management and they keep doing their job. It makes sense to leave well enough alone and work on other stuff, right? It's a common approach and it kind of makes sense. Except, if you ever need to update software on that system. And that's when the pain begins.

Here's a few examples of straightforward tasks that have ended up being unreasonably time consuming, infeasible due to the number changes required on production boxes, or near impossible due to the level risk introduced when changing software the was depended upon by other components.

  • Installing Dell OpenManage utilities 
  • Updating Subversion
  • Updating Net-SNMP
  • Installing Puppet 
  • Administering EMC CX3 NAS
I've found that the requirement to update software often comes when improving management of the server. The software packages that provide the key services like databases, application servers or web servers are not upgraded that often and the update process is fairly straightforward. Although updating between major versions tend to require a whole new set of dependencies that may be more challenging to satisfy.

Now even though you're improving the system to make it more manageable or reliable it doesn't mean that there won't be objections to upgrades from customers or within your own team. Some typical objections:
  • It's been working well enough up until now, there's no need to change it.
  • An application developed by in house development team will have to be re-tested or changed. They don't have time for that.
  • We've got fires to put out, that's not even burning!
None of these objections are valid reason not to upgrade something, but they are things you take into account when managing your approach to upgrades. IT Operations should be adept at keeping things running optimally and being proactive at doing so. Waiting for something to break is not a great strategy. The time spent investigating incidents that are actually caused by known bugs will easily outweigh the time taken to make small upgrades. If another application needs to be re-tested or changed then you'll have to work with the development team to do so. This may be difficult because they won't have the same priorities that Operations have but as long as the problem with not upgrading can be expressed in ways that affect the running of that application, you should be able to get some traction.

It won't always be easy to make upgrades, and you will have to compromise sometimes. But it's important to have a strategy of regular updates in order to maintain a stable environment.