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?

You know YAGNI? Well, here is YRGNI!

A little ago I wrote about TLA's (three letter acronyms). Well, I think we all agree that pressing the world into three letters is not enough and would not work. And computer work is so much more complicated than normal work... .

Therefore (and to show that computerization is geeky) the computer industry and nerds had to top three letters. The first well known computer more-than-three-letters acronym widely known was "wysiwig" - What You See Is What You Get - which only meant that what you see on the screen is what you (mostly) get printed on the printer. I'm sure IBM hated it.

Nowadays the nerd-gossip is, as example, about words like YAGNI. And to be honest, I love YAGNI. It's an abbreviation of "You Ain't Gonna Need It". A new project starts and the client is full of ideas what might be done. Mostly he has no idea what he wants but - aren't that computers? Can they not simply do everything one imagines? As how to build an interface for department "x" smartly transfering data to department "y"? And may the workflow not simply be shown by using "z"? "At least I get all the data/workflow/oversight I need, if (or if not) ... and it's simple when ... having ..." buzzing bingo. The client is freely associating all the possibilities and opportunities even (or because?) he does not really know what he wants. At this point being a project manager, you have two ways. Nod or tell them YAGNI.

Doing the first and nod you should really be aware of what you promise. You should be aware of the implications and programming/integrational work that might follow your promise, if that all fits into your project plan and if it fits into your available data structures. Not every thing that might be done can be done in a simple way - often the time schedule does not suffice to implement it or data is not availabe to fulfill the task. That is why I love YAGNI: Tell it to the client, listen to their argumentation (perhaps it really is reasonable? If it is reasonable: drop YAGNI). And despite of what you tell them look what you can do backstage as a preparation without too much effort. This way you stay prepared and, heck, being aware of them you sometimes might realize their wishes on the fly. Both (the client and you) will not come into troubled water and believe it or not, both will prosper from that. You can concentrate on the work that has to be done and your client can concentrate on the functionality he really needs.

What a surprise for me to find an article which teaches me a new acronym (YRGNI) and tells me that YAGNI is confused with YRGNI. YRGNI means You aRe Gonna Need It. So which one is correct? Reading the article splitted the responsibilities for these two philosophies for me. And as mentioned before both are no contradictions: The one (YAGNI) seems more the "management" level, the other one (YRGNI) more the "fulfillment" part of the story. After I read the article completely I was even more astonished that I found myself in both worlds.

So, as I technician I'd say one should "think YRGNI and act YAGNI". Best of both worlds.




http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/