![]() If it's used three or more times, look at writing an abstraction that suits us TODAY, not for the future. If it's used twice, copy it, it's better. ![]() "If something is used once, ignore any abstractions. You shouldn't go too extreme on the " write code for right now " side of the spectrum, or you're left with a hacky mess that needs to refactor every time the codebase is touched. I don't want to fix a heavily abstract bug because I wonder if what I am fixing will break other parts of the system. ![]() The only thing that all engineers can hope for in such abstracted layers of code is that there won't be a bug in that system. You need to explain such layers of code that are hard to debug. You spend a lot of time trying to make the code beautiful, layers upon layers of elegant abstraction that is ingenious and worthy of a Ph.D. Now, they have to spend three hours during a whiteboard session explaining, in deep frustration, how that complex abstraction works. They waste engineering time and resources arguing with other engineers about the future that may never happen - arguments that are mainly speculation.įast forward to the future, the company hires a new developer who needs to develop features on top of the overly complex framework that they did. They must prove that they can prophesize the future if they get any pushback against their layer cake of abstraction and design patterns. Then they leave with infinitely extensible and scalable code that is neither easy nor scalable because no one can understand it. "We want to abstract this function into a strategy design pattern because what if marketers want to implement more algorithms?" "We need to put in a Queue to make it asynchronous because what if we have a high load ingestion and the server is overwhelmed?" ![]() "What if in 6 months we also need X capability? I can add another layer of abstraction that will make this extensible." "How can I make this as reusable as possible?" They become obsessed over every feature they design and every piece of code they are about to write, Thus, all possible designs cause you to invent scenarios where your special code will be useful under the new imaginary future condition. One root cause that made engineers think about code reusability is that the product requirements keep changing.
0 Comments
Leave a Reply. |