Thamarai's Blog

• Creates a new order - Maintains existing order
• Defines risks - De-risks
• Opportunity focused - Resource focused
• Comfort in ambiguity - Comfort in clarity
• Opportunity centric - Constraint centric
• Big-picture oriented - Detail oriented
• Innovative - Adaptive

PS : I have red above points from Subroto Bagchi's (COO of Mintree Consulting) presentation

The Mythical Man-Month

Whenever a product's development schedule is slipping badly and there is a crisis meeting of the programming team, the term "mythical man-month" is likely to be bandied about. There will be many sighs and exchanges of knowing looks and pointing of fingers and tasks assigned and subsequent exchanges of memoranda and Highly Significant Position Papers. But it's a safe bet that hardly anyone at the meeting will have actually read "The Mythical Man-Month" by Frederick P. Brooks Jr. or know exactly what it talks about -- the book, and its author, have acquired a certain mythic status of their own.

So what is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?"

Alas, time cannot be warped so easily. Dr. Brooks observed, while he was managing the development of Operating System/360 (OS/360) in the early 1960's, that man-months are not -- so to speak -- factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.
When you stop to think about it, this phenomenon is easy to understand. There is an inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be dedicated to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there will be at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger.

Assigning more programmers to a project running behind schedule will make it even later, due to the time required for the new programmers to learn about the project, and the increased communications overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative (i.e. the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created).

• Group Intercommunication Formula: n(n − 1) / 2
• Example: 50 developers -> 50(50 − 1) / 2 = 1225 units of effort (hour/week/month) spent in communication

The Second-system effect

The second system an engineer designs is the most dangerous system he will ever design, since it will be disastrously overdesigned. Thus, when embarking upon a new project, a project manager should ask for a chief architect who has designed at least two systems.

Progress Tracking

Question: How does a large software project get to be one year late? Answer: One day at a time! Incremental slippages on many fronts eventually accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management.

Conceptual Integrity

In order to make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. A "super cool" idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.

The Manual

What the chief architect produces are written specifications for the system in the form of the manual. It describes the external specifications of the system in detail, i.e., everything that the user sees. The manual can be altered as feedback comes in from the implementation teams and the users.

The Pilot System

When designing a new kind of system, a team will design a throw-away system (whether it intends to or not). This system acts as a pilot plant that will reveal techniques which will subsequently cause a complete redesign of the system. This second smarter system should be the one delivered to the customer, since delivery of the pilot system would cause nothing but agony to the customer, and possibly ruin the system's reputation and maybe even the company's.

Formal Documents

Every project manager must create a small core set of formal documents which acts as the roadmap as to what the project objectives are, how they are to be achieved, who is going to achieve them, when they are going to be achieved, and how much they are going to cost. These documents may also reveal inconsistencies that are otherwise hard to see.

Project Estimation

When estimating project times, it should be remembered that compilers are three times as hard to write as application programs. And systems programs are three times as hard to write as compilers. And the use of a suitable high-level language may dramatically improve programmer productivity. Also, it should be kept in mind how much of the work week will actually be spent on technical issues rather than administrative ones or other non-technical ones, such as meetings or sick leaves.

Communication

In order to avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible (e-mail, phone, meetings, memos etc.) Instead of assuming something, the implementer should instead ask the architects to clarify their intent on a feature he is implementing, before proceeding with an assumption that might very well be completely incorrect.

The Surgical Team

Much as a surgical team during surgery is led by one surgeon performing the most critical work himself while directing his team to assist with or overtake less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Additionally, Brooks muses that "good" programmers are generally 5-10 times as productive as mediocre ones.

Code Freeze and System Versioning

Software is invisible. Therefore, many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system will therefore need to be changed in order to fulfill the changed requirements of the user. This can only occur up to a certain point, otherwise the system may never be completed. At a certain date, no more changes would be allowed to the system and the code would be frozen. All requests for changes will be delayed until the next version of the system.

Specialized Tools

Instead of every programmer having his own special set of tools, each team should have a designated tool-maker that may create tools which are highly customized for the job that team is doing, e.g., a code generator tool that spits out code based on a specification. In addition, system-wide tools should be built by a common tools team, overseen by the project manager.

Lowering Software Development Costs

There are two techniques for lowering software development costs that Brooks writes about :

• Implementers may be hired only after the architecture of the system has been completed (a step that may take several months, during which time prematurely-hired implementers may have nothing to do).
• Another technique Brooks mentions is not to develop software at all, but to simply buy it "off the shelf" when possible.

1. I am not sure what would be the impact on Indian astrology.
2. What will happen to software companies / products that have Pluto as part of their name?
3. Who will be answerable to students who were punished by their physics teacher for not remembering Pluto as planet?

Post me if you have any great ideas on this topic !!!

Here is the simple graph based on porter's competitive strategy. I am doing a research on various indian software service providers and their competitive strategy to win and execute software projects. I will be soon blogging my findings. Meanwhile, here is the saimple JPEG image that depicts porter's competitive strategy ( Created with free mind )

• The bargaining power of customers
  * buyer concentration to firm concentration ratio
  * bargaining leverage
  * buyer volume
  * buyer switching costs relative to firm switching costs
  * buyer information availability
  * ability to backward integrate
  * availability of existing substitute products
  * buyer price sensitivity
  * price of total purchase

• The bargaining power of suppliers
  * supplier switching costs relative to firm switching costs
  * degree of differentiation of inputs
  * presence of substitute inputs
  * supplier concentration to firm concentration ratio
  * threat of forward integration by suppliers relative to the threat of backward integration by firms
  * cost of inputs relative to selling price of the product
  * importance of volume to supplier

• The threat of new entrants
  * the existence of barriers to entry
  * economies of product differences
  * brand equity
  * switching costs
  * capital requirements
  * access to distribution
  * absolute cost advantages
  * learning curve advantages
  * expected retaliation
  * government policies

• The threat of substitute products
  * buyer propensity to substitute
  * relative price performance of substitutes
  * buyer switching costs
  * perceived level of product differentiation

• The intensity of competitive rivalry
  * power of buyers
  * power of suppliers
  * threat of new entrants
  * threat of substitute products
  * number of competitors
  * rate of industry growth
  * industry overcapacity
  * exit barriers
  * diversity of competitors
  * informational complexity and asymmetry
  * brand equity
  * fixed cost allocation per value added
  
  
  Porter's Competitive Strategy

Privatise the Indian Parliament!

Earlier this yaer a television news channel exposed, using hidden cameras, how Indian MPs across several mainstream parties take money to raise questions in Parliament. While the event has evoked a predictable public chorus of ‘shame, shame’ and pious pronouncements on the decline in standards of our politicians all this in my opinion was missing the point completely. These allegedly ‘corrupt’ MPs need to be congratulated not condemned for their behaviour.

Before any of you go ballistic, let me explain why.

First of all, in a Parliament where a significant number of members have criminal records or are closely associated with crime, the act of a few MPs accepting money in a peaceful and non-violent manner is in fact a sign of hope.

It shows that despite the pollution of our national cultural values by foreign channels like Fashion TV even today Gandhi- (the Mahatma, not Sonia)- wields influence on at least some of our leaders. After all the same MPs could have been out somewhere extorting money at the point of a gun from someone. (Would that have been all right for the Aajtak TV fellows with their silly secret cameras? Hmmm!)

Secondly, by agreeing to raise questions in Parliament the honorable MPs demonstrated that there are still some elected representatives left in our country who are willing to work for their money. How many MPs do you know from whom a client, customer or citizen can get any work done or service performed even after paying hard cash?

And also think of it - how much easier it would have been for these MPs, being martyred by the media now, to have taken the money and then paid someone else to raise the questions. Wouldn’t that have been even worse, being outright cheating and complete dereliction of duty?
By taking up direct responsibility for asking the pre-paid questions (the post-paid option is still in the works) in Parliament, the MPs have in fact set a shining example of personalized customer service that puts much of the Indian private sector to shame.

But well beyond demonstrating the power of Gandhian thought and the ancient Indian work ethic what these eleven MPs have done is pioneered a concept that has deep implications for the future of electoral democracies all over the globe. They have taken the first steps towards implementing the amazing idea of Privatizing the Parliament!

Imagine the future! You want a question asked in Parliament-? No problem- you will be able to book your favorite MP over the Internet with the mere swipe of a credit card! (http://www.cashforquestions.com/ or something like that). There will be competition for this market of course so you can look forward to deep discounts from rival MPs who might offer two questions for the price of one. If you don’t have a second question to ask they will have management graduates who can invent them for you. How thoughtful!

Forget about mere questions- you want a law introduced or amended? No problem again-they will introduce, reduce, bend, amend any law you want and have it freely delivered to your doorstep!

If you privatize parliament then what is left of the idea of ‘one man, one vote’ and the very concept of electoral representative democracy? Does it not become ‘one dollar, two votes’ or whatever the conversion rate may be?

Indeed, if money can buy our MPs then why bother to have an elected government at all? Why not do an IPO and sell the damn institution to any multinational, hedge fund or global bank willing to pay the premiums? Why have a Prime Minister and a cabinet full of pompous ministers when you can get a smart, highly paid CEO and a board of directors accountable to none but their shareholders?

And will this mania for privatizing every public body stop with even the parliament or government? Why not privatize the armed forces and the police too- after all these are huge and highly subsidized institutions in every country that violate all the rules of the WTO? And while we are on this privatisation spree why not sell the moon also to a multinational - to convert moonlight into a moneymaking venture?

You know what? All these questions above are not really questions at all but frightening descriptions of where our dear country and the globe are really headed for. Even on a noisy day I can hear the future wheezing and sputtering with her privatized lungs.

(This is extact of article written by Mr. Satya Sagar, CPIL)