-
@mrksdck I see people that understand product evolution, feature maturity or adoption curve to understand when to focus on deleteable code. If we consider the adoption using the next chart. We can say that a feature is more likely to be deleted on Early Market than Mainstream Market.On twitter.com
❤️ 1 Favorite Mood 0
-
@mrksdck So, as a Product Engineer. You will understand that the feature is in high uncertainty and it might not fulfill a user's need. So, you design based on that hypothesis.Permalink On twitter.com
-
@mrksdck Only ONCE the hypothesis is proven true. THEN, the Product Engineer will adapt the design of the solution to a more "clean code" approach. Because it's when you have your assumptions resolved, and your code will represent the true business model.Permalink On twitter.com
-
@mrksdck We can also think of it as. Your first code is full of assumptions: - Product Needs Assumptions 👈 When proven false, worst-case scenario, you might need to delete the full feature - Business Model Assumptions 👈 You need to remodel the solution to fit an accurate understandingPermalink On twitter.com
-
@mrksdck One of the main problems with aiming to do "clean code" too early is that you might be assuming that you know your business domain model well enough to produce "clean code". So, I feel that you move your attention to the _code_ instead of the _business_.Permalink On twitter.com
-
@mrksdck Design the code to match the business reality. If the business doesn't know if that's the right feature, prepare the code to be deleted. If the business saw a huge user adoption, prepare the code to be robust and represent the domain knowledge you acquired.Permalink On twitter.com