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

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 tells us to look in other places, to learn what other practices have been known for years.

Answer 1

It may apply to software construction, but I am not sure it does apply

If we consider the five elements in a "toyota-way of decision making", based on the principle that "how you arrive at the decision is just as important as the quality of the decision":

[mode humour ON]

• Finding out what is really going on, including genchi gembutsu.

  Except that sometime, one does finally understand what is going on when the client explain to us at the end of the project;)

• Understanding underlying causes that explain surface appearances—asking “Why?” five times.

  Sure but the client is not available enough during the project ;)

• Broadly considering alternative solutions and developing a detailed rationale for the preferred solution.

  Too late, the programmers are already coding like madmen :)

• Building consensus within the team, including Toyota employees and outside partners.

  Oops that programmer is already re-writing the authentification system even though the old one was working fine

• Using very efficient communication vehicles to do one through four, preferably one side of one sheet of paper.

  Did you hear "death by powerpoint" ? This is not always our strong suit ;)

[mode humour OFF]

Seriously, as stated by the previous answers, the Agile philosophy does address some of the core tenants of this Toyota principle.

And it may be a little richer that just "You Ain't Gonna Need It", as described in the book "The Toyota way"

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

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 :)