Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Sun, 20 Mar 2011 04:53:38 -0700 Ready Made v Ground Up http://vijaykrishna.posterous.com/ready-made-v-ground-up http://vijaykrishna.posterous.com/ready-made-v-ground-up Now this is a debate ragging in my head for quite some time now. I just completed a project for my college's website. The website was built using Drupal. We are now looking for a fully functional website for the college alumni. And there again, we are looking at Ning as a platform. Drupal wass used by a group of students to build a website. They did not have the time to build the whole thing from scratch. Why? Because they were busy with their projects and assignments. When it came to working professionals building a similar website, time became even more of a luxury than before and we moved towards a more ready made platform. And in all this i am not even talking about the time spent in developing the product. But like all software pros, i am talking about the time spent in testing it, making it bullet proof and then maintaining it. Now, this entails a lot of time. When you come to think of it, if and when someone starts paying you for something like this, it becomes a full time job. But then again, that is a big "if". At the same time, while working as a software pro, i realise the power that custom built software has. The flexibility that it has to offer is too much. You can change anything to anything. It gives you the power to do what ever it is that you want to with a website. Having said that, it requires time. Time which we do not have. So, have we finally come to a point where we are ready to be dependent on someone else all-together for our software solutions? I doubt it. We are still pretty much the same when it comes to wanting something: when and if we want it, we get it. So this is the real challenge in front of us today. We are at a point where we do not have the time to achieve the world, and we are also not ready to settle for anything less than that. And this is the most fundamental challenge we will face in the coming years and this issue or problem or what ever it maybe, will only compound and we have the information growth rate to thank for that. Software solutions from now on can not be addressing specific problems anymore. What does that mean? It means that we cannot restrict ourselves to a set of demands or requirements. While the work domain by itself may hardly change, the dynamics and needs will, and beyond changing, they will grow! This is where i have to divert a little and point out that the very purpose of requirement analysis from now on is not understand the requirements of the business that we are going to serve as software engineers, rather it is to preempt for ourselves, so that we can avoid changing the systems and code (which we provide as products), as far as possible. This brings me to another point about custom made software. You do not want to change it too much. It is true. When you write a piece of code, you do not want to keep modifying it too much. You would rather get it right the first time and be done with it. So in a very basic sense, the very purpose of the custom code is defeated. After all, what is the whole point of have custom software when you cannot, or would not like to bring in any change in it? So i guess all you need is to tweak existing systems. That suffices it seems. So there in lies the trick and the solution. I think there is not point writing software anymore. It is time to start writing meta software. Makes sense?

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
Mon, 07 Mar 2011 18:24:48 -0800 You cannot please everyone http://vijaykrishna.posterous.com/you-cannot-please-everyone http://vijaykrishna.posterous.com/you-cannot-please-everyone I was taught this lesson in my 1st year of engineering when i was working on my college magazine, Srijna. It was a simple idea and thought. Beyond anything else, it was a warning. The fact that you cannot please everyone is well ingrained in my head. I understand it better than most people. "Why?", you ask. Simply because, i fail at it over and over and over again. I find the whole notion challenging. Over the years i have witnessed it in many projects and activities in which i have been involved in. The world of professional software development is no different. I am not talking about my work at office. I am talking about Project Doughnut, the founding website team of my undergrad college. Today, after its soft launch nearly 2 and half weeks ago, the website was thrown into the deep waters of an online public forum. This was the kind of publicity we (the team and i) were and were not looking for. But then again, there was the feedback, which we took with intent ears and minds. Paid good attention to most of what people had to say. And that is where i realised that i had yet again set out on a road to keep every one happy, this is otherwise called User Acceptance Testing in the world of software development. The biggest issue with UAT, i personally think, is the U. Sorry to be so candid, but the User does not really understand what exactly he wants. It would be so much better if the Users could really bend their back, focus a little and think a little about what they really want, and compare it with what is already there. But if that were really possible, then requirement analysis would not really be a matter of concern now would it. I find that users have a lot of objective opinions, such as, "You know, this is not right." or, "There is something missing." and, "This should could have been better.", and so on. But very few really dwell into the details and explain why a certain thing could have been better in a given manner or what and why something is missing. All of this calls for some thorough analysis on the background of the user. Why? Simply because you have to enter the users brain and figure out what he thinks is wrong with something but does not want to say it aloud or is simply oblivious to the true reason. A good understanding of the user is recommended while carrying out any kind of UAT and/or requirement analysis. This not only explains the reasons behind the user reported feedback, but also enables you to asist the user better in understanding his own demands and requirements. Try asking the right kind of questions as a part of such an exercise. There is a good chance that the user might come out with a few extra details about the features he would like if you probed him a little about it. This forces the user to think, thus reducing some of your own mental burden. Help him, help you. But then again, you should know how to ask the right questions. Remember, its like working with a computer. If you do not ask the right questions or give the right commands, you will never get the desired results. Never be impatient about the responses people come out with. No matter how shallow they (the responses) are. And never miss out on a single word. Try and imbibe all of what the user has to say. Remember it might not make complete sense to him, but you can churn out a few meaningful ideas which not only apply to that one particular user, but a a more general and larger set. You make a good product not for your own satisfaction, but for the users. And you can never make a good product, if you are not a good user.

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, 17 Feb 2011 17:37:25 -0800 Code Integration http://vijaykrishna.posterous.com/code-integration http://vijaykrishna.posterous.com/code-integration It has been a week of thorough introspection and rough hours at work. With ever changing requirements and demands of the software world and its clients, i guess any developer goes through this phase early in his career. The phase where he not only has to produce good code but also keep changing it as per those requirements, and fast!! And all the while, you have to produce bug free code. So what is the secret? How do you keep writing good error free code, with the fast paced changes? Well, let me break the bad news to you: No one can write bug free code in its entirety with significant changes in the software model/requirements being made every other day. But here is the good news: You can reduce the number of bugs by being careful about the changes that you incorporate in your software/code. And this whole process of being careful is called Integration testing. For those of you who treated STQA (Software Testing and Quality Assurance) with little or no respect during your engineering/undergrad days, bear this in mind: You will regret it, for that is the final barometer of a good coder. So, if you did not pay enough attention to that aspect of development, you still have the time. And yes, it is an integral part of code development itself. While many may feel that it is the job of the testers to actually test out code, i fundamentally disagree. Until and unless every form of testing, which the testers do at a more sophisticated level, starts at the developers' desks at a very basic and rudimentary level, you can never produce good software. Never! Don't testers have to learn programming languages, in the basics, to start testing the code? Then why can't developers get some basic levels of testing done at their own end? And it really does not have to be a very daunting task. Here are two very basic guidelines anyone can use to get that basic testing done right from the very beginning: Assuming you are a decent coder, most of the mistakes you will make is while integrating features or different code modules with your software. Take care when you do this. Remember integration of code is not a mathematical addition of the number of lines of code in both modules. Rather, it is the multiplication, or the product of the number ways the data streams going in and out of both these modules will start to interact with each other. How these data paths join together gives rise to new scenarios, which you would not have considered before. Try finding those scenarios. There is always something new. And that is where most bugs reside. It is easy to work in a localized context and develop small modules of code. The idea should always be to think of how, what you code will, effect the over all scheme of things. The other equally important way to counter unforeseen issues in such integrations is to write decoupled code as far as possible. Thus, in its pure essence, a lot of trouble can be averted, if one were to write independently functional code, to begin with. There should be a middle ground (fragments of transformers) where the mappings or collaborations between these sets of independent modules of code should be performed. This also localizes the errors as well. If the modules by themselves are working well, (and this can be unit stress tested), then all you really need to look at as a developer/tester is how the transformer code is really doing. Thinking of your code structure in this way will also give you some ideas about how software should be designed. These are two very radical approaches, one which relies on the fundamentals of testing, while the other relies on the foundations of designing principles. While most coders i find crib about not being able to be a part of the designing process, i wonder how many of them design their own small modules of code, in the best manner possible. Coding is least about writing lines of text in a particular computer language which generates fancy outputs. It is about writing good logic, in a readable manner, which can be well managed thus resulting in easy verifications. I think that every piece of code deserves all of these elements to their core. No Exceptions!!

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