Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Tue, 05 Apr 2011 06:46:48 -0700 Coding (vs) Logic 1 http://vijaykrishna.posterous.com/coding-vs-logic-1 http://vijaykrishna.posterous.com/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.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Tue, 08 Mar 2011 17:15:58 -0800 More Options to the User - Elements of Interface Design http://vijaykrishna.posterous.com/more-options-to-the-user-elements-of-interfac http://vijaykrishna.posterous.com/more-options-to-the-user-elements-of-interfac This was really a sub point in my earlier post which dealt with the basics of Interface Designing in general. But then a good friend of mine, who also happens to be a fantastic software test developer, asked me this and so i decided that i should elaborate on the point in a more details manner. Here is the excerpt out of that post which directly deals with this post:
Q. How much of a choice should one provide the user with? A. The answer is optimum. If you give very few choices and options, you are providing the user with a under functioning UI. If you give too many choices then the chances are that the UI is going to turn out to be very cutlery. Something you do not want. But, more than that, there is another peril lurking in the dark. Say you have provided your user with 5 buttons and only 5 chances to hit any button, then there are 5^5 ways in which he can use those buttons. Imagine what will happen in all those cases. Think of how will handle all of them and what will happen if one were to increase that number even by 1. Prioritize your functions just like your data and information. The priority of your information depends on your users, the priority of your buttons depends on your information.
Now, the question that was asked was quite simple: Is it a good idea to reduce the functionality you give to the user to make the application more User Friendly? Well I will have to say that the answer to that question is obviously no. Simply because, more the features the better is the application in terms of its feature set and hence, a happier user. Of course, it goes without saying that by increasing the feature set, you are making your application that much more unstable. You will actually require well written code and logic to substantiate it. So the issue is not really a user experience issue but a coding and software development problem. And many a times there will be situations where you cannot keep simple and straight forward UI's. The business will require you to complicate them. Sometimes, even if a simple alternative were viable with a more optimum number of features and choices, you would still be forced to come up with the same clustered UI simply because the client might be used to it, and may not want to change over to simpler and better things. Hence, at some point or the other there will be times when complicated coding, followed by a sophisticated bout of testing will have to be done. And that is the bad news. Having said that, here is the good news. The choices and features that we give to the user, need not always be interdependent. In case they are, then you have no other alternative but code and test out of your skins. But, if there is a way by which you can keep the interdependencies, at a minimum internally then life will get a lot simpler for you. In case the dependencies cannot be avoided, try minimizing them or concentrating them to a single interfacing point with in the code. For instance, most of such data dependencies can be taken up at two instance, such as the beginning, while the UI is loading, and while the user is exiting that view, i.e. at the end. So, you are creating a single data pathway, through which the data will enter and exit, at which point you will resolve all your dependencies. I will still say that it is best not to give the user too many options no matter much the usability improves, and improve it will. "Why" you ask? Simply because, once you walk down that path things will only keep getting more complicated for the coder, and more enjoyable for the user. And there will come a time when the system will get too unstable to manage and maintain and the user will be in love with such systems due to its usability but will frown when the bugs come crawling out. I have really painted an ugly picture here, by giving a worst case scenario. In most projects as far as possible, systems are made simpler and better than their predecessors. Even the end users are willing to accept new ways of doing things. It is at such moments that we should make the best efforts to simplify things.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu