Thursday, 15 May 2014

Logic or laundry list?

Just as a person with a good understanding of English and nodding in understanding , when told that "E is equal to MC square", does not make for a genius, similarly, piling up a list of 'permutations and combinations' does not make for good application of logic.

Below is such an example that I came across recently.

A file being opened from a Open Dialog box, of the same name and from within the same file.

I have seen some teams go into a frenzy of analysis over such a simple use-case of "Open a file" and believe it to be a thorough analysis whereas, it is the classic example of "over-kill", "over-analysis" (similar to it in normal life is what is called "Beating about the bush"), where a person uses a crane to pick up a bucket just because, being an Engineer, the 'world' (a collection of people hardly numbering above two digits) would be agreeable to the idea.

There are some fine boundaries that define every field of study, and logic, due to the increase in population, has become multi-layered for some types of people (maybe due to lack of maturity, knowledge or clarity in attitude and approach towards life) but that does not in anyway redefine the application of logic.

Even if "a 'kid' can program nowadays" adage may be true but the fact remains that the many other 'layers' in the above example, like education, training, time, context and many etcs that come before it will make a difference in either speeding up the "kid's" application of logic or in becoming a totally useless application of a  'laundry list' of scenarios that may just affect the design, performance, speed and security of the program logic!!

So, what then is 'solid logic' in today's world?


Only that logic that stands up to tests and succeeds, is 'logical'.

Not the knowledge of operators or all that computer science nonsense jargon but simply, tests.

Not tests as 'software testers' believe tests to be but tests that have a conceptualization point before any implementation of logic - what is called Tests Driven - Development or Design.

What makes this (TDD) the most workable technique is because of the multi-layers that the external world imposes on an use-case even before it reaches a design table.

It is like trimming and sprucing a problem to find what is the real problem that needs to be solved because unless you know what the real problem is, will you not simply be 'beating about the bush' ? :)

No comments: