Pages

Monday, 28 February 2011

Governments are being toppled every week in Egypt and the Middle East, so what better time to topple some of your own oppressors? The good news is you won't need a few thousand people in support and your opposition doesn't have guns. The bad news is that it's resilient, has support in unlikely places and won't go without a fight. Yes, I'm talking about Bad Software, also known as BS.

It may be software bought of the shelf, a bespoke solution, or something created internally. But regardless of the source, its had it's time. It's slow, cumbersome, it's not doing all the things you need it to, it's buggy, it's annoying - but it's doing just enough to hold on to power. And worse still, its corrupted your colleagues and managers in to thinking it's got a place. When you try and get rid of BS, you'll get responses like

"It's too hard to replace. You just have to get used to it."
"It's done it's job for x years, it's good enough."
"It's not the greatest, but it does function x which we really need."

B.S has infiltrated their way of life and made a home for itself. Colleagues are institutionalized. They will even fight to protect the very cause of their problems. But inevitably, change must come. But you'll need a few things to make it come a little quicker.

1. A better alternative
How will you replace Bad Software? Identifying a problem is easier than producing a solution. Sometimes its only when trying to find a replacement that you truly understand the problem. You'll also have constraints such as budget, time allocated and technical issues. Don't choose something just because it's popular. There's too many finer points to just assume what's popular will work for you. Write down what the product needs to do and work from there.

2. Credibility
You can't go far without credibility. Even if you got a great solution, if people don't believe in you it will be very difficult to get your project off the ground. Building credibility takes time. If you're a new engineer you can do smaller projects to demonstrate your capability. Credibility also helps during the project. When you run into difficulties, people are less likely to assume the project was doomed to begin with and will just accept it as work in progress.

3. A Plan
Always make some kind of a plan on how your going to proceed. Your chances of successes will be much greater than if you try and hack your way through. And by plan, I mean something written down that you can show people. Many faults can be picked up on paper saving you a lot of time during the course of the project.
BS is the ruling power and has been there longer than you and has probably seen off a few attempted coups, so be prepared. BS may covertly bring out it's supporters, arming them with seemingly legitimate concerns which are really fears about change. A good plan helps to build confidence and can also help to win over doubters.

4. Patience
You will encounter problems, there will be opposition (justified or unjustified), it will take longer than expected. Keep the end goal in mind and know that replacing a bad solution is a hard but worthwhile job.

Wednesday, 16 February 2011

There comes a time in every engineer's life when you see a problem and think, "I could make a good solution for that. I just need to create a program that would do xyz, and I'd be sorted!". There's some solutions out on the market but yours will be better. And it will be just the way you wanted it because you coded it yourself. With love and tenderness...

Most of the time, I'm opposed to IT Operations building software that's anything like a commercial or free alternative. Because 9 times out of ten, it won't be better, or cheaper. Just different, and most likely a bit crap in the long term.

Here's my pros and cons of rolling your own solution vs customizing something off the shelf

Pros

You have the opportunity to design something that is tailor made to your needs. There's nothing like a solution that fits perfectly. I didn't think much of tailor made suits until I bought one - and I looked gooooood....

Cons

You have to make it. This is a lot of time and effort which might be better spent dealing with other problem you could have solved in less time. Also, designing software is actually quite hard. If its not your strength, you need to think twice.

You have to support it. Once the pleasure in creating the first usable release is over, you've got to deal with every day life. Bug fixes, documentation, extra features. It's not a one night stand, it's a relationship you have to commit to.And the day may come, when you're blamed for every problem with the software, and you'll curse the day you ever conceived such a monstrous child.

Someone else will have to support it when you're gone. This is one of the biggest reason NOT to write important software that your team will rely upon. Coping with the loss of the creator is something that is never really planned for in IT Ops. I've seen too many pieces of software that caused pain on a regular basis but nobody knew enough about the code to make any fixes. Normally it continued being a pain until it was replaced with a commercial product.

It might do one thing better than the alternative, but it won't do most things better. Homegrown software is often made when an engineer has a particular feature or style of working that they are passionate about. But software is about more than a cool feature that you like, it's about fulfilling business requirements. Can you really put down on paper why it's an all-round better product that the alternative?

You can't 'Google' it. If you're dealing with well known software, and you've got a task you want to complete or an error, you'll almost certainly find some help on some forum. But if you're the only person using the software, it means you have to solve the problem yourself. This sucks.

My general recommendation for customized solutions

Stand on the shoulders of giants, and have a look around. See what can be achieved if you work with something already on the market. They've been in your place before and done a lot of the groundwork. Anything you do extra is now truly adding value to the solution.

Design it before you make it. You can hack small thing together in a few days or even a week or so. But bigger projects need to have some sort of plan so you can specify what you're going to achieve and how it's going to be done. It's much, much easier to find that it doesn't work on paper, than to build it and find out the same thing.

Present it to the team. If you're project is worth it's salt, it should stand up to a little scrutiny from your peers. This doesn't necessarily mean they'll agree - people can object for a variety of non-business reasons. Typical one's being a general lethargy towards improving services, uninformed bias towards a particular product or programming language (e.g "MySQL is for amateurs, you need Postgres"), or a general fear of something new. But either way, it's a useful process.