Taking a programming approach to solving any problem

I am an engineer by schooling and a programmer by googling. On second thought I am probably an engineer by googling too. When learning to code there are certain principles ad good practices you come across, typically these are not hard rules that will break your program if you don't follow them, they are more like guidelines that will make your work easier and your program much more efficient. At some point it hit me that many of these good practice programming principles apply to many problems that require structured solutions. A lot of the best problem solvers and efficiency experts use these same principles without necessarily knowing that these are the same principles followed by programmers. So here are three basic programming principles that can be applied almost everywhere;

The DRY/SSoT principle

DRY here means Do not Repeat Yourself; This particular principle in programming is also known as the SSoT or Single Source of Truth principle. The basic idea here is that there should be only be one single unambiguous and authoritative source for every piece of information. There shouldn't be conflicting sources of information for any particular function. For example, you shouldn't have policemen directing traffic while traffic lights give conflicting directions. If you should have both then one should get its directions from the other, i.e the police could simply enforce the direction given by the traffic lights(or vice versa if you can pull that off).

The SoCs principle

Separation of Concerns is another fundamental programming principle. What it means is simply modularity. In programming this means dividing a program into sections, each section concerned with a different issue. In other fields applying this principle would mean breaking down each problem into sections that can be managed by separately. Ideally a supervising section only says what needs to be done and then gets waits for the response. However there is a need to be careful here since too much and the overhead starts exceeding the benefits(e.g too many districts in Uganda)!
Also key to modularity is that each section should be as self sufficient as possible, for example if you want less plastic bottles littering the city, a tax say 50 shs may be levied on every bottle, that 50 shs would be redeemable once the bottle is returned to a collection points by anyone. That way the bottle pays for its own cleanup. Similar methods could be applied to things like city posters, buveera etc

KISS

Keep It Simple Stupid; This one should be fairly self explanatory, don't unnecessarily complicate things when there is a simple solution available. Don't add components you don't need, too many checkpoints will lead to stagnation of any process. Make it easier to get things done. For instance if you want to encourage entrepreneurship make registering a company easier, cheaper and faster. You want a National ID, policy how bout just get the company who made one of the best in world(Malaysia's MyKAD). Its cheaper than what we have spent so far!


These principles might seem pretty obvious and you might actually be following them already, however its something else to put a name to it and actually know what its called. The other thing stating these explicitly helps in optimizing. Knowing these helps to know what can be optimised and made more efficient in any system.
Generally I believe a programming like approach to problems is generally a good way to solve them efficiently and with minimal input and/or supervision.