Trying to work in this political uncertainty is really hard.
Diversity on a team is helpful. https://hbr.org/2016/09/diverse-teams-feel-less-comfortable-and-thats-why-they-perform-better As I understand it, one of the benefits of diversity is that it breaks up the team's decision-making flow, causing decisions to be discussed and made deliberately, rather than swiftly.
How can I quickly achieve some of the benefits of diversity, without, for example, switching teams to a more-diverse team, or getting someone else hired or switched to be on my team? Computers are alien, I am a computer programmer, could I create an AI to be on my team? No - that would take even longer than involving HR. Complicated "german" card games sometimes have "AI" which is merely a page of rules, possibly using dice, a few counters, or a few decks of cards as its internal state. For example: http://www.gmtgames.com/andeanabyss/6_FARC_FlowchartITA.pdf
What would happen if Congress had a magic 8-ball as one of its members? For simplicity, instead of the usual ratio (ten affirmative, five negative, five noncommittal see: https://en.wikipedia.org/wiki/Magic_8-Ball) let's imagine that it is fair, with ten 'yay' and ten 'nay' votes in it.
Votes that were barely-safe before the addition of the magic 8-ball would become risky. Possibly the majority would engage in more coalition-building, beyond where they would have stopped. Possibly the minority would strive to bring more proposals up to that risky level, because there's a chance they would succeed. I don't know all the consequences, but it seems to me like adding 8 or 10 magic 8-balls to Congress might be a very good thing.
In practice, the rules of parlimentary procedure probably can be adjusted to game this. For example, if the minority could put 2^10 identical-in-practice proposals forward, then the 8-balls would be expected to vote for the proposal in a bloc once. Or something about dividing the intended legislation into N pieces might effectively force the 8-balls to act like members of the majority. Maybe a policy of choosing a random Congressperson, and then imitating their vote, would be better?
Anyway, the point of this thought experiment is, having even as simple an "AI" as "random" in your team decision-making process disrupts and changes your decision-making process, possibly for the better.
Michael Brough writes about deciding, as part of his game design for Imbroglio, to obsess about the number 4: http://mightyvision.blogspot.com/2016/08/imbroglio-notes-8-score-o.html This is like collaborating with a simple "AI" that claims and argues that 4 is the right answer to any game design question.
Systematic Inventive Thinking, TRIZ, and similar moderately rigid design methods, such as Jackson Structured Programming, are like a collaborator who is not random, not constant, but follows a rigid flowchart. Realizing that these design methods can be framed as "collaborating with a teammate who thinks differently" helped me understand something that had puzzled me for a long time. Using a method often helps, but which method you use doesn't make a huge difference. Better flowcharts are probably some better, but adding a flowchart-AI to your team might help by breaking up your decision-making flow, causing you to think about different aspects of the problem, to decide deliberately and so on. All almost regardless of the content of the flowchart.
The flowchart methods are often not up-front about how much backtracking is actually involved in programming (or, I imagine, design generally). If you read all the accompanying text, then the books do say there is a lot of it, but in the compressed form, they usually have "fake time" fairly visually prominently displayed. By "fake time" I mean the kind of thing "Rational Design Process How and Why to Fake It" is talking about. After the project is finished, you can prune off the messy dead ends of the backtracking search process that led to the conclusion of the project. Retelling this golden history from the beginning to the end is "fake time".
I think it would be more honest, and more useable, to express these rule-based collaborators as a prioritized list of questions, with a short list of actions (often one) associated, something like a World of Warcraft "rotation".
- Is Combustion off cooldown? Use Rune of Power.
- Does Rune of Power have at least 2 charges? Use Rune of Power.
- Does Phoenix's Flames have 2 charges? Cast Phoenix's Flames.
- Are you on a Hot Streak? Cast Pyroblast.
- Are you Heating Up? Cast Fire Blast.
- Cast Fireball.
This does not prioritize communicating the idealized time sequence, over the minutes, hours, days, and weeks it takes to develop software. It instead focuses on the actual, practical decision structure of "what to do next", and the span of time described by the list of questions is very short (seconds or less) and occurs over and over again.
That is, "We go round and around, first Red, then Green, then Refactor" is communicating the idealized time sequence, but Kent Beck's Four Rules of Simple Design look more like a decision list:
- Are the tests failing? Fix the tests.
- Does the code reveal your intent? Refactor (and/or rename) to make your intent clearer.
- Does the code have obvious duplication? Refactor to eliminate duplication (often introducing a new class/module/function).
- Is there a way to accomplish this with fewer classes/modules/functions? Refactor.
For example, one emergent consequence of the prioritized list is that if you rename to make your intent clearer, and then the tests start failing, then you should fix the tests, not go on to the "next step".
I'd like to see more design methods that explore the space in between rule-based design methods (like SIT, TRIZ, JSP or Beck's Four Rules) and dice or decks of cards (like Brian Eno's Oblique Strategies). Because of course I would.