A Common Mistake...

Most of us, even Software Engineers do not keep their Personal Computers and Laptops Organized.

A perfect example is the pathetic condition of their desktops. I often see people having a clustered and unorganized desktop. Most don’t realize that more the desktop Icons lesser is the performance. Word Docs, Excel sheets, Images and other installables, are few items that can be seen more often in these clumsy desktop. These docs can be segregated and organized in their own personal folders in side the Hard disk or the “My Documents” folder. For Novice and amateurs “My documents” are very useful.

Installing unwanted and unknown applications lead to leakage of important data and important information. They degrade the system performance very badly. Most prominent are the software downloaded from the P2Ps. Most of the exes are Virus and Trojans. But most of the time we might be able to diagnose it unless it is installed. For example, I badly needed a “Turbo C” compiler recently. I wasn’t able to get it from the internet so I had to download it from “Limewire” P2P software. After I downloaded it, I ended up getting one of the worst Viruses I have seen. It got in all the “Ad wares” possible and my CPU was always full. At last I had to format it.

So please be aware of any kind of exe you download and install.

Most of us don’t really have Anti-Virus software to handle this. If at all we have one, we fail to upgrade the latest virus definitions.

I recently found this web site http://housecall.trendmicro.com/ that does Virus Scanning online. It’s a very time consuming but a very effecting process. This comes for free and is very reliable.

Do check it out.

If at all you don’t remember the URL. Goggle “Micro Trend”. And the first site you get it this.

Hope it is useful to you.

Hilarious...

The one below is a very hilarious Comedy I have ever admired. Anytime you see it, you will laugh like crazy. If you can understand Tamil it would be even more fun. Anyways you will have subtitle. Hope you enjoy.

My Comments On Their mail.

Note: Please read the earlier blogs for better understaning

Yes, as Ari said cost is an important factor, considering the fact that the development time of the project is less than six months, like most projects in SME. And it does not make sense having a technical writer for an Iterative model where customer customizes the product as and when it is being developed. And it's needless for the company to worry about having a technical or a functional document. But the client should be smart enough to ask for some kind of technical document, once the project is over. A developer can do this and he is a best person because, there are very few developers in such a project and he knows it better. And document writing should be the last thing that you can do.

If I remember it correctly Kalai was handling a Mobile project along with the other dude (his name was barbarian in CS). The project was initially developed in some language and they wanted to convert it into a different language (or some shit like that). I remember they were struggling to understand the source code for a very long time. A document at this point would have made the job lot simpler by greatly reducing the analysis time and would eventually increase the productivity.

Let us consider bigger projects like EF and Thomson. The development phase for these projects usually takes almost a year and the maintenance will runs for decades. In such cases a huge amount of money is being on the development. So the cost factor should not be an issue. These projects cannot use iterative Model. You cannot customize it during the development stage; doing so is a potential problem to code and the development of the project. Usually waterfall model is chosen, not because it will ensure success of the project but to ensure it does not fail.

So for bigger accounts it is dangerous to iterate or change the functional spec during the development stage. This is where processes, design patterns and frameworks come into play. This is done during the System analysis phase, an important phase in the software development life cycle. Functional specification, High level design and low level design documents are first charted out before starting the development phase. For example a good SRS will spec out, the Data flow, a class diagram, its methods, its parameters and even the minute iota like local variables, which make the development a lot easier.

So ideally a technical writer has to do these documents coordinating with the project lead and other technical leads. A developer is not the right person to do it. The only documentation that a developer should do is to writing clear, simple and grammatically error free comments in between the codes. Good commenting practice will technically solve whole load of shit. So the bottom line is to, write clean, readable code in such a way that it doesn't need any comments to understand. Nicer the code lesser the comments.

So cost is not an issue for bigger projects. So it's the companies that should decide the need for the technical writers depending on the type of the project and the type of the development technique they implement.

Ari and Shivan: Batman and Robin

Statuary Warning: If you reading this Article for the first time. Please read the earlier one for better understanding.

I badly needed comments or suggestions for my earlier Blog before I could really stick in on my blog.

Ari and Shivan pounced on it almost immediately with a lot of suggestions. I find it worth pasting mentioning it here. Thanks a lot :-)

Ari's Comments :

Before i fondle on the importance of accommodative & shape shifting process, i think you have way too much time. which is good.

All SME's have a cost factor which affects the business application therefore ignoring the acceptance of a process. But hey times are changing, the larger the organization the tougher it becomes to foresee the implications of change - which is why you have shape-shifting SDLCs.

A not-so-perfect analogy of SDLC's would be circuit designing, they share a common base but are totally parallel to any work which takes place. Usually being intangible.

The law of 80:20 is so universal that we adapt our perspectives in viewing the systems around us.

If you ask me what is terribly important is the paper requirement gathering stage of the project . you see the BA's are supposed to nail the requirement after devising a solution that has been already discussed and envisaged with the client. for example: if a small functionality of the website has to be built in a stand-alone procedure, the Quality team should interpret the respective necessities of the module and translate them into code guidelines.

Any form of documentation should be automated - providing 100 unemployed technical document writers - those profiles shouldn't exist any more, for am sure documentation procedure can be obtained in various report methods - dude IBM are in process of automating the complete SDLC and we are hatching eggs here!!!

I believe the complexity always lies in the decision of frame work one chooses and leverages it with the amount of time they spend on editing / altering / tailoring.

Shivan's Comment:

Naveen, I understand where you are coming from and where your are going (metamorphically speaking). See, the fact is that SDLC's do exist and they are implemented by one and all knowingly or unknowingly. The question is how effectively it has been implemented. There is no point planning unless you strategize it's execution (I hope the choice and order of words are correct). So what you are asking for (the ideal situation) is Utopian. It exists theoretically but poorly implemented. But the very reason we (India Inc) is getting more and more business is because the client is 60% satisfied (I believe so).

