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/
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/
0 Comments:
Post a Comment
<< Home