W@rfi Blog

Yeah, this post is all about as the title says Late sittings are the only truth about offshore software development houses. While I was working on offshore projects, I thought this happens more often due to the fact we are working in a different time zone than the onshore site. That’s why we had to sit late.

That assumption gone to the recycle bin as soon as I got a chance to work on a local project. Where we had got no zone differences. All communications were made during the day. But still we had to sit late till mid night or more to complete our tasks. I started realizing that all this is happens due to some customs developed within developers. And especially the company culture. The obvious reasons are:

• Bachelors usually try to sit late as they had got nothing to do at home. They actually promote a very bad culture within the company and create problems for others.
• Poor planning and very tight deadlines.
• Management wanted to see their team going home late to prove they are pissing off resources well to make their bosses happy.
• Managers wanna show they had completed the project in very little man hours. In fact if they calculate the hours, it would be double the effort they are actually showing in.

The list is very long but to show what I mean the above are enough. At the end, I would like to give a message to managers:

“Try to understand the difference between staying late and working late and try to encourage the employees put in effective hours rather than more hours ”

admin Management Assumption, Bachelors, Company Culture, Customs, Developers, Different Time Zone, Late Night, Local Project, Man Hours, Offshore Development, Offshore Projects, Offshore Software Development, Software Development Houses, Tight Deadlines

Have you ever wondered or even thought about that how many defects are being produced by requirements? If your answer is no, then read on, you should read even if your answer is yes

Here we go, more than two third defects are produced just because of requirements. Developer produced errors account for a small fraction only. But we tend to put more efforts on coding instead of requirements.

As a reference, do read this journal article:
http://www.springerlink.com/content/m9404w6639063h7g/

For managers, see what is the value of poor requirements analysis with respect to cost (managers would definitely be attracted when shown something associated with cost
Requirements analysis on basis of ROI

As per Fred Brookes:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part of the system is more difficult to rectify later.”

Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”, IEEE Computer, Vol. 20, No. 4, April 1987, p. 10-19.

Coming back to our point, who should take the action ? Of course the decision makers who decide how much time to put on requirements analysis & what methodologies to adopt for requirements gathering, analysis and management. If managment itself does not know the importance of requirements and its impact, then how the choas created by the end of the project will be overcomed.

As a first step, we need to know ourselves what impact requirements have on projects. There’s a wealth of historical information that proves that projects started without written requirements are doomed to fail. As Jones said:

“A significant and important aspect of requirements errors is that if they are not prevented or removed, they tend to flow downstream into design, code, and user manuals. Historically, errors which originate in requirements tend to be the most expensive and troublesome to eliminate later.”

Jones, C., Software Quality: Analysis and Guidelines for Success, International Thomson Computer Press, 1997

The next step is to get Management to understand the importance of requirements and to require that requirements are a mandatory part of your development process, a step that can’t be skipped no matter how intense the pressure is. Management commitment to having well-written requirements is essential.

The most neglected part is our lack to learn from our past mistakes. We do not do post mortem of past projects to learn from them and not to repeat the same mistakes. Offshore companies are always eager  to find short cuts to reduce time and in turn cost. The first approach they adopt is to spend as little time on requirement gathering, analysis and management as possible that in turn produces problems by the end of the project.

To conclude, getting the requirements right is the key to getting the software right. With poorly written, incomplete, and ambiguous requirements, it’s difficult  for software guys to know what to build & for QA guys to know what to test.

admin Management Conceptual Work, Cripples, Decision Makers, Historical Information, Impact Requirements, Methodologies, requirements, requirements analysis, Requirements Management, Software Engineering, Software System, Software Systems