Tuesday, November 16, 2004

Currently Reading



Sunday, November 14, 2004

The Great Arc

1600 miles, 50 years started circa 1800, no fewer than 700 men, few tons of equipment, Lethal Climate - Insects, Dense jungles, Malaria, Typhus fever, Tigers, Snakes etc.

Colonel William Lambton, Superintendent of the great Trignometrical Survey of India and later his successor Lieutenant George Eve-rest, inspite of the casualities (entire teams of about 150 were wiped out at times), mapped India.

Model of accuracy and the maps which it yielded faithfully....indicating 'the position of every town, fort, village.. all rivers and their courses, the roads, the lakes, tanks [reservoirs], defiles, mountains, and every remarkable object, feature, and propert of the country'

Inspite of the combined assault of climate and local prejudice which contributed to wiping out survey parties in single season, they carried on relentlessly sometimes taking long sabbaticals to recuperate from exhaustion and sickness.

Nothing gives a better idea of his passion for shaving tolerances to an infinitesimal minimum than this pursuit of a variable amounting to just seven thousandths of an inch.

But at times the measurements made by zenith observations could not be reconciled by triangulation.

It was said that if experienced observers, taking all possible precautions, found rhemselves confronting an anomoly for which they could not account, they were probably 'on the vergeof some important discovery'' - The fact that mountain masses exercise an attraction over the plumbline

Finally in 1857 the "Great Meridional Arc of India" was completed, The heights of the major himalayan peaks (Nanda Devi, K2, Kanchenajunga) were ascertained and Mount Everest was named (obvously in honour of Lieutenant George Eve-rest) . During this period Surgeon Ronald Ross discovered the source of Malaria at Begumpet (Hyderabad)

In the land of rope tricks, snake charners, superstions, spirituality and sadhus; This sweat soaked odyssey was the largest scientific endaevour known to man. It was one of the most stupendous works in the whole history of science.

An Awesome Project.

My laws on Software Project Management!

Here is a look at the lighter side of software project management. ENJOY!!!
  1. The silliest bug will find your best customer.
  2. If a software code has been found defective, its author has just embarked on a plane to the US.
  3. After improving quality from 95% to 99%, the remaining 1% defects will find its way to your regular paying customer.
  4. The moment you disciver that additional testing is required, the software code has lareday been FTP'd to your customer.
  5. The number of Quality Control Procedures followed is inversely propotional to the number of programmers who folow them and the number of project managers who understand them.
  6. The number of testing cycles that an application undergoes is directly proportional to the number of defects it is shipped with.
  7. The best product that marketing wants to sell is the one which 'Product Delivery' is least interested.
  8. The product in which both marketing and 'Product Delivery' agree upon is th eone in which the customer is least interested.
  9. A mission critical application is likely to break down because of the smallest unit of code.
  10. The probability of an application failing increases rapidly as the warranty period is about to expire.
  11. A random sample in a Customer survey will not include a disgruntled customer.
  12. The project manager who complains about quality the most is the one who understands quality the least.
  13. If a company has just obtained its quality certification (ISO/CMM), customers have recently complained about the numerous bugs in the application.
  14. When your client asks about a missing business requirement in the specifications, its probably the first time you ask the same question yourself.
  15. When you conduct a training program, the person who needs it most will be firefighting to attend it.
  16. During the arer times a manager enquires about a certain project, the projectmanager is on leave.
  17. 90% of the software defects are discovered by your client, the rest by your testing team
  18. The client who demands the most prompt delivery is the least prompt in payment.
  19. The intensity or length of a company's celebration in launching a product or obtainig a project is inversely proportional to the life of it.
  20. The more eloquent or impressive a presentation to a prospective cleint is, the more bleak is the chances of them buying the idea.

Monday, November 08, 2004

Cathedral and the Bazaar

A couple of days back I had blogged with comments on the book by Eric Raymond. This is what he has to say.

  1. Every good work of software starts by scratching a developer's personal itch
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse)
  3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
  4. If you have the right attitude, interesting problems will find you
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor
  6. Treating your users as co-developers is your lest-hassle route to rapid code improvement and effective debugging
  7. Release early. release often. And listen to your customers
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone
  9. Smart data structures and dumb code works a lot better than the other way around
  10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong
  13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to yo
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
If this makes sense then read the full book. If this doesnt make sense then you must read the book, Better still get some formal education in software engineering.

Saturday, November 06, 2004

Resource Marshalling

20 People in 5 days. Thats the number of prospective new hires I spoke to this week - in person, telephonic.... Guess I was down on luck got to shortlist just a few of them. Found one thing common amongst all of them - lack of passion, They are here just to land their next job. There were Project Managers who were not aware of (and hence obviously did not practice) Requirements management, traceability; Design was limited to drawing a few rectangles and arrows in MS Word or Visio; Estimations and scheduling were based on prior experience (mystical I guess!) and not on Function Points; No reports to management, no phase ends, no schedule monitoring, no quality plans, no risk identification and hence no mitigation; no histograms, no pareto analysis, no formal defect prevention mechanisms other than probably yelling at the team!; and so NO LEARNINGS. Yet all of them draw fat salaries that would be the envy of neighbours and friends. WHY?

Now Reading

Its been a good week. Completed reading "Cathedral and the Bazaar" an essay by Eric Rayomond on software development more specifically on the methods. The "Cathedral" style followed by most software development organisations and the "Bazaar" style followed by a cohesive set of volunteers like the Linux Kernel Project, Mozilla, GNU Cash etc. He goes on to disprove a lot of conventions that we have as project managers on motivation, resource marshalling, schedule, budget and time, and proves very convincingly the superiority of "Bazaar" style development. Which in hindsight is true considering that most of us have a contempt for documentation and quality processes. But we still believe that the "Cathedral" style will provide that magic cure to all our software development ills. Such Shortsightedness. Well now on to another masterpiece