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
Wed, 16 Feb 2011 17:20:52 -0800 SRS: Software Requirement Specifications http://vijaykrishna.posterous.com/srs-software-requirement-specifications http://vijaykrishna.posterous.com/srs-software-requirement-specifications I was finally able to clean up my comp today off all the trash i had accumulated over the years in college. Saved up a lot of space!! :D That is when i found this rather interesting document worth having a look at. It was a simple straight forward guideline to writing an SRS. I used it while documenting my analysis and design aspects of my final year project. It is to the point and comprehensive to say the least. I guess one such document should always be by your side while working on any project. :) I could never quite locate the true source of this document. It was a life saver for me. So here is the link to it: SRS.pdf Hope this helps you in your documentation and analysis of your projects. Cheers!!!

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
Sun, 30 Jan 2011 16:59:35 -0800 Requirements http://vijaykrishna.posterous.com/requirements http://vijaykrishna.posterous.com/requirements Every project is a result of a set of requirements. The success and the failure that project depends upon the extent to which those requirements are satisfied with the project. This is not another piece of literature that will tell you the importance of understanding a client's or consumer's requirements because it is important for the consumer. I am a coder, and i will like to, for a change, try and point out the issues a coder has if the requirements are not clearly defined. To be more explicit, i really do not care about how poor requirement analysis usually effects the consumer, i am more concerned about how it effects the coder, who is expected to transform those requirements to a finished product and machine. My point being, if the coder himself is unclear about the specs., then we have bigger concerns, bigger than the client. Live the consumer's World. - When a requirement analysis is being carried out, there should always be a certain degree of clarity between the one who is conveying the requirements, and the one trying to understand them. In an ideal world, the one who is trying to the understanding should also be able to convey those in their precise element, and also be a part of the coding fraternity. Also, there can never be a situation, when you are apprehensive about asking questions about a particular aspect about the requirements. It is always good to try and understand the purpose of what the client is trying to achieve with the final product. There is no point making assumptions based on what the client has told you. Remember, the client lives in that world, where the requirements exist, you do not. Live that world. Only then will you be able to truly see the intricacies of the problems you will face while actually developing the product, even before you get into the whole whirlpool of development. Avoid the Negative Trickle. - Information, like rations in India, suffers from the trickle down effect. When it starts from the source, it is rich and abundant. But, by the time it comes down to the individual who has to make sense out of it, and use it, there is hardly any left. The reason this is normal  is due to one simple thing: a lack of form in the information that is being generated at the source. Because, it is very abstract, and largely based on the consumer's experiences and not on a well thought off scheme of things, the information needs to be organized. And there is the loss of information begins. In the process of organization, we loose of several key elements, which might not seem important at the inception, but becomes important, as the project grows. We negate those elements, in the early phase of our project and thus, loose them for ever. Many come back to haunt us, many revive quietly. The idea should be to preserve everything. Do not loose any thing, even if it may seem to mean nothing to the project. See reason, not instructions. - In any team, there will always be someone telling someone else what to do. And since not everyone in a development team can meet the client, the "telling" will be more while trying to convey the requirements and hence the goals. In this whole process, one tends to take everything as an order or a blatant instruction, to be performed blindly. This is specifically true to coders. Don't do that. Listen to what your mentor has to say. Try and see the reason in the goals and requirements. What might seem right to you may not be so for the consumer. Adjust your thought accordingly. And until you are clear and confident of the fact that your understanding of the requirements are same as that of the client, don't stop asking questions. But the bigger thing is to always find the right reason behind your goals. Don't develop something blindly. Try looking at the Big Picture. The moment you start taking a holistic view to things, you understand the context of your work, which allows natural synchronization with the team that you are working with. When these things are not followed things get tough for a coder. He has no context for his work. His code is a result of an instruction from his superiors. And more often than not, he has little or no understanding of the requirements and ends up coming out with good code for the wrong 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