25 ms·
I personally think that you’re doing the right thing. Thinking too much about extensibility too early or applying patterns often makes your code overengineered,
by d--b 5y ago
I personally think that you’re doing the right thing. Thinking too much about extensibility too early or applying patterns often makes your code overengineered, and in no way can guarantee that it can be extended in the right direction.
Having to rewrite existing features differently is mostly a consequence of you not being an expert in the business application you’re writing.
Maybe if you’d invest more time upfront to understand deeply what the application is for and how people are going to use it, you’d be able to spare a few mistakes.
But even being an expert and talking to people doesn’t shield you from that problem. There is always a new feature that contradicts how the code works. It’s just a consequence of software being so malleable.
As a car driver, you can’t ask the car maker: “hey can the needle on the speedometer turn red when I go over 60?”, or “hey I need this car to work with both gas and diesel?”
This would be perfectly reasonable in a software equivalent world.
In the end, you just need to explain this to your client…
- rlayton2 5y agoThanks for the comment. I am generally a technique expert rather than the domain expert in a project, so your comments about "being an expert" definitely makes sense.
- sam_lowry_ 5y agoTry to reduce the number of lines of code, and, at the very least, use languages and tools with refactoring support. I find that I am much better at delivering ad-hoc solutions when the codebase is small.