You Need a Novelty Budget (2018)(shimweasel.com)
shimweasel.com
You Need a Novelty Budget (2018)
https://shimweasel.com/2018/08/25/novelty-budgets
16 comments
[deleted]
A very similar concept is the idea of the innovation token. You only have some many tokens to spend innovating.
I came here to say the exact same thing, and it was linked to in another comment here at Dan McKinley’s (mcfunley.com) blog.
I have been served very well by wisely spending, or choosing not to spend, my innovation tokens on any given project. And the cap of 3 tokens really does seem to be a good level.
I have been served very well by wisely spending, or choosing not to spend, my innovation tokens on any given project. And the cap of 3 tokens really does seem to be a good level.
I feel like this is the often repeated maxim of "use what works" with the argument inverted and with some extra embellishments.
'Only use novel things that are actually needed and can be accomplished in a reasonable time frame'
Good advice and I like the novel the argument approach.
'Only use novel things that are actually needed and can be accomplished in a reasonable time frame'
Good advice and I like the novel the argument approach.
This sounds like saying “Do what leads to your desired outcome.” Vacuous statement.
Given the tendency to drive toward Abilene, I don't think it's vacuous. Sometimes it's easy to get caught up in groupthink and neglect the hard question of whether something is really helping achieve your end-state. There's nothing vacuous about cautioning people not to fall into that trap.
McFunley had a whole piece on this called "Choose Boring Technology"...
https://mcfunley.com/choose-boring-technology
https://mcfunley.com/choose-boring-technology
Maybe two things to consider in implementing this:
(A) some things cost more than others, based on newness, familiarity, etc.
(B) everyone should agree on A, because teams are only going to integrate novelty based on the individual least comfortable with it.
(A) some things cost more than others, based on newness, familiarity, etc.
(B) everyone should agree on A, because teams are only going to integrate novelty based on the individual least comfortable with it.
This is good advice, except....A lot of recruiters and managers aren't terribly focused on results and the quality of software. They often want to see a resume that looks like a word cloud of tech trends and buzzwords. A lot of developers would be happy to stick to "boring tech that works", but are afraid of being labeled as some dinosaur who's resistant to change and won't learn new things. Until recruiters and hiring managers stop rewarding mindless novelty over things that work, we're all going to be awash in mindless novelty.
It's usually not managers who are chasing the latest buzzword but employees who don't want to be stuck with legacy technologies. The elephant in the room is that most technologies fail to gain traction and employees understand they have to curate their resume to maintain relevance and employability. All too often technologies are chosen to appease that, not based on a clear-headed assessment of the benefits and risks.
The designers of the videogame Civilization at Firaxis said they had a 3-thirds design budget for each sequel:
* 1/3 you keep the same, keep it familiar for those who know previous games
* 1/3 you improve on iteratively, gotta make things better someplace
* 1/3 is completely new, like the borders in Civ4, or the Hex grid in Civ5. This is the risky stuff
I think it's a nice and easy heuristic, ensuring you have a stable foundation while offering opportunities for creativity, and it can apply to many other fields than game design.
* 1/3 you keep the same, keep it familiar for those who know previous games
* 1/3 you improve on iteratively, gotta make things better someplace
* 1/3 is completely new, like the borders in Civ4, or the Hex grid in Civ5. This is the risky stuff
I think it's a nice and easy heuristic, ensuring you have a stable foundation while offering opportunities for creativity, and it can apply to many other fields than game design.
You have sold me on COBOL. No churn and predictable results.
COBOL is still alive :)
[deleted]
I don’t think this applies to side projects as much though. There more risky makes more sense
I like the concept we used at GitLab since beginning: boring solutions. Whenever you have to pick, you pick the boring one. It almost always pays off.