I think this applies at a variety of levels on a project, too. I used to give my love of imagining futures and my love of building things free rein. But that m

I think this applies at a variety of levels on a project, too. I used to give my love of imagining futures and my love of building things free rein. But that meant I ended up building a lot of stuff that never got used, or had a bad ROI. Looking back, it just made me sad how much well-engineered stuff never really got used because I was building to my or an exec's vision, not to real needs. I still go hog wild with imagining, but now I store the results of that in bullet-pointed lists of things we might build. Then I wait for proof of actual need before hauling out an idea (or just coming up with a new one). And even then I may write a bit of throwaway code [1], to see how sustained the need is. We manually solve a problem the first time, throwaway code the second time, and only then invest in proper automation. I'm much happier working this way, and I get better results, because a) delaying design until actual need means your designs are based on maximum information, b) I have more time to focus on what matters, and c) I'm not carrying around as much out of date code to sort out when I realize the actual need. [1] Note: To make this work, you have to have the discipline to throw away throwaway code. If you (or your team or your company) have a track record of not cleaning up messes, this approach is probably not for you.