A good solution applied to the wrong problem is still the wrong solution. Do not apply design patterns just because they worked elsewhere.
-
-
Replying to @DaveHogue
@DaveHogue ...Over-engineering for the sake of "future-proofing" creates more work, not less1 reply 0 retweets 0 likes -
Replying to @davecathcart
@davecathcart How far into the future do you future-proof for? Is there a Pareto Principle for time?3 replies 0 retweets 0 likes -
Replying to @DaveHogue
@DaveHogue …Better to embrace this fact. Keep it simple, and don't be scared to continually refactor code as requirements evolve.2 replies 0 retweets 0 likes -
Replying to @davecathcart
@davecathcart Slightly different for design (sometimes), because we often need to design "places" for things we know will be added later.5 replies 0 retweets 1 like -
Replying to @DaveHogue
@DaveHogue probably depends on the nature of work as well. In my current role, we deliver working software incrementally, ever 2-4 weeks3 replies 0 retweets 0 likes
@davecathcart we usually have a feature map, and our cycles are much longer (6 months on average), so we "see" up to 36 months out.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.