Reasons not to overdesign a solution to a current problem [closed]

Question

G'day,

While having a think about this question here about overdesigning for possible future changes it got me thinking.

What reasons against can you provide to people who insist on blowing out designs because "they might want to use it somewhere else at some stage in the future"?

Similarly, what do you do when people take the requirements and then come back with a bloated design with lots of extra "bells and whistles" that you didn't ask for?

I can understand extending a design when you know it makes sense for requirements or possible uses that exist either right now or in the near future. And I'm not advocating just blithely accepting a list of requirements and implementing that explicitly without providing any feedback on what you think may be missing.

I am talking about what to do when people insist on adding, or having, extraneous functionality so that "we might use it somewhere else at some stage in the future?"

Answer 1

Plenty of good reasons on Wikipedia.

http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

See also: http://en.wikipedia.org/wiki/KISS_principle

Answer 2

Especially on an embedded device, size is money (larger Flash part, say, which costs more and has a longer programming time at manufacture; or more peripheral components).

Even on a Windows application, the larger your application and the more features it has, the more it costs to develop; wait until you know what's needed and what's not and you'll waste far less money developing stuff that turns out not to be what was needed at all.

Also, any additional functionality brings with it the potential for bugs.

It's good to think properly about the requirements before developing something, but over-designing is often just borrowing trouble.

Answer 3

Them: "We might use it somewhere else at some stage in the future."

Me: "Yes, we might. And we might not. And we can't know, now, in what ways we might want to. And if we do want it at some stage in the future - that's the time when we'll know the ways in which we want it. That's when we can write it with confidence. On the other hand, if we write it today, but never need it, we've wasted resources to develop something we didn't need. And we've added to our code bloat, so it's harder to find the pieces of our code base that are in use, because we've got all this (presently) unnecessary code crowding out the useful stuff."

Answer 4

In our team we just say "YAGNI". It reminds people why. There is MORE than enough stuff on the web about YAGNI if you think you need to collate it to provide a report.

Actually, having someone say "YAGNI" to you on our team cuts a little because it's like saying "C'mon; you know better than that", which always hurts a little. :)