W@rfi Blog

Have you ever wondered what is company loyalty ? Is there something like that or its just for exploitation or something else ? Lets look it other way round. For instance, you are loyal to company and in turn your employer, is your employer in return loyal to you as well ? If you say yes, I doubt it

Having said that, is it required to love your company or your work ? If you just love to work for your company and not your job, you are not fulfilling your duties. Top priority should always be your job and work not the company.

When company will do good business, employer will happily say its your company and when its the other way round, the same employer would say this is my company and I have to take some hard decisions Is n’t it ?

Read more…

admin Management Bottom Line, Company Loyalty, Essential Family, Good Business, Hard Decisions, Hating Your Job, Love, Priorities, Right Decision, Right Time, Top Priority

When I joined my first job, I have never thought will I leave this organization or not? As per circumstances I remained for a while with the employer despite of quite much post WTC financial crisis with the company. Anyways, I left when company asked me to

As my career moved onwards, I switched some companies due to many factors like:

• Having absolutely no structure or hierarchy. Funny part is that most of the companies top management call themselves a matrix organization which by no means fulfills the definition. Just calling itself a matrix organization does not serve any purpose
• Lack of communication or you can say haphazard mode of communication.
• Having lots of managers everyone seems to be manager and you never know who you are ?
• Very little or no appreciation at all. Delivering is your responsibilities but you do a lot going out of your boundaries to deliver but having no credit definitely hurts.
• Bad apples, yes the bad apples who are spoiling the culture and always trying to make things worst for people they don’t favor.
• Last but not the least if you (an employee) have got no social life for longer period of time, ultimately employee will leave with frustration. Working on offshore does not mean you are not human.

Read more…

admin Management Bad Apples, Career, Circumstances, Financial Crisis, Funny Part, Gallup, Google, Hierarchy, Knowledge, Lack Of Communication, Matrix Organization, People

Productivity is one of the phenomenon talked about much, practiced and yet there is a lot for improvement. Organizations/groups complaining less productivity know that organizations with higher productivity doesn’t use very advanced technologies.

Their better performance can be explained entirely by their more effective ways of handling people, modifying the workplace and corporate culture. All the measures to increase efficiency or productivity account for measures that take longer time periods to be effective which becomes discouraging for organizations. Every organization wants some miracle to happen that some consultant comes and turn over everything but of course it did not happen that reminds me of the phrase “Easy non-solutions are often more attractive than hard solutions”.

Some of the false hopes include:

• Some managers are getting more than hundred percent gains or more! Forget it. The typical magical tool is focused on the coding and testing part of the life cycle. But even if coding and testing went away entirely, you couldn’t expect a gain of one hundred percent J There is still all the analysis, negotiation, specification, training, acceptance testing, conversion, and cutover to be done.
• Changing languages will give you huge gains. Languages are important because they affect the way you think about a problem, but again, they can have impact only on the implementation part of the project. Sure, it may be better to do a new application in PowerBuilder™, for example, but even before PowerBuilder, there were better ways. Unless you’ve been asleep at the switch for the past few decades, change of a language won’t do much for you.
• You automate everything else; isn’t it about time you automated away your software development staff? This is another variation of the high-tech illusion, the belief that software developers do easily automatable work. Their principal work is human communication to organize the users’ expressions of needs into formal procedure. That work will be necessary no matter how we change the life cycle. And it’s not likely to be automated.
• Your people will work better if you put them under a lot of pressure. They won’t—they’ll just enjoy it less. So far, all this is rather negative. If leaning on people is counterproductive, and installing the latest technological doodad won’t help much either, then what is the manager supposed to do? This Is Management

Let me quote Sharon Weinberg as an example for Managers as quoted by one of the developers:

“In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sickbed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup.

After she’d poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, Tom, this is management.”

Sharon knew what all good instinctive managers know: The manager’s function is not to make people work, but to make it possible for people to work.

admin Management Corporate Culture, Cutover, Development Staff, False Hopes, Human Communication, Illusion, Increase Productivity, Life Cycle, Magical Tool, Miracle, Negotiation, Powerbuilder, Software Developers, Software Development

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

Parkinson’s law states: “work expands to fill the time allocated for it”. Offshore software industry more or less follows parkinson’s law.  Parkinson’s law is seen like Newton’s law or as true as Newton’s law are. Newton was a scientist and he proved every law with research and verification and those laws late were also proved after two hundred years of study.

On the contrary Parkinson was not a scientist rather he was a humorist. He has collected no data and did not even understand the rules of statistical inference. Yet his saying later adopted by approximately all off-shore anagers as a law. His law becomes popular as it was funny Funny enough, managers after putting un-achievable deadlines  and getting lowest quality work completed. They think themselves to be the most successful managers

Every manager in his/her life has to deal with worker who avoids work, or who seems to ahve no starndard of quality or someone who cannot get the job done. Is n’t it Parkinson’s law? In a healthy environment, the reasons mentioned above in a person is due to lack of confidenct, lack of competence or lack of affiliation with the project and its goals. In none of the reasons it will be feasible or practical or wise to assert schedule pressue. When a worker is unable to perform work, it shows the worker is overwhelmed by difficulty of work and he needs to be re-alligned or re-assigned.

Statistical Data

Now let’s see at some data collected at University of New South Wales for this purpose. A couple of researchers at university perform research on live projects each year. They figured out productivity effect is more or developers work harder if they are trying to meet their own estimates. The guys performed research on more than 103 projects. Lets look at the following table:

Lets first forget about the estimate given by system analyst. The highest productivity occurs when programmer does estimate himself/herself. But what happens when system analyst does the estimate. Why developers work harder to make system analyst’s estimates a success. If we believe as we do that bad estimates are always a demotivating factor, then this data doesn’t need explaining away at all. The systems analyst tends to be a better estimator than either the programmer or the supervisor.

Most surprising part comes from the next research done, let’s see the table below:

Projects on which the there was no schedule pressure out performed in productivity. Of course, none of this proves that Parkinson’s Law doesn’t apply to development workers. But doesn’t it make you surprise?

The decision to assert schedule pressure to a project needs to be made in much the same way you decide whether or not to punish your child. If your timing is flawless so the justification is easily apparent, then it can help.

Data taken from Dorse House – People ware

admin Management Healthy Environment, Off Shore, Offshore Software, Parkinson, parkinson law, Productivity Effect, Quality Work, Software Industry, Successful Managers, System Analyst

All of you had definitely heard of a buzzword “Agile”. The mostly used words whenever some geeks discussing the development approaches, processes, management style blah blah blah. You will hear these terms Agile development, Agile design, Agile modeling, Agile testing, Agile project management, Agile roll out planning, Agile decision making, Agile Scrum, Agile languages, Agile database, Agile programming, Agile assembly, Agile game development, Agile thinking, Agile usability, Agile IT… You must be “Agile overload” now

I have all my sympathies with this word as its been used wrongly most often. Normally its being used to defend when someone is trying to hide his mistakes of violating company’s policies or processes etc. When I finally digged into real details for Agile after hearing a lot of differentiating opinions, I thought to share it with all of you as well.

Manifesto

First of all we should know who started thinking about Agile and what were the principles upon which its foundation had been built. In 2001 seventeen software anarchists met to agree upon the following principles that was later recognized as agile. These values are phrased as preferences for one aspect of software development over another:

• Individuals and interactions over process and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

For complete details, refer to this web page http://www.ibm.com/developerworks/rational/library/mar07/pollice/index.html.

Is my project Agile?

After taking a look at manifesto, still what project should be regarded as Agile or non-Agile? Secondly, may we designate some part of a project as Agile and the rest as non-Agile? Does implementing continuous integration and unit test automation makes my project Agile? There are a lot of questions. I think we may come up with something like:

• You have frequent releases and deliverable.
• You welcome and manage change requests.
• Larger projects changing into smaller applications is also a possibility you need to provide for.
• You work closely with the client and/or business experts to provide a real business solution.
• There are no fixed bids.
• You wanted to be flexible and your client also wants the same.

May be you can add a couple of more items to the above list. The point is to know for yourself do you wanted to go for Agile and then really go for it. Remember one thing always “its not about Agile, its about success” as says Gary Pollice.

Drawbacks

Know for yourself what are the drawbacks or using Agile or let me re-phrase, when Agile should not be used:

• Do not use Agile if your team size is more than 80 and increasing.
• Do not go for Agile if the management style is not Agile. If the management is bureaucratic and you wanted Agile, you will definitely be pissed off.
• People are inflexible and/or unable to react to change, using agile will be too hard for them to follow.
• Stakeholders are unwilling to be involved actively. They like to invest time to make decisions.

