Coding (vs) Logic 1
Yes sir!! it is a battle of clans! Today all thoughts all ideas are going to come down here. And i am holding nothing back. It is a great war this. In the world of software development there are those believe that it is the Coding that matters more than the logic! startling claims indeed. And maybe that is the reason why they have been loosing as well. Logic undeniably is ultra important when it comes to developing software. Those who somehow claim that coding skills can outshine logical abilities, obviously have issues with their logic. But then i sat down thinking all these years and more so in the past few months, thinking if there was/is any logic in what they said. Can coding truly be as important as the logic, where it is built upon that very logic?
That was the question going through my head. And that is when i realise that, i was asking the wrong questions. While the theme was the same all through... code vs logic, the concept or the understanding behind their relation was wrong. The real question is this: Can coding truly be as important as the logic which are nothing but mechanical transformations of each other? And with great thought and pondering, i think yes! In fact, Logic and Code are equally important in the whole process of software dev, and this is irrefutable.
You see, like i mentioned above, code is nothing but the mechanical transformation of logic. While logic addresses the solution to a problem, coding addresses the solution to the problem of rendering that logic. Logic is devoid of syntax. It is concerned with the mechanics of how a given issue or problem can be resolved. And hence, it is a more universal phenomena. Be it programmer, a manager or an army General, all use logic. They all render it in their own manners. The General does it with Battle Formations, a Manager with Resource Allocation Charts and a Programmer/Coder does it with Code.
So, Code like a Battle Formation or a Resource Allocation Chart, is a tool to render the logic used to win a battle or solve a problem. If this use itself is not logical, then there will be issues. If the troops are not commanded properly by their battalion commanders then the army will loose. If the junior managers do not follow the charts properly to allocate resources, then there will be surplus at one place and scarcity at another. If the code is not used correctly then exceptions and bugs will occur. Its that simple. Now do you get the point?
Let me put it in a single statement:
Logic renders the solution to a problem, while code renders that logic.Thus, without the code, you cannot go out to kill the problem. Logic alone is not the answer. So its time that the two clans ack this and greet each other with open arms and paramount respect. Then i thought about how one should go about dealing with logic and coding. I guess that there will always be infighting between the thinkers and coders in any team. Of course the successful bunch are both: coders and thinkers. But coming back to the point, to avoid the natural conflict between logic and code, it is best to isolate the processes. Yes, there is no innovation in this age old idea, i agree. But i am talking blunt firmness. Isolate the two process completely. Do not even think about one when u are busy working on the other. My manager and mentor in my firm has been telling me this right from day 1:
When you are working on the logic/design for a problem, do not think of how it will look in code."I guess he forgot with the second part to such an apt statement. Never think of the problem and its logic or its design when you are coding. Even though you know that something is wrong, trust it blindly. Get the bugs right. Resolve the issues. Once the code is running and is rendering the given logic then get back to the logic development and enhancement. There is no point shuttling between the code and logic design. Imagine if a General were to do that in a battle: 1. Come up with a Battle Formation. 2. Send the troops in to battle in that formation and the associated orders. 3. "OOOPS!!!" Realise that the Formation and Orders were wrong. 4. Call the troops back, which is half way through the battle. Here we are assuming that a lot of loss has already taken place. 5. Goto step 1, if you have not already lost the battle or if all your soldiers are not already dead. See the issue with the toggle approach if it were employed in a battle. Treat everyday software development as a battle. You are bound to make more profits by making and selling better software than you are making and/or selling right now.