Turning problems on their head
It's often easy to find books, articles, and advice on how to do things well.
A common theme among tips and advice articles is to frame things in the positive - ‘the 3 things you should do every morning’, ‘the 10 lessons learned from an amazing company’, ‘the 5 habits of successful people’ and so on, there’s even our 5 tips for smoother software development.
So to switch things up, we’re going to think about how to run a bad software project, and look at a checklist of things to do if you want to fail.
The inversion principle
The inspiration for this piece is a high school graduation speech given in 1986 by Charlie Munger (b. 1924), who is vice chairman to Warren Buffett (b.1930) at Berkshire Hathaway.
In Charlie Munger’s address to the young students, he decided not to speak about how to be happy and successful in life (as is par for the course at these type of events), and instead chose to address the topic of how to be miserable in life.
This novel approach I’m sure brought amusement, but most importantly probably got everyone thinking in a way that a ‘standard’ speech may not have done.
A self-made multibillionaire through investments, Charlie Munger is a big fan of having an arsenal of mental models at one’s disposal.
These models are clear thought processes with which to analyse and approach problems. The ‘inversion principle’, or approaching problems backwards, is chief among his go to thought processes.
A basic example of how Charlie might use this model would be thinking to himself ‘How can I lose money?’ rather than ‘How can I make money?’ when selecting companies to invest in.
I’ve decided to follow the alternative approach of inverting problems in producing the list below:
Charlie Munger (left) and Warren Buffett (right) - Vice Chairman and Chairman at Berkshire Hathaway, both are well known for their unconventional thinking, and amazing investment returns over many decades.
Checklist: How to ruin a software project
1. Have no vision
The easiest way to fail is to have no clear mission. That way no one knows what they are doing.
If the project leader cannot articulate the direction of the project, and the objectives that must be achieved along the way, then the project is off to a great start (assuming failure is the end goal).
A vague mission becomes a fuzzy product, with poorly described features that are open to interpretation, propped up by ill-defined tasks, rampant misunderstanding, constant clarifications, dubious deliverables, and therefore no real accountability.
The department will be a hive of activity, as a lot of people will be busy working on their own interpretation of what they might be trying to achieve.
2. Tolerate poor performance
If everyone has a half-baked attitude, and performance to match, then the team is guaranteed not to produce anything of quality.
So poor performance must be embraced.
Only accept the first set of behaviours, don’t encourage, let alone expect the latter.
3. Be unrealistic
Set unrealistic deadlines and aim to do too much, this renders objectives unobtainable, and is great way to guarantee failure.
Bonus marks if everyone is stressed out and miserable, but no one stops to reassess the situation.
It's also possible to be unrealistic in other ways, for example by not addressing user feedback, or issues that came up in testing, and hoping that they simply go away when the product launches.
4. Make excuses
If a team wants to avoid building successful products, then they need to be well versed in excuses for not building good products:
‘We don’t have enough people in the team’
‘That’s not my job description’
‘The requirements aren’t clear’
‘The QA team should have caught that bug’
‘The client doesn’t know what they want’
‘I’m too busy to take on any more tasks’
‘We don’t have the budget’
5. Avoid making software
Day in, day out, week in, week out - don’t review progress in terms of usable software.
That way everything but software can be produced under the guise of progress.
Perhaps detailed (read "unnecessary") research on a competitor or new technology, long presentations or documents that no one will read, or even just give verbal updates such as ‘Today I looked into a bug that was bothering me, I hope I can fix it tomorrow', and palm it off as progress.
A simple rule to follow is that if a team is building a new product, which let's say features:
1. a landing page
2. a sign-up form
3. a confirmation email
4. a dashboard
5. four widgets on the dashboard
Then definitely don’t aim to build:
If anyone starts building something that starts resembling the end goal, ask them to write reports, or attend meetings and talk about things they might do instead. This will distract them from actually building software people can use.
If a team can follow these rules and turn hours into days, days into weeks, and if they're really good, into months - then they have succeeded in failing to get anything done.
By David Fallon
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly