Monday, April 16, 2007

Is documentation really that useful?

I know a lot of managers feel that a system should have a certain amount of documentation supporting it, but in my experience often
documentation that is produced for this purpose never gets used after it is written. I would suspect some sort of high level design of the system which describes it's interfaces, major architectural components and design patterns is useful. Perhaps also a support/operations manual for those that need to support the system in production can be useful. However when it gets down to detailed design documents such as class diagrams and sequence diagrams I rarely find them useful. Usually they don't get maintained and they just don't help you understand the system that much.

Although I'm not totally convinced I'm starting to lean towards the idea that good software is self documenting and software quality is more important than documentation. Also having been involved in some agile projects lately, I'm starting to see how the automated tests for a system can be the best documentation of what the system does.

Saturday, April 14, 2007

Java is too complicated

I'm trying to get hibernate and spring working together and finding it REALLY REALLY frustrating to get simple transactions working. Google hasn't come to my rescue yet. In this case I suspect it is because there are some many variations of how you configure it and not many people are using it the way I'm trying to (maybe that is the problem...) I'm thinking this is probably a common experience. These frameworks are extremely powerful but also awfully complicated and hard to master.

Thursday, March 15, 2007

Why development still takes as long as ever

Have you ever wondered why despite the amazing advances in programming languages and tools that it still takes as much effort to maintain code as it did 10 years ago. I'm thinking specifically of Java here but I'm sure it applies to other languages too. There are a few reasons for this but these are my favourites.

Firstly programmers always seem to want to use the latest frameworks that come up. I guess it is because we get bored and we'd like to try something new. Therefore we are forever trying to use new frameworks. These have a learning curve so the initial development is always slow. It feels like we never master anything before moving onto the next thing.

Secondly there is so much overuse of design patterns and over engineering. Here is where agile techniques have a lot of value. They encourage the use the simplist design to achieve what you need to do.

Lastly there are the tools. I guess IDE developers have to stay in business by offering more and more features. However once you get to the 3rd version of a product, unless you are a genius or it is a very well design product it tends to get so complicated it takes an eternity to master. That is unless you have used the product since it first came out. Just take something like photoshop for example: there are a lot of features but I can't figure out how to do even the basic stuff. Once a product has got a "wizard" you know it is lost cause...

Suffering from writer's block

I thought I had more frustrations but now that I've started writing them down I realise I have already captured the main ones.

Saturday, February 24, 2007

The evils of short term incentives

I'm convinced that the current way that companies try to set incentive pay for employees based on short term and results based outcomes during the year is going to be their undoing. So often I see people being rewarded for putting in short term solutions that are going to cost the company a fortune in the long run due to the maintenance or support effort they will create.

Thursday, February 22, 2007

Decisions made by people who don't understand technoloy

Recently I've found myself in the situation where many of my recent managers think they know much more than they actually do about technology. They go to meetings with their ill conceived assumptions and make major decisions without consulting any of the technical people. When the tech savvy people actually find out that a decision has been made, often it is too late to change it. It seems like a bad case of chinese whispers where the facts get distorted as they get passed up levels of management.


Why is it that senior management always think they can fix everything with a restructure. If they just listened to the people on the ground they would know how to fix the underlying problems. Instead they go on their "off-site" retreats and work out restructures achieve absolutely nothing. Do they think that they will look weak if they listen to people who work for them or is it just sheer arrogance or stupidity?