Software is not a panacea - Part 2

In the previous article I raised the fictional scenario of a company wanting to automate a timesheet submission process. In this article I'd like to touch on some of the project processes that would be used by the majority of companies.

Generally, most companies will start off with the sensible process of evaluating existing software packages, looking at what's out there and maybe even seeing what other companies use. After a period of time a sensible company will come to the conclusion that there is no one piece of software that fits their requirements and so their requirements must change as well as some processes. This is a key point as every company likes to think that they are unique and so around that uniqueness certain process have appeared so when it comes to upgrade or computerise those processes they are reluctant to change them.

However, back here in the real world most companies will do one of three things, they will

1. Abandon the idea
2. Buy the commercial package closet to their requirements and get it customised
3. Hire a developer to write a bespoke piece of software

Of the above three options the first is the best and safest but at this point many companies make another fundamental mistake. They never document the issues found or the reason for the project to be abandoned. This means that often someone else will reopen the project 6 to 12 months later, reinvestigate options and then select option 2 or 3.

Option 2 is an interesting one, surely there can't be much wrong with making some customisations could there?
Well, it depends. If the software is designed to allow those customisations then go ahead. However, may companies will want to alter certain business logic (e.g. maybe three people would have to approve a timesheet and the system, by design, only allows a maximum of two.
Quite often a company will purchase development skills and get the codebase changed to support what they require. This causes a problem when upgrades are required or if a security hole is discovered as often the customised verison will break when patches for the mainline system are applied if it's even possible to apply them at all.
Now the company ends up in a situation where they like and want the features in the next version but are tied to an old version due to the customisations, often they will have to face the choice of staying with the customised version, migrating to the new version or paying out to get the customisations in the new version.

Option 3 opens up all sorts of interesting possibilities for problems and complications to occur but I'll save that one for another blog

Gameforge supports theft

Up until a few days ago I played ogame. This is a browser based online game where thousounds of people interact to steal and trade resources. It was the sort of game that you could spend 10-20 minutes on throughout the course of a day and provided a welcome respite from work.
My finacee also played it for similar reasons. She played for almost a year and I did for 2 and a half years.

That is, until the other day. Because I was helping out my financee (which is within the rules) and because she was on the same IP address (also within the rules) when the resources arrived (against the rules) we both got banned until 2036. Now, I'm not disputing the ban. We both violated one small part of the terms and conditions. The penalities for that are a permanent ban which seems a little draconian but that's how it is.

So, Ban in place I decided to ask for my money back as I've got 8 months left to run on the account only to be told to go away.

So, bewary of online games especially of places like gameforge who will happily take your money and then ban you for an infraction.

This to me is theft - a bought for service is not being provided, they won't transfer the subscription to another account and they won't refund me.

So, thanks to Gameforge I'll not be trusting any MMO ever again.

The state of IT

I came across the above article earlier today and I know that examples of the above problems are not just endemic to development process but instead seem to be buried deep into the very psyche of the majority of IT projects today.

I honestly would not been surprised to see Matt Allwright of BBC's Rogue Traders pop up at some of the meetings and accused the attendees of doing a shabby job and, of course, they would be right.

The classic in the above linked article is the very last email complaining that 'I'd love to write a dev env setup guide, but I just don't have the time!'. Hang, Didn't that email exchange basically list most of the steps needed? If there is time for the email exchange and time to waste someones time in scrabbling around for this information then the setup guide could have been written ages ago!!

We, as IT professionals are constantly subjected to these shabby practices and yet we don't accept them from other professionals so why should we in our own industry?

Security Industry Commentary

Last night I watched the "Diana: Last Days of a Princess" documentary. I admit that I largely watched it just to moan about how much the British media is still concentrating on Diana but I was pleasantly surprised at how good the documentary was because they largely focused on the two bodyguards assigned to Diana and Dodi.

What really surprised me was the similarity between physical security and computer security. Both have a recommend set of practices or standard operating procedures. During the final days of Diana's life the documentary highlighted that the two bodyguards were physically exhausted and their recommendations for security practices had been ignored with the result of Diana and Dodi paying with their lives.

Now computer security isn't as hands on as computer security but there are startling similarities with the way people in both industries are treated. I still don't understand why we as security and IT professionals are hired and often ignored/overruled by management.
Obviously, there are some occasions when management have to do this to fit in with a company vision or similar which has not been fully cascaded to the business or for reasons of corporate confidentiality have to be kept quiet but this sort of practice happens all to often.

Nimda, Slammer and the like

Now that Microsoft have released a patch for the recent DNS RPC vulnerbility IT Admins should be deploying it as quickly as possible - I was talking to a friend about this today and we got to talking about how the threat landscape had changed over the years.

Many years ago a vulnerbility would be announced on bugtraq or the like, Microsoft would rush a patch out and then few people would deploy it - IT Admins would brief easy because a patch was out and things would continue.
Then the virus would hit. It would exploit a hole that had been patched MONTHS before hand. After the problem was fixed, the virus cleaned out and tools or a white paper written on how the bug worked and how slack Microsoft was in making products with security holes in.

Fast Forward a couple of years and look at the operating system. Its resonably secure out of the box, there are templates for making it more secure, there is COPIOUS amounts of documentation on locking it down. How many people ACTUALLY lock down a new server? How many apply the security templates or even take a template and modifty it? Show of hands?

Thought so.

Why do we as IT Admins wring our hands and blame Microsoft for all the security woes on the planet when they provide us with things like security templates that very few use?

The threat landscape has changed. It's highly unlikely there will ever be another SQL slammer, Nimda, love bug or code red style attack. It's just not worth it. With firewalls, IPS/IDS and Anti Virus all over the place writing a virus is actually quite difficult. It's even more difficult to get it unleashed on a network via email or similar because people are aware of it.

The new threat landscape comes from Information Disclosure. It's now routine for applications to phone home and send anonymous information 'back to base' in order to 'improve the application'. I do wonder just what information is sent back. I also wonder just how many applications turn this ability on and do NOT TELL THE USER.
Obviously, If a vendor gets caught sending back a bit too much information from your PC then they will look foolish and it will hurt their sales for a while but is this enough?

The single biggest abuser of the 'phone home' capability is spyware. The little applications that install from some websites. Some of this spyware is incredibly intelligent in how it hides itself and in what it selects to send home.

I firmly think that today, this is our biggest challenge.

Task Switching

Joel Spolsky writes a great blog over at Joel on Software. He has an insight into programming and development that a lot of companies sorely need. Recently he wrote a blog on why task switching was harmful for programmers and I wanted to highlight that here but also add that task switching is HARMFUL and STRESSFUL to most jobs.

For example, In the UK it's acknowledged that driving and using a mobile phone is a dangerous because it splits the attention two ways so why does it seem acceptable for most business to insist that their employees do several things at once? I'm not talking about having several tasks to do within a time frame. I am talking about insisting that the latest crisis is priority then when you JUST get the mind focused on that task and moving in that direction the NEXT crisis becomes priority.

This type of work pattern in unhealthy and dangerous. It puts a great strain on the employee when it becomes the daily routine rather than the exception. I still fail to understand how this type of working pattern can be seen as normal for a company, I guess it's a pattern that is easy to fall into when the department itself is being pushed, squeezed and stretched to achieve more with the same or with less or when managers are too scared to push back to their managers or the board.

This is unhealthy and unproductive but I don't see any way that he vicious circle can be broken.