|
|
|
|
|
|
by r2dnb
3377 days ago
|
|
|
I agree with Twisell. The solution is to create a super data-structure so this really is an architecture and abstraction issue - ie. design things in a way such that these structures can be added in an incremental and painless way when the need appears. Only a minority of people are good at that. I'd also note that there is a correlation between the importance of such needs and the ability to anticipate them at the initial design stage. (ie. is it reasonable to be surprised by the fact that a holding owning several supermarkets asks for consolidated reporting at some point ?). If you're good at abstraction, modularity and composability, there really isn't any gotcha to fear. Stuff don't just come out of the blue. |
|
|
How do you create a data structure for a requirement that doesn't exist at the beginning of the product?
Most of the time when I've seen someone design data structures in a way that attempts to design for unknown or predicted future requirements, the design ultimately becomes over engineered and a nightmare to maintain or expand in ways the actual product requires down the road.
I'll always pick the concrete implementation as long as future requirements are unsure.
I don't know how you get good at magically guessing how your product needs to evolve, e.g., what new industries is your sales team going to crack into, what direction does marketing want to take your product, etc - the only way you could be "good" at that is when the direction is extremely obvious or you have unilateral decision making on every point of your road map.