Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Mon, 18 Apr 2011 11:04:15 -0700 Makeovers http://vijaykrishna.posterous.com/makeovers http://vijaykrishna.posterous.com/makeovers Roughly a month ago i was hard at work, against time time and energies to integrate a whole new set of changes in the services with the UI. It was crazy to put it mildly and it was one huge chunk and it was evolving everyday. The whole transition to the new changes took a new 5 days to come to stable grounds. After i was done, i left for a week long break. I knew that the changes would continue, even from where i left off. When i came back however, change was made in virtually every way the application was conceived to begin with. The changes resulted in a drastic makeover and i was in no state to even comprehend the new dynamics of the business that were introduced in the software. I was truly lost. Makeovers are a part of any developmental process. But the big question is if they should be. At least by definition, they should not. A makeover is something that has to come after the development phase is over, instead of being a part of it. In the world of software, where the work and the daily text is  adorning the guises of programming languages, understanding the changes becomes even more difficult. One might argue that this is a common feature of any profession and is not specific or more so in the software world. But i tend to disagree here. Not because i am a part of this Industry of Logic, but because as a proponent of logic i can not help but notice that this industry is still young and is driven by a truly illogical set of rules and frameworks. The code that every one seems to write is more art than clerical form filling. Every one has their styles and hands at coding, like i have discussed this in a previous post. And this being a primary occupation of solving problems, and varied paths may be employed at solving the same problem, the diversity of the work in front of you increases, especially in terms of solutions. So, when you sit down to try and understand what has happened to an existing project, especially one which you worked on, you will find it extremely difficult to comprehend or rather accept new ideas and the general change that has come about in the system. In most software development that i have seen taking place around me, the makeovers are in the form of incremental changes taking place over an extended period of time. True makeovers i think should be a total change of any system ground up. This is a true harbinger of complexity in any system. Such makeovers only complicate the whole process of getting acquainted with new systems. i do not claim that what i have seen or heard of is the general nature of makeovers in any field or profession. But makeovers should, in my opinion, be implemented when one attempts to make something simpler, faster and lighter. This implies a rewriting of the script which may result in an initial failure of the system with its new face. Nonetheless, it should not be avoided. The price of getting better at something is imminent failure, but often that is also its reason in the first place.

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
Thu, 03 Feb 2011 18:16:07 -0800 A Coder's Handwriting http://vijaykrishna.posterous.com/a-coders-handwriting http://vijaykrishna.posterous.com/a-coders-handwriting This is a phrase coined by i-don't-know-who. But this is a phrase used my a colleague of mine at office. When ever there is any issue in the code on the TFS, instead of doing a history check and the past check-ins, this guys identifies the author of that code based on its "handwriting". Interestingly enough more often than not, he is correct. And surprisingly enough, when you think about it for a minute, there seems to be some sense in his method. Any coder, no mater how much he has coded, or whom he codes with, has a basic style of coding. It may change over time. That is because a lot of factors effect how one writes code. The kind of software one uses to write code. The sort of framework/technology/language someone is working with or how much they know about it, the kind of practices one uses while coding, which involve, comments, regions, proper grouping of a particular kind of data variables and methods and the names used for those. Its a sum total of everything. And that is what i think my colleague means. Now every one has their own hand in coding and it keeps changing from time to time, more in the early days of work. But, as you go on, it stabilizes. Or so i guess. You can teach a coder how to use comments, and how to put everything in regions and how to make sure that he uses the same naming conventions everywhere. But there are so many things out there, (hell...even the kinds and number of commenting styles can overwhelm you at times) that it is only human for a coder to pick up a subset of all those standards and notations. Mind you, not all those standards are the best for any and every kind of scenario. But, those such as using comments to write the steps in your code, or place the methods in the probable sequence in which they will be called, or using access modifiers whether required or not, really help in the process of coding well. Many will beg to differ with me at this point, and i do not blame them. For i, myself believe that logic is the most important thing for a coder and everything else comes later. But, having such habits is not a bad thing really. Having comments is good for your own logic building. You really do not have to keep looking at the code and deciphering it, in order to understand what you have done. If you were to write the steps of your logic in comments, then the next time you open your code, you can just pick up from where you left, without dwelling into the code too much. This way you are not wasting time in revising on old stuff but actually moving on to new logic or logic enhancements. And it also makes it easier for someone who has to give you ideas/suggestions/reviews for your code. He can then actually understand what you have written. What is the point of writing good logic with poorly understandable code? Its like writing a new idea on paper with a doctor's handwriting. No one will understand your idea. Not because it was a complex idea, but because your handwriting sucked and your words were difficult to read. Writing neat code also conveys a clarity of thought. I think the reverse psychology also works here. What i mean is that a good coder with a clear mind will in all probability write clean code with proper naming conventions. Similarly, if you were to force yourself to use clear naming conventions you actually begin to have a clear understanding your own code. And that is the first step to good coding with sound logic development. Still not convinced? Look at it this way: You write code for your understanding, not the computer's. The computer will always convert your code to its own language which happens to be the binary, something you cannot not understand anyway. So whom are you writing that code for in a high level language, if not for yourself and your understanding?

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, 11 Jan 2011 16:45:09 -0800 My Final Year Project Problem Brief http://vijaykrishna.posterous.com/my-final-year-project-problem-brief http://vijaykrishna.posterous.com/my-final-year-project-problem-brief This is a snippet of my Final year Project's Problem Brief. It was an adventurous project, had loads of fun doing it. BTW, the next tutorial on Silverlight is coming up soon, so stick around. In this project we are trying to address the problems of Comprehension and Reduction of Java Code. While writing programs a programmer looses track of the flow of the code and at times even the logic of the program that he is writing. This is a very common problem for many coders, especially when they are writing lengthy programs. Such situations quite often result in the coder writing code which is never reached during execution. This is because he does not have a clear picture of the program flow. As a result many programmers have to put in an additional effort to keep track of the flow and logic of the program. This diverts the programmer’s attention from his actual task, which is solving the problem at hand by using programming as a medium or tool. So we find that programming, which was intended to help the process of problem solving, has actually become its biggest hurdle. Thus, it becomes important to show the programmer exactly what the program flow is at any given point of time without a great effort from his side. All this finally boils down to the automation of the analysis of the code by a software tool, with which both the flow of the program and possible reductions can be shown to the programmer from time to time.

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