At the end, before taking any decision do learn about it. Read this story about 6 blind men and an elephant, if you have not already read. As you take a decision think twice about this story to reach towards a good conclusion

admin Agile, Management Agile Assembly, Agile Design, Agile Development, Agile Programming, Agile Project Management, Agile Scrum, Anarchists, Blah Blah, Buzzword, Change Requests, continuous integration, Contract Negotiation, Customer Collaboration, Development Approaches, Frequent Releases, Game Development, Management Style, Test Automation, Unit Test, Working Software

I have always wondered why producing an error is sometimes OR often treated as a sin. One of the major reason is the illusion that software development is somewhat similar to production. On the basis of this illusion, it is considered that:

• Errors can be eliminated.
• Humans can be treated as interchangeable parts.
• Processes can be followed blindly

The above and a lot more illusions can be associated within a production environment but not within development environment. For a thinking worker, making an occasional mistake is natural and healthy as well. But an error on job should be discriminated from a sin. One very clear definition says that errors can be recovered but a sin is not reversible. So if something is reversible that should not be considererd a sin.

For instance, if a product is designed and somehow design changes are required such that the older design need to be thrown away. Management tend to be very strict about it but it needs to understand that it is part of the design activity and that is what design phase is all about. Managers feel this would pose an impossible  political problem for them. They seem to believe that they’d be better off using the same defective version even though it might cost more in the long run. Prevailing an environment that does not allow for error simply makes people defensive. They stop doing any experimentation and looking for new horizons. It happens usually when strict methodologies are imposed. Rather the people should be encouraged to make some errors by asking them what dead end roads they have been throw in their career. Think if any of your people says they have not produced any errors, it will make you feel the opponenet is either a dumb or making you a fool. All those dead end roads make up your experience after all.

Managers need to understand that they can kick the asses to make people active but not to make them creative. Creativity is required in every job that requires head rather than hand. Managers tend to adopt an attitude that everyone is replaceable. Using this mentality, it seems like manager may place an order in store like: “Send me a new Grady but make him less arrogant”.

admin Management Creativity, Defective Version, Design Changes, Design Phase, Development Environment, Job, Methodologies, New Horizons, Occasional Mistake, People, Production Environment, Sin, Software Development

Belonging to software industry, you must have faced times some project failing you were a part of. Have you ever thought, why a software project fails? You will think there could be unlimited scenarios. Yes, you are right there are unlimited scenarios but just handful of advices.

See there had been thousands of ERP projects finished since someone started working on them but still today some ERP project will be failing somewhere. Imagine, some project requiring no technical invention is still failing. By this we can think more often technology is not a barrier to project failure but the culprit is somewhere else.

According to a survey conducted by Tom and Timothy, 15% of smaller projects around 5-10 man years and 25% of bigger projects 15-25 man years failed. The real name of game is “Politics”, yes the filthy thing absorbed into our organizations that don’t let people do work and spoil them as well.

Under “politics” I would put things as communication problems, staffing problems, disenchantment with the boss or with the client, lack of motivation, and high turnover. If you see a problem as political in nature, you tend to be fatalistic about it. You are confident you can stand up to technical challenges, but honestly, who among us can feel confident in the realm of politics? Only a technical politician that can cause real problems   Always look around for them and beware

Sociology is something that seem outside of our field of expertise but its not beyond our capabilities.  Whatever we name these people-related problems, they may cause issue in our next project or task that we should be capable to handle it.

Most Managers know for themselves that they’ve got more people worries than technical worries. But you will seldom see they manage that way. They manage as technology is the prime concern. They spend their most of the time resolve puzzles that they people have to solve, as they themselves have to do the work rather than managing it. Moreover, they are always looking for some magic that can automate most of their work. The most strongly people-oriented aspects are often given the lowest priority.

This is due to the fault in our the upbringing of the average manager. S/he is educated on how the job is done, not how the job is managed. They’ve got very little management experience and no meaningful practice. So how do new managers succeed in convincing themselves that they can safely spend most of their time thinking technology and no time to think about people related issues.

admin Management Boss, Capabilities, Communication Problems, Culprit, Handful, Invention, Lack Of Motivation, Politician, Prime Concern, Puzzles, Resolve, Scenarios, Sociology, Software Industry, Software Project, Technical Challenges, Turnover, Worries