YAGNI and the Crystal Ball of Software Architecture

YAGNI and the Crystal Ball
How often have you been involved in a project, and someone starts a statement with “It would be really cool if … ?” The second I hear that, I find myself evaluating what comes next with high degree of skepticism. First of all, it usually would be “really cool,” but that doesn’t mean we should do it. Too often these ideas solve a problem that you won’t ever have or will not have in the foreseeable future.
YAGNI = You’re are not going to need it
Sure, it would be pretty cool to have a full plugin architecture, but do you really need it now? Let’s gain some traction, iterate, and then we’ll determine if it’s really necessary. Doing it because it’s cool only wastes time if you figure out that the users don’t really care. YAGNI.
Always design for current needs, leaving yourself open for the foreseeable future. Forget about the using the crystal ball to guess what your users will want a year from now. It’s far better to get something in front of your users sooner and find out what they really want. Even if a year from now you have to do a major refactor because something in the crystal ball came true, you will have a user base now and a good reason to make the change. You did iterate to get there, didn’t you?

How often have you been involved in a project, and someone starts a statement with “It would be really cool if … ?” The second I hear that, I find myself evaluating what comes next with a high degree of skepticism. First of all, it usually would be “really cool,” but that doesn’t mean we should do it. Too often these ideas solve a problem that you won’t ever have or will not have in the foreseeable future.

YAGNI = You’re are not going to need it

Sure, it would be pretty cool to have a full plugin architecture, but do you really need it now? Let’s gain some traction, iterate, and then we’ll determine if it’s really necessary. Doing it because it’s cool only wastes time if you figure out that the users don’t really care. YAGNI.

Always design for current needs, leaving yourself open for the foreseeable future. Forget about using the crystal ball to guess what your users will want a year from now. It’s far better to get something in front of your users sooner and find out what they really want now. Even if a year from now you have to do a major refactor because something in the crystal ball came true, you will have a user base now and a good reason to make the change. You did iterate to get there, didn’t you?


Posted

in

by

Comments

Leave a Reply

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