Friday, July 14, 2006

What technology do you need?

In times where IT-projects are cancelled or are never really doing what they meant to do, one question arises more often than others: What kind of technology do you really need to fullfil your tasks? In principle, this is a very simple question. In practise, this is one of the tough ones.

Well, as stated above, in principle the question is pretty simple to answer: "It is the technology that solves your problems.". If so, why does not everybody simply use the technology suited to the problem? There are a number of reasons, let me try to state some of them:

  • "We always used X and it was apropriate till now."
  • "You can solve every problem using X."
  • "X is better than Y, because of ..."
  • "We (only) have knowledge of X and cannot simply switch to Y."
  • "Our (co)workers know X and not Y."


Some of the above listed statements are more true (or wrong) than others. Let's have a look at them.

We always used X and it was apropriate till now.

Having a new project or problem to solve, this sentence cannot be wronger than any other, as long as the new problem is not of similiar kind like the older ones. The fact that problems were solved in the past does not really take in account that new kinds of problems may arise that can be programmed easier using another programming language or other tools. It only depends on the problem.

You can solve every problem using X.

This sentence mostly bases on the fact that programmers are much more conservative selecting their tools and programming languages than often expected. In theory, every problem can be solved unsing any computer language. But nobody nowadays would write a website using machine code or a very complex workflow system that connects to other systems around a business only using scripting languages.

X is better than Y, because of ...

Well thats a knocker. I cannot remember how often I heared that argument before and I cannot count the numbers it still was wrong then. Do listen carefully to this argument, then compare it to the needs your new project has to fulfill. You will surely find an argument against it in an instance.

We (only) have knowledge of X and cannot simply switch to Y.

This argument often is true. It often does not make sense to switch to a complete new programming paradigm if no one ever worked with it. Nevertheless, working in business programming you should always be aware of technology changes and perhaps you have a chance to spit in some new paradigms on small/lesser extensive problems and projects. This will invalidate the argument a little bit in the future and broaden the view.

Our (co)workers know X and not Y.

True too, but a little bit like the argument before. If you never give Y a chance, you will never collect knowledge in that region. And we talked about that the technique used should at least match the problem.

So what to do?

Taking the arguments from above here is a brief (of course incomplete) list what everyone should bare in mind:

  • Evaluate your tasks for the new problem.
  • Try getting open-minded, if all arguments say "Y" is better than "X", evaluate your options about "Y"
  • Get a background on the technologies you want/have to use. Often this may help to make a decision on how/what to use more simple.
  • If you got a complex problem you might want to use a complex environment. Otherwise if you got a simple problem, you might to want a simple environment.
  • The tougher the problem, the more tough it is to "computerize" it, meaning that simple environments may not fullfil your needs there.

This all sounds pretty simple or even flat? True. On the other hand advice needs not to be complex to work. And be honest, how often in your daily life do you really ask yourself the questions stated above when deciding how to go on in IT and project managment?

Labels:

 

0 Comments:

Post a Comment

<< Home