And an essential response, too, if you're doing a fixed price project :)

yummy change requests at 4 times the normal price :o

Don't you think just you just went to the other side of your previos rant ?

You wrote about that you are anoyed when people consernes are dissmised.

"Basically, the problem is that concerns that are being brought up are dismissed as unrealistic, idealist and non workable in the real world. "

But basicly you did just this in this case.

@Michael -- Huh? Not sure how you came to that conclusion.

The concern of this developer was not "dismissed as unrealistic, idealist and non workable in the real world" it was simply out of scope ("it would only show up if we extend the project in a certain direction, which isn’t currently planned").

Huge difference.

Sean YAGNI type arguments can be used against any suggestion for iprovement or inovation in proccess or tools. It anoying when you on the reciving end but perfectly correct and pragmatic thinking if you the one what puting restratins on things :)

Here a couple of examples :) :

I want to use unit testing to increase software reliability - Why we need to test we have testers for this "Let them submit a bug report for that"

I want to introduce Interfaces in certain places so we have extensability points in the future - The need for extensability would only show up if we extend the project in a certain direction, which isn’t currently planned

Michael,

• If the customer does not get what he specified, he will stick the bug report into some place where it really shouldn't be and possibly not hire you again.

• Why would you introduce extension points for things you aren't planning to extend?

If developers have seen potential problem and then bury their heads in sands and do nothing. This is irresponsible. Every one in the team should be responsible for the software quality.

I would have proposed something more like:

"Document the HELL out of the code at the possible extension point, explaining what problems might come up if we do go in that direction."

If you do go in that direction and this problem gets forgotten about, it could get caught in testing (best case) but could also go into production with a bug. I guess you know better than anyone how big a deal that would be (since you're the one who knows the project).

Generally speaking, I wouldn't discourage this kind of thinking. The most valutable developers (and analysts) are ones who can effectively identify cases beyond the sunny-day scenarios.

This is just another design trade off. I personally think if a potential problem is identified then it should be documented along with a test case.

@Michael -- I think you're missing the point here, or at the very least you are changing the context. He never said he told someone not to unit test or that he told him not to implement extension points.

[I believe] he is saying that the developer responsible implementing a feature reported that if the project scope is changed then there could be a bug. To paraphrase, the developer is talking about a certain situation that could crop up if the scope changes in the future, which may or may not happen.

To me that is what YAGNI is all about. Don't code to future, hypothetical situations, code to what is needed now. Of course, if the direction the developer refers to is a known, planned one then that changes things.

For what it's worth, I'd probably still call YAGNI on that second example though. :-) Extension points for the sake of extension points is not something I'd want to spend time on when efforts could be better applied elsewhere. Again, if we know we're going to need those extension points someday then that's different.

Finally, I agree that YAGNI could be used as an argument against innovation and it does indeed suck when this happens. I think it's only happening in your examples though, not Oren's.

IMHO, This approach may be good enough for a specific project at a specific time, but as a general rule, it is just showing dishonesty and disloyalty,

Dishonesty, beacuse you are making business assumptions for the customer, and this is not what we are getting paid for. What if the customer wants to pay for that blind spot to be fixed during development, so he would not have to pay extra later on? what if this extension is actually planned, but not at the current stage, so you werent notified? why should we make such decisions? give the power to the customer.

Disloyalty, because today's team is not tommorow's. People come and go, and leaving a well-expected and well-known bug (hey, if we can easily to a stage where users file a bug report, its a bug) to lurk somewhere undocumented and unnotified, it being disloyal to the company that hires you.

YAGNI is about doing exactly what we required. I never saw "creating undocumented bugs" in a requirements list.

Actually, the more you develop the more these things show up. Probably, in five years Ayende will put off this blog, forget about all that idealistic stuff and just make money on the solutions done previously )

@Moti you might want to read the post again. It is not a bug, it is a potential bug that will only appear if the project direction changes. That is neither dishonest or disloyal.

As for YAGNI, the potential bug is not even in scope right now. Maybe it only shows up if the customer uses the product in ways it was not designed to be used? If in fact it turns up as a legit bug down the road, who's to say that the customer will get charged to fix it? Never mind the fact that calling someone dishonest and disloyal based on your assumptions is, um, well, rude.

-- why should we make such decisions? give the power to the customer.

Because we're the developers, we are paid to make those decisions. Consulting the client about every single coding decision is simply not feasible and is a sure fire recipe for scope-creep.

-- I never saw "creating undocumented bugs" in a requirements list.

No one did that. This bug may or may not crop up if the project changes direction. Also, where did he say the potential bug was not documented for future programmers?

Let me ask a question, if this potential bug takes two weeks to fix is it still the developers moral duty to fix it? Keeping in mind that if the project doesn't go in the direction that would create the bug then those are two completely wasted weeks.