Now, the next question is how to ensure we formalize this SDLC in actual implementation. Sure, every company has all the formal processes in place to do that crap, but as you said the actual implementation is poor to average. I believe it exists at the individual level. I firmly believe we, as individuals, must take more responsibility to do this. Yeah,Yeah, we are supposed to do this and blah blah blah but, it is not done. This leads us to the next question, moral responsibility. I also firmly believe there must be some commitment level to the work we do. If even this commitment is not there then we better jack off at home than disrespect work (I would like to boast that i have high moral values). You can claim that strict enforcement will also achieve this aim but if a person was inclined to do this then that would not be necessary at all. But since not many are inclined companies enforce this and unfortunately everyone sees it as added burden and it gets weighed down in priority and is eventually sunk to the bottom which brings us to the first point - "where the fuck is my document?" "I am sorry sir, but it is not my headache. It should have been done by some other bastard. I am getting paid to fucking code" (This would be a hilarious conversation")

I would like to modify the old saying (Charity starts at home) - Documentation starts at the individual level (I am buried under the assumption that the entire diatribe was on good documentation). I hope this was useful.

The following conversation has no relevance to the above at all but is very funny:

When England toured Australia in the infamous Bodyline series, an Australian apparently called England's captain, Douglas Jardine, a bastard to which he went and complained to Australia's captain, Jack Fingleton. Jack is believed to have asked the following in Australia's dressing room - "Which one of you bastards called that bastard a bastard?"

Ari's Comments:

When shit hits the fan, it spreads. Under the ivory tower of SDLC lies cost of implementation. the reason why India Inc is currently making the world happy is due it the cost of execution. With lower responsibility comes lower liability, and thats exactly where we stand. lets take TCS for instance, despite it being a CMMi5 level company, their process doesn't resolve problems, yet it lessens the risks for the client as well as the implementers.

A typical Indian Software Industry - A Novice view

Free lancing!!! I have done a quite a few free lancing not for money but for experiment and want to know kind of attitude "why so many software industries including giants fail to make it". So much of money, time and resource harvested are scraped in no time. I know I am amateur and a kid to do a complete market study on why this is happening. But I write this with the little amount of experience I have had in the industry.

SCRAP THE PROJECT. I find many reasoning it, to have chosen a wrong software life cycle model, framework, resource planning and stuff like that. But I personally feel the mistake is in the granular level. Most small/medium sized companies find it lazy enough to have a Quality team (here I am not talking about the testing team rather a team that checks to see if the processes are in place), Technical Document Write and failing to create awareness among the developers about the Code and the coding practice.

In an ideal scenario (waterfall model), the following process is followed

Information and system analysis: Establishing requirements for all system elements and then allocating some subset of these requirements to software. It must consider other elements like hard ware, people, environment (intranet or internet) and other factors. A study is to be made about the existing system and spruce up the process.
Software Requirement analysis: Once the above is done feasibility study is done based on the above. Then the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, and target dates. System engineer ("analyst") must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved.
System Analyst: This phase is usually about the software technology, factors like Client/server, Architecture, Data structure, Framework and Database design is finalized. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase.
Coding (Interesting Phase): Once all the above are frozen. Knowledge transfer is done to the resources and the developers start their work. I don't think mush of the explanation is needed here as most of you must know this.
Testing: A quality testing team does rigorous testing before the end product is finalized. This testing team must be proactive and should be virtually disconnected from the development team. Ideally the development team must not interact with the testing team. Any communication should be routed through the Quality or the project lead.

And this will ensure the success of the project.

The Key word is here is Ideal. But unfortunately the word Ideal has just been in the dictionary right from the day the word was coined.

Ideally a client should know what he wants. Ideally Analysis team should do a right design and architecture. Ideally by now we should have had some SDLC Model that can guarantee success to a project. Ideally when a programmer spews an Ideal Code, where in there should be virtually no bugs in the project. Ideally if Testing team can find all the defects, then Client should be happy by now.

And I am sure most of the above is not happening. So at any point I find it pointless talking about an Ideal scenario.

So what is that we have to do in order to ensure atleast 60% satisfaction if not 100% to the client?

Any Big software giants do this. Yes, Patch work. By patch work I don't mean a patch fix. A patch fix is something that we do after the project is done and patch work is something that we do during the project in order to save the unexpected. Just as the old proverb goes "Prevention is better than cure"

And these patch work is also billed with the customer.

Remember I had already mentioned about 3 important factors in the Granular level. Let's see why and in what way they can contribute to the project.

Quality Team
Documents Writer
Programmers awareness to the Coding Style and Coding techniques

The Quality analyst must ensure that all the processes are in place. A constant code review, documentation and he has to ensure that, there is always a buffer time for the developers to relax towards the end of the project (Not for a picnic or a team outing but for developers to be available for any changes from the testing time towards the end). It's the part of the quality team to remind the developers about the unit test, a constant status update meetings. He has to keep constant check on the documents and the new functionality changes from the Client.

The Complexity lies in development process and its documentation. Alteration of the documentation during maintenance is an important problem for improvement of quality. The documentation to be evaluated is often complex and voluminous. Because of complex relationships between technical data products, planning documentation, test requirement, and different phases of development life cycle elements, this documentation is difficult to evaluate to assure that all activities have been adequately addressed. Documentation provides communication between all groups concerned with development on the one hand, and the control of project process on the other. I found the following lines in one of the websites and I think it's worth mentioning it here. 'Software in the application process must be constantly adapted and altered. The maintenance programmer usually does not have the time alteration to documentation. Often suitable tools are not available either. This causes the quality of documentation to suffer". And I truly subscribe to this.

Most developers (be it a lateral or a fresher) who are newly introduced to the code start experimenting with the code apart from their initial knowledge sharing sessions. Trial and error methods are all about it. Declaring unwanted variables and adding functions that might already exist with a different syntax. Coping a pre-existing code is usually found to be an easy alternative of creating a new page. But out of my experience, I have found it is more time consuming and is prone to bugs in the later stage. This is usually because most of us fail to alter few small keywords that later has a drastic effect. Constant unit testing has to be done after each and ever module. Feedback from the Quality team should be constantly monitored and reviewed. Most companies do code review but this practice slowly fades away towards the dead line. The 80-20 rule applies here. 80% of the issues come from 20% of the code.

Before I complete this note, I would like to mention that these are just the missing patch work that can be done in order to move one step towards the success of the project.

Again if all the above can ideally happen then the project can be a success.