Remove the Stupid degrees of freedom

This is what almost all progress in areas of productivity and security is about – remove the stupid degrees of freedom. Sure there are people out there arguing that life is less electric when builders do not fall off skyscrapers in production due to guard rails in front of all +1meter drops. And yes, they will also argue that driving with the seat belt fastened is for people that should not drive a car in the first place.

You may wonder what seat belts and not falling off tall buildings has to do with degrees of freedom? Your body is free to continue in your given speed even when the car halts abruptly if you do not where a seat belt. Hence you have a degree of freedom that will never ever be beneficial to you – and that is what I mean when I say “stupid degree of freedom”. The seat belt effectively removes your freedom to die violently even with collisions in moderate speeds.

Your gut reaction might be to say STOP I want to keep all my degrees of freedom – even the stupid ones – those that will never be beneficial to you. But if you are an intelligent and sane person you will soon come to the conclusion that I am right – stupid degrees of freedom should be removed wherever possible.

We have been removing and reducing the stupid degrees of freedom since intelligence took off. Reducing in like – do not smoke – or at least not continuously – if you want to stay alive. We put up traffic lights – and even if there is nothing stopping you running a red light – most sane people just choose to not use the stupid freedom to crash out in crossing traffic, and most of us appreciate the help the traffic light gives us in order to avoid a possibility that is stupid. We put lids over the sewage-entrances in the street – making it almost impossible for you to fall in – even though you could just as well avoid all those holes. The lids are effectively removing the stupid degree of freedom to fall down in one and break your back.

You get my point. Once you start to look at improvements in any field as reducing stupid degrees of freedom you will see that the description is a good one.

But why do I bring it up?

Well we need to talk about software development.

You think there are a lot of degrees in freedom in the physical world? Well there are millions and millions more degrees of freedom in the software world. Most of those freedoms are stupid and never beneficial – like software bugs.

In the physical world we have an environment that we cannot argue with or redefine; like we cannot walk through a brick wall and we will not turn into smoke for no reason. But in the software world we have no such basic limitations unless we stipulate them ourselves.

Any sane software developer would set up some basic rules to reduce the most stupid degrees of freedom you may think?

Do not be too sure.

This is were things turn ugly pretty quick – there is a standoff between developers using strongly typed languages (c#, Java, c, c++) and those that use weak/dynamic typing (javascript, assembler ) https://en.wikipedia.org/wiki/Strong_and_weak_typing

In short you can think of strong typing as “I first set up rules – then if I break them the compiler will let me know” – and that is pretty much to say what should be allowed and remove all other stupid degrees of freedom. Dynamic typing removes very few stupid degrees of freedom – and you will need to be very careful or your program will not do what you wanted it to do – very macho – “if you cannot avoid stupid mistakes you should not touch a keyboard in the first place”.

Most software developers has a self image like this:

But if you are focused on the result rather than being very cool you are probably looking for someone like this:

Who has the most degrees of freedom? Who is looking more professional? Who is almost guaranteed to survive the day?

When it comes to software development you want to ensure that:

1. You have quality built in so that you need very little test to verify basic function
2. You should be almost guaranteed success on reaching the functionality you want without people having to act heroic in any way

The way to reach this is by starting to remove many of the none beneficial degrees of freedom from the program/system.

But how can the system know what is beneficial to you and not? Well that is where the specification comes in – what is the system supposed to do? If only there were a way to declare what the system should be all about… Like UML.

What UML does is something that any sane person would want for any endeavor they take on; it defines the base rules on what you want to allow – and it does so in a way that has no alternate interpretation.

That means that UML is the un-ambiguous language you would want to write a specification for anything in. You would want to express your specification for software unambiguously since there are so many possible degrees of freedom that are just plain stupid – but sadly more likely (just because they are so many) than the degrees of freedom you really want.

Ok – I have now reached the point in my argumentation where I have left you with a suggestion to write a perfect specification in order to have a perfect system – and you may think that this is not really helpful – since it impossible to decide in before hand what the specification should look like. After all there were good reasons we ditched the waterfall-planning-strategies of the 1990’s in favor for the agile approaches with short term goals stacked on top each other. True. But I am not finished yet. There is a piece missing.

1. We must describe what degrees of freedom we actually want in order to be able to avoid the ones we do not want.
2. If we can manage to describe what we want in a language that has no room for alternate interpretations – then implementation has no degrees of freedom left – it must follow our specification
3. If the implementation must follow our specification there is no risk involved and we will always succeed

Wow. Success is guaranteed?! Yes – if there is no need for free climbing heroes in the production – it will never fail.

Now let us take this approach one step further: if there are no degrees of freedom left when we follow the specification to get the result – then we can easily build a machine that does it for us – after all – very little smartness is needed following instructions that are complete, exact and with no room for interpretation.

Now you have MDriven.

And now we can take back the agility – but not on the level of implementation and coding – but on the level of specification.

This is the reasoning that has led us to claim that MDriven is a million times faster than traditional coding praxis’s:

MDriven works by allowing you to describe what your system should do – then – a second later – your system allows you to do exactly that.

The true value of your efforts are in the description of the system – just as it should be – this is the intellectual capital that survives tech-shifts that will happen as time goes by.

This piece was written to help you to understand why some of your hero-developers  might be reluctant to adopt MDriven. But a strong hero will always be needed for stuff – we are just saying that you do not need heroism to write 99% of the software you need today and tomorrow – a good evolving specification will do just fine – and you still need really sharp heroes to think out how to evolve the specification to reach your true goals.