Design and implement a new Silk Road, with an architecture that resists detection and takedown far more vigorously than the earlier incarnations. You'll have enough to retire on within months. Problem solved.

Above and beyond any specific policy areas such as coding standards, seniority mixes and son on, the biggest and most important thing to manage is the overall software development culture. If you can energise the culture, and inspire people to believe in the mission, to fight for it like their own flesh and blood, as well as to honour each other's diversity of perspectives, you will achieve far more than by drawing policy lines in the sand. Keep it fun. Make the crew feel special. Give them a feeling that their futures are within their control.

This said, I would also recommend frequent peer code reviews - this will inspire better work, knowing that people are accountable to their peers. Also, be on the lookout for single-sourcing, and fight it off like the plague, even if it has a productivity cost. Yes, Natalie is brilliant with the middleware. But what if she gets hit by a bus, or leaves to have a kid? Defend in advance by ensuring there are others who can instantly step in and take over from her.

Again - an energised culture with a strong team spirit - a deep and powerful soul - will optimise the workplace far better than any arbitrary standards.

Give this man a big white pointy hat with eye-holes

infamous Gay Bomb!

There is a social scheme to provide a level of relative security for an encrypted time capsule:

1. Choose n separate trusted individuals or organisations, ideally scattered around the world and unaware of who each other are
2. Gain promises from these entities that they will each send a block of data to the time capsule at a given time, and not before
3. Decide by policy how many of these entities (m) should be required to do their part, for the time capsule to be decrypted
4. For every combination of m entities, generate m strings, where the XOR of all these m strings arrives at the decryption key
5. For each of the n entities, issue the required number of strings (n-1)C(r-1) required to contribute to every combination of m entities of which this entity is a part
6. Each string is prefixed with a binary string of n bits, indicating by true/false values whether the string is part of a group of each of the n respective keepers
7. The whole set of strings given to each entity would be prefixed by a 'keeper number' and then encrypted
8. The time capsule curator destroys all record of who these trusted agents are, and relies on them to send their keys at the appointed time

Example - 10 keepers chosen, 4 in UK, 1 in Iceland, 2 in Australia, 1 in USA, 1 in Uruguay and 1 in Morocco. Policy chosen so that the cooperation of 7 is required to decrypt. Each keeper then is thus issued 84 strings. 1 agent dies, another agent gets busted, and a third agent becomes opposed to the decryption. This leaves 7 agents. They each send their key packages in to the time capsule curator, who decrypts each package, identifies which string within each package is need to form the key, XORs these strings, then arrives at a final decryption key. Even if an intelligence organisation manages to extract keys from 6 of the agents, they won't be able to decrypt. If on the other hand, they kill up to 3 of the agents and stop them returning their keys, the decryption can still go ahead. Ideally, you would want to set n and m according to perceived risk, plus the size of the data set. For example, 36 agents and 20 required would produce a key set which would fit into a cheap 8GB USB stick.

I can only guess that this is Australia after North Queensland has seceded off into its own banana republic

...Google Balls!

The job market is very tight, so employers are spoiled for choice. They will seek employees who can hit the ground running immediately. In this environment, they see even a week's learning curve as a waste, and would rather hire someone ordinary who can be immediately productive rather than someone great who might take a little longer. Watch out for this changing as the economy recovers, and jobs again become an employee's market.

Self-driving cars means that people will be able to drink and "drive" to their hearts content, legally and safely. This will help to rejuvenate the ailing club/pub scene and maybe restore the live entertainment industry to grace. It would make sense for liquor companies, pubs and clubs to invest substantially in autonomous vehicle tech. Anyone up for a new "Roaring 20s"?

...credentials to my Mailinator account :P

Rule 34. Or, in other words, a major internet industry needs to VC the development of advanced tactile transducers.

On my motorbike, I'd feel much safer if all the cars around me were driverless. Human car drivers, who so often tend to blank out half-unconscious and fail to check blind spots, are the leading cause of death for bikers.

From my R&D experience across many companies, it's clear to me that a "software engineer" is a proper superset of "developer".

1. A 'developer' is paid to create code that works within the company's contrived runtime environment and passes a few stages of testing, while a 'software engineer' is also paid to ensure the code actually works reliably in this nebulous abstract construct called the "real world" - customer/client installations where there are innumerable environmental variables and things that can go wrong.
2. A "developer" nods timidly and reluctantly to Murphy while passing in the corridor. But the software engineer says "Thanks for another great night. What would you like for breakfast?"
3. A "developer" goes whining to her/his team leader when the tools or OS play up. A software engineer cracks out the machine-code debugger, logic analyser and oscilloscope, traces all the API calls, and spits out working patches for the bugs in the libraries, drivers and kernel.

If I had some plant that was failing at 3:15am and costing me a fortune, I know which I would prefer to have on site.

But the Supreme Court had no choice but to stand up for justice. No going soft on patent abuses!