Don’t future-proof your code

What you think might happen doesn’t matter. Developers love to future-proof their plans. They want to make sure that they anticipate future needs and code accordingly. The bad news is: humans are quite bad at predicting the future. This is a key lesson. Anticipatory coding is often wasted effort. <h1>It’s a trap!</h1> Experienced and novice engineers alike fall into the trap. They try to guess what will come next. They work those changes into the current design. Practically, this means adding some extra fields to a database, refactoring existing logic to be more performant, or creating reusable resources in anticipation of more future requests. Here’s the thing… Those extra fields, logic changes, and reusable resources don’t come for free. They cost time & effort. You’ll take longer to deliver the first version when you’re constantly revising the design to compensate for anticipated needs. Unfortunately, that extra effort will probably be wasted. <h1>You don’t know what you think you know</h1> Right now, you might feel like you understand what the business will need in the future. I can promise, you don’t. If you’re lucky, you can anticipate future needs maybe 1 out of 10 times. The other 9 times, you wasted effort and complexity future-proofing a design for something that will change or won’t be needed. It’s a difficult lesson to learn. One that many senior engineers haven’t internalized even. We get sucked into the trap again and again. Writing code in anticipation of some future state. <a href="https://blog.developerpurpose.com/dont-future-proof-your-code-aad04ef75584">Click Here</a>