>Being able to avoid complexity by finding simpler solutions.
This is one of the most important ones, IMO. Sometimes it may also mean reducing the size or scope of the problem itself - because YAGNI (where Y is the customer), or AYRSYNI (Are You Really Sure You Need It - TM me :). Seen it done by my managers a few times, and done it myself a few times (sometimes successfully, sometimes not), as a consultant.
I had read about in a book by Steve McConnell, IIRC (maybe his book Rapid Development), but did not get a chance to try it in a real life project - yet.
I wasn't aware of the term, but I often give myself up to 2x the estimated time to do something... once I hit 150%, I'll do something less elegant that can move things forward and punt the issue for now.
Perfect example, starting on a new SPA, wanting to use latest/greates React/Redux/Webpack/Babel tightly coupled to a Node API latest Koa and it's ilk. For the life of me, could not get the Webpack dev server bits to work with Koa. Spent about a day and a few hours on it... finally decided to run the node server on a separate port, and have the webpack dev server set to reverse-proxy to it. I have no current plans to run websockets on my backing service, so it works for now, but not the integration I wanted, the way I wanted it.
To me, it's just being pragmatic with my time... I was explaining to a friend who asked, "were you pressured into these time constraints...?" and my response was no, it's just I wasn't going to delve into a week+ of work to get things the way I want only to provide minimal value, while the larger OSS dev community will likely provide a better solution before I can circle around to it.
I love OSS, I participate when/where I can, and appreciate all that everyone does. If you're working on something that can be separated out, that isn't a core to your business, why not put it out into the world and save someone else some time down the road. I mean a lot of things are of varying quality, but if they provide value and save myself or someone else time, I'm all for it.
Where I feel bad are the projects that start off small and hit a critical mass where the support exceeds the time/expense to support something. It's always a matter of reaching a pragmatic balance to one's efforts.
https://en.wikipedia.org/wiki/Timeboxing
I had read about in a book by Steve McConnell, IIRC (maybe his book Rapid Development), but did not get a chance to try it in a real life project - yet.