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.
The Nations that have Ebola, have governments that want bribes and kicks back just so that non-profits can operate and help. Then even when they get there, more mafia style extortion occurs. Is there some way to change this behavior?
Give this man a big white pointy hat with eye-holes
Conceivably this bounty would be payable not only to government department employees, but also to anyone able to access government servers in the US, New Zealand or elsewhere, or servers of any companies or organisations working with these governments, who can retrieve documents clearly proving corruption in the whole prosecution process, and these documents help materially to derail Kim Dotcom's prosecution, this would most certainly qualify for the bounty."
- Choose n separate trusted individuals or organisations, ideally scattered around the world and unaware of who each other are
- 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
- Decide by policy how many of these entities (m) should be required to do their part, for the time capsule to be decrypted
- For every combination of m entities, generate m strings, where the XOR of all these m strings arrives at the decryption key
- 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
- 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
- The whole set of strings given to each entity would be prefixed by a 'keeper number' and then encrypted
- 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.
- 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.
- 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?"
- 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.