Comments on: When YAGNI Is Confused With YRGNI http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/ Lidor Wyssocky's Blog on Optimizing Software Development Sun, 27 Jul 2008 02:34:50 +0000 http://wordpress.org/?v=1.5.2 Comment on When YAGNI Is Confused With YRGNI by: WaterBreath http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-872 Fri, 07 Jul 2006 03:16:44 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-872 A particular case came to mind where YRGNI can happen quite often: data warehousing. Of course YAGNI happens often there as well, but the post was about YRGNI ;) Anyway, in data warehousing it can often be the case that waiting to add a feature until it is "needed" equates to a huge increase in implementation effort down the line. Large databases are notoriously rigid, even when well-designed. And that means that making things easily extensible is much more difficult. Or worse, waiting means that the feature won't have the necessary historical source data to start with. For example, if the feature that we "might need" in the future is a certain summary report of data that is not currently kept in a backlog.... Say it's January now. And in June a decision will be made whether the report will be needed. Should we get the backlog in place now, even though the report it is for may not be implemented? Well, that depends on the user requirements. It may be critical that, if the report is implemented, data is available for the entire year. In that case, if we wait to put in the backlog till the report is green-lighted, the users won't really be getting what they need. So the prudent choice may very well be to put the backlog in place and start collecting data now, even if it may never be needed. Probably not the greatest example, but it's a lot more concrete for me since a data warehouse is my primary responsibility at the moment. A particular case came to mind where YRGNI can happen quite often: data warehousing. Of course YAGNI happens often there as well, but the post was about YRGNI ;)

Anyway, in data warehousing it can often be the case that waiting to add a feature until it is “needed” equates to a huge increase in implementation effort down the line. Large databases are notoriously rigid, even when well-designed. And that means that making things easily extensible is much more difficult. Or worse, waiting means that the feature won’t have the necessary historical source data to start with.

For example, if the feature that we “might need” in the future is a certain summary report of data that is not currently kept in a backlog…. Say it’s January now. And in June a decision will be made whether the report will be needed. Should we get the backlog in place now, even though the report it is for may not be implemented? Well, that depends on the user requirements. It may be critical that, if the report is implemented, data is available for the entire year. In that case, if we wait to put in the backlog till the report is green-lighted, the users won’t really be getting what they need. So the prudent choice may very well be to put the backlog in place and start collecting data now, even if it may never be needed.

Probably not the greatest example, but it’s a lot more concrete for me since a data warehouse is my primary responsibility at the moment.

]]> Comment on When YAGNI Is Confused With YRGNI by: Patrick McElhaney http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-868 Thu, 06 Jul 2006 12:23:15 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-868 Why do you keep changing the interface? Why don't you extend it, or create a new interface, or a new component? Or an adapter? Why do you keep changing the interface? Why don’t you extend it, or create a new interface, or a new component? Or an adapter?

]]> Comment on When YAGNI Is Confused With YRGNI by: Lidor Wyssocky http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-865 Thu, 06 Jul 2006 08:29:05 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-865 Hi Joshua, You are, of course, right. Your observations stress my point: this decision (like many others) is context sensitive. I am not suggesting that one way is better than the other. I just argue that you have to consider both options on a per-case baiss. As Apoch hinted: use common sense. Don't follow any rule blindly. Lidor Hi Joshua,

You are, of course, right. Your observations stress my point: this decision (like many others) is context sensitive.

I am not suggesting that one way is better than the other. I just argue that you have to consider both options on a per-case baiss.

As Apoch hinted: use common sense. Don’t follow any rule blindly.

Lidor

]]> Comment on When YAGNI Is Confused With YRGNI by: Joshua Volz http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-864 Thu, 06 Jul 2006 07:30:09 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-864 I agree with the primary focus of this post. It does, however, assume a couple of things. First, it assumes you know your component is going to be doing something else in the future (or expanded functionality). That is sometimes elusive information. Second, it assumes that you are going to be the one doing the repeated changing later. If you aren't, then you have to weigh the cost of doing it now (with your presumably superior knowledge of the problem space) against letting someone else (possibly less informed) do it later. If you aren't going to be around (short contract, taking another job, this project is being sold to another company, etc.) and you aren't sure how things are going to go in the future (will the component change in a predictable way), maybe *You* aren't going to need it, even if someone else might. And while I am all for doing what's right for my employer, sometimes there are more pressing matters that must be finished before you go. I agree with the primary focus of this post. It does, however, assume a couple of things. First, it assumes you know your component is going to be doing something else in the future (or expanded functionality). That is sometimes elusive information. Second, it assumes that you are going to be the one doing the repeated changing later. If you aren’t, then you have to weigh the cost of doing it now (with your presumably superior knowledge of the problem space) against letting someone else (possibly less informed) do it later. If you aren’t going to be around (short contract, taking another job, this project is being sold to another company, etc.) and you aren’t sure how things are going to go in the future (will the component change in a predictable way), maybe *You* aren’t going to need it, even if someone else might. And while I am all for doing what’s right for my employer, sometimes there are more pressing matters that must be finished before you go.

]]> Comment on When YAGNI Is Confused With YRGNI by: Apoch http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-863 Thu, 06 Jul 2006 06:13:11 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-863 I've found that in many cases all the methodology rule-sets (like Agile, XP, et. al.) are actually superfluous; they can all be reduced to a single guiding principle: Don't be stupid. Unfortunately, those who are capable of actually carrying out this rule tend to be far enough along as programmers that they don't really need to memorize a lot of rules to get their jobs done ;-) I’ve found that in many cases all the methodology rule-sets (like Agile, XP, et. al.) are actually superfluous; they can all be reduced to a single guiding principle:

Don’t be stupid.

Unfortunately, those who are capable of actually carrying out this rule tend to be far enough along as programmers that they don’t really need to memorize a lot of rules to get their jobs done ;-)

]]> Comment on When YAGNI Is Confused With YRGNI by: Lidor Wyssocky http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-859 Wed, 05 Jul 2006 20:46:19 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-859 Thanks for the feedback WaterBreath! Lidor Thanks for the feedback WaterBreath!

Lidor

]]> Comment on When YAGNI Is Confused With YRGNI by: WaterBreath http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-857 Wed, 05 Jul 2006 16:51:54 +0000 http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/#comment-857 Very nice post. Shame no one has commented yet. Maybe it's just too sensible to provoke any response? At any rate, it is nice to see someone out there vocally tempering the advice of the Agile aesthetes with some common sense limits. There are many people are far too ready to accept guideline as gospel. They can use these kinds of corollaries. I guess in short, simplicity of implementation is a goal, and a good one. But it doesn't necessarily trump all others, and it's not the only place where simplicity is beneficial. Simplicity of integration is also important. And as Mr. Wyssocky has pointed out, there is usually a trade-off between immediate simplicity of implementation and near-term simplicity of integration. Rather than forsaking one for the other, we should strive for balance. Very nice post. Shame no one has commented yet. Maybe it’s just too sensible to provoke any response? At any rate, it is nice to see someone out there vocally tempering the advice of the Agile aesthetes with some common sense limits. There are many people are far too ready to accept guideline as gospel. They can use these kinds of corollaries.

I guess in short, simplicity of implementation is a goal, and a good one. But it doesn’t necessarily trump all others, and it’s not the only place where simplicity is beneficial. Simplicity of integration is also important. And as Mr. Wyssocky has pointed out, there is usually a trade-off between immediate simplicity of implementation and near-term simplicity of integration. Rather than forsaking one for the other, we should strive for balance.

]]>