@Sean.

I must have hit a nerve, ill try to be gentle.

-- Because we're the developers, we are paid to make those decisions.

Consulting the client about every single coding decision is simply not feasible and is a sure fire recipe for scope-creep. --

No, we are not being paid to make THOSE decisions. We are getting paid to deliver a system. If you are making a decision that can sometimes in the future break something, the customer needs to be aware of that. Not informing that due to "lack of time", is at most cases (as i said, a general rule - i'm not judging a specific decision on a specific project) a bad excuse, a lie, or a giant red light that should tell you that you are managing your time badly.

Imagine a doctor, before an nose job, neglecting to tell you that you can't dive anymore, just because until now, you never set foot on water.

Heck, even imagine a hardware engineer, making a decison that his chip will only support certain frequences because the product is not meant to handle others in it's current version, and not making sure everybody knows about this decision.

I met my share of programmers that felt that having a VS installed on their laptops made them god, but our industry should understand that it is an just like any other, and grow up. Even in our line of work, a customer is a customer, and should be treated like one.

-- No one did that. This bug may or may not crop up if the project changes direction. Also, where did he say the potential bug was not documented for future programmers? --

Sure he did. I can devide by zero, and it may or may not crop up if the project changes direction. It is still a BUG. Also. if sometimes the project does change direction and the bug does pop up in user's bug report, than to me it means that there are no supporting tests, nor inline documentation to alert the programmer responsible for the direction change that the system is going to break.

-- Let me ask a question, if this potential bug takes two weeks to fix is it still the developers moral duty to fix it? Keeping in mind that if the project doesn't go in the direction that would create the bug then those are two completely wasted weeks. --

Again, it is not your decision to make. It's not your money, and it's not your time. It's the customer's (or employer's) and he should be at least notified of this tradeoff.

Finally, i don't think i was rude in any way. I wrote a disclaimer regarding me not knowing the specific of the case ayende is working on, and did not judge him. However, i did went against placing that story under YAGNI.

I worked with several large organizations, that held hiding bugs under the hood a justified cause for lay off. I can't say i totally disagree with them, even if the hiding occures under a cape of a notable principle such as YAGNI.

Don't worry, no nerve was hit. I was merely surprised at that what he did could be interpreted as dishonest and/or disloyal (however subtle the implication was). Thanks for being gentle though.

-- No, we are not being paid to make THOSE decisions. We are getting paid to deliver a system. If you are making a decision that can sometimes in the future break something, the customer needs to be aware of that. Not informing that due to "lack of time", is at most cases (as i said, a general rule - i'm not judging a specific decision on a specific project) a bad excuse, a lie, or a giant red light that should tell you that you are managing your time badly.

Again I beg to differ. A developer needs to produce a bug free system that does what it's supposed to do. They are not required to go to the client at every turn and say "Hey, in the future are you going to do this? If so then I need to do this, otherwise I won't need to and I'll implement it only when you need it, if ever." Of course they can do this if they like, and it is indeed a good idea/gesture, but by not doing this they are not being dishonest or disloyal, nor are they mismanaging their time. The customer still gets what they wanted and/or paid for.

-- Sure he did. I can devide by zero, and it may or may not crop up if the project changes direction. It is still a BUG.

No, it is a POTENTIAL bug. A bug is a defect in the system, one that causes it not to function correctly. If the project never changes direction then this potential bug will never see the light of day.

-- I met my share of programmers that felt that having a VS installed on their laptops made them god, but our industry should understand that it is an just like any other, and grow up. Even in our line of work, a customer is a customer, and should be treated like one.

This is a bit out of left field so I'll chalk it up to you being burned by crappy programmers in the past. I am sorry to hear that, but I treat my clients well and they are happy people (well, most of the time).

-- Again, it is not your decision to make. It's not your money, and it's not your time. It's the customer's (or employer's) and he should be at least notified of this tradeoff.

I think you assuming here. If the project doesn't change direction then what trade-off is there? Time spent now vs. only spending time if/when it's needed?

-- I worked with several large organizations, that held hiding bugs under the hood a justified cause for lay off. I can't say i totally disagree with them, even if the hiding occures under a cape of a notable principle such as YAGNI.

I think hiding bugs is a bad idea too and I don't condone it. I feel the programmer should have done what they did, bring it up and hopefully document it. Whether or not it is a bug seems to be the heart of our debate.

After re-reading this reply I am tempted not to post it, but it took me a while to write so I might as well. Without knowing the details of the situation though we are both making assumptions (the severity of the bug, whether it even is a bug, is it being hidden, how likely is the project to change direction, what is the developer/customer relationship etc.) and we are both making arguments to justify our own assumptions.

In the end I'll just agree that hiding bug is just plain nasty, even if I disagree with that interpretation of this situation.