Solution domains

Problems and solutions exist within certain domains and when the problem and solution domain do not match, the result is usually less than ideal. This is not to say that solutions in other domains always are bad, they're not. This is especially true when there is no solution in the problem domain.

People vs Technology

Note: I use the term developer loosely here, meaning anyone involved in software development on a technical level. Official title may be tester, UX-designer, data engineer, etc.

One mismatch I see quite frequently is the people/tech domains.
Here is a chart with the mismatch marked.

It may not be immediately obvious why the cross-domain solutions are problematic. So let me share some examples.

All developers must use the same IDE

This is a Technical problem with a People solution. The Technical problem being solved is the one of "works on my machine" - local configration affecting builds or running code. The solution is in the People domain: a rule specifying that all developer machine should be identical as far as possible.

Not every application of this goes the whole way and specifies that every bit of software on the computers have to be exactly the same, but that is how far you must go for this to be completely effective. The extreme nature of the complete solution is a tip-off that the problem and solution domains are not the same.

The proper solution in this case is to use a build system which controls its own environment to the necessary degree. Paired with dedicated integration computers (perhaps powered by a CI deamon) this solves the problem by redefining what works means.

If it doesn't build on the integration computer it doesn't work. If it doesn't run on the integration system, it doesn't work. I don't care if it runs on your machine, if you cannot make it run integration system it does not run.

So let devs use whatever development environment they want, as long as the code works on the integration system. Happier people are more productive, more creative people.

Use tool X to get through the company proxy/firewall

This is a People problem with a Techincal solution. The people problem is the faulty assumption that the more we lock everything down the more secure our own network will be. The solution is a technical one: A tool to circumvent restrictions put in place.

Developer machines are difficult to secure properly. You cannot restrict what a developer can run on their machine in a reasonable way,since arbitraty binaries must be able to run (the software being developed). Which means that there is pretty much always a technical workaround.

A proper solution? Make security an explicit policy, extreme security requirements calls for extreme policies: Separate development machines from the internet completely. Let them have their own network and inform developers of why this is necessary. This last step is the most important.

The cost of security is vigilance. Attackers need only find a single security flaw, but defenders need to plug every hole. Defense in depth, proactive security on ALL levels, are general strategies employed in the security industry to reasonable effect.

Information is key. Inform people of why security is important, what the ramifications are when a breach happens, possible attack vectors, what types of attacks exists. You cannot defend against that which you cannot imagine.

Trust is paramount. Make sure you build networks of trust with your employees and collegues. Put audit trails in place, so that when something happens, you can trace it and rectify the trust problem. This usually mean personal credentials everywhere.

What does NOT work is hindering peoples day-to-day activities, they will just find a workaround which will inevitably open a larger security hole. It will also make people hate the security group and not want to work with them. This is an anti-security pattern.

Make sure that people have the access they need to do their jobs. This means opening up that proxy to outbound traffic that is needed by developers or setting up tunnels to the resources that need to be accessed. Make it as easy as possible for your developers to do their jobs.

The best security is the one that flows through everything you do, but yet it does not disturb you, you do not notice it.

Summary

Watch out for solutions which are not in the same domain as their problem, such solutions may indeed do more harm in both domains rather than solve anything. Challenge such solutions in their validity and prefer a solution native to the problem domain. If you cannot find one, ask an expert in the field or find out how others have solved the same problem.

There is a lot more that can be said about this subject. I will most likely be able to add more examples, although I wish I would not.