When You Know You’re Going to Need It

Home / Methodology / When You Know You’re Going to Need It

Picture a team tasked with building a new product, like so many of the teams we’ve formed or assisted.  

One team member assigned is known for an ability to envision how an entire system will work end-to-end … sometimes in only a few moments.  Early in the process, the team identifies the features or “stories” of the product that should be built first and development begins.   But after a short time we notice something odd: one of the in-house engineers who is less experienced but by all prior accounts personally productive, is basically following behind the most-senior person and deleting her work. This enthusiastic and energetic developer says,  “you aren’t going to need it”  (“YAGNI”).

The conversation goes something like this:

The algorithm to do the analytics on incoming data feeds isn’t coded yet, so I deleted the database design and code you were working on.

But … without data access the entire system won’t function… we positively know we need the database and supporting code to deliver anything that works at all.

You only foresee a need for data. That’s in the future. You see I’m coding the analytics which are really tricky for me to work on and will take a couple months. Since my code outputs data, your design and code won’t be needed until after my code is finished and actually outputting data. One the data exists then we’ll find out if we need your code.

This anecdote is fictionalized, but it closely resembles reasoning we’ve seen from time-to-time.

What about situations that are known?  That is to say, when skilled and very experienced people have a great deal of confidence about what must be built?  It seems difficult to make a strong argument that positively no thought should be devoted to what is already well-understood about software to be developed.  Introducing “you aren’t going to need it” as a motivation to deliberately ignore what’s known and understood about a contemplated product is — in our view — not very likely to be beneficial at all.

Does your development culture actively discourage engineers from using a technical approach with legs to it even when that approach can be implemented just as quickly and readily as a temporary one?  Is it truly necessary to first ship a product that displays 100,000 unsorted records and then to wait for users to confirm you’ve delivered something annoying?  Should developers become habituated to deliberately steering away from smarter code purely so we can engage in “refactoring” and “improving” the code incrementally if the product is adopted as we hope it will be?

Will users shrug off a partial product and customers become more costly to acquire as a result? If yes so, has that been factored in the costs? Does an interim solution actually cause migration to a subsequent (good) solution to be more difficult or more costly?  I would strongly prefer not to be driving “Lunar Landing Module 1.0” at very the moment I learn the “return to Earth” story will be introduced with version 1.1.

“Yagni” seems to sometimes be discussed in connection with the idea that thinking about the future would be a distraction.  But, discussions with stakeholders, understanding requirements, writing and ordering ‘stories’, even having the idea to create certain software in the first place, are activities that require thinking about the future inherently.

Our view is that when knowledge and understanding are available concerning a product to be built, those things are of value (not a distraction).  Sometimes the fastest way to get somewhere is to know where you’re going.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: