Never do anything until you ready to use it, in software too? [Toyota principle]

Question

I was listening to a podcast. Where they talked about principles Toyota was using.

" - Never do anything until you are ready to use it."

I think this tell us to look in other places, to learn what other practices have known for years.

Ok, here is the podcast. I think it is interesting

http://itc.conversationsnetwork.org/shows/detail3798.html

UPDATE: ok, I think it is educational, but it has a neg. count. Should I remove it?

Answer 1

It is a good agile practice to think just like that. There is also something called Test-Driven-Development, that helps you get software without bugs (almost), but also have that side effect that NOTHING is implemented that you don't use.

A example is you're own collection class. If you only are needing a Add method, and a ToArray method, then why use the time to implement the Remove and Count methods?

So yep. Follow that principle :)

Answer 2

Sort of, yes. This is a core part of the agile philosophy.

Basically, favour flexibility and speed of response over big design up front and unwieldy specifications. One of the best ways of doing that is to only build enough to meet your current requirements, because you never know when they're going to change.

Answer 3

It is old news a little. It's often called "You ain't gonna need it" ( "You Arent' Going to Need It" in non-idomatic English), and abbreviated YAGNI.

Problems associated with implementing a feature when you don't need it:

• the implementation takes time away from developing features that are needed
• the feature is hard to document and test, since if you don't need it, who knows what it's supposed to do exactly?
• maintaining the feature will take additional time
• the feature adds extra code, complicating the codebase
• the feature may have a snowball effect, whereby it suggests other features that you may then want to add, even though they're not needed

Answer 4

C2 has some more on YAGNI.