I just found out a website where our Uttarpara Apartment (Regent Ganga by RDB Industries) plans are available....nice...here is it....
Tuesday, October 27, 2009
Manifesto For Software Craftmanship.....
Have been neglecting the blogging demands for some time now..
Here's a quick update of something exciting. Recently I became a signatory of the Manifesto of Software Craftsmanship.
It's a group of likeminded individuals who believe building software is a high-end craft. The journey to become an expert craftsman (just like any other craft) is a long and self-learning and rewarding one - full of pitfalls and ecstacies.
For the uninitiated - here's the manifesto
Manifesto for Software Craftsmanship
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Yes, it's very similar to the Agile manifesto and that's because the movement is sort of an offshoot from the Agile movement, and a lot of signatories are people who are "agile-minded and spirited" to the core..
We believe in the Agile principles (people oever processes, collaboration over negotiation etc etc) but more importantly, we believe that Software craftsmanship is a step further in the journey towards great software build by great teams....
Proud to be part of the movement....invite you to join in....it'll be a great adventure....
Here's a quick update of something exciting. Recently I became a signatory of the Manifesto of Software Craftsmanship.
It's a group of likeminded individuals who believe building software is a high-end craft. The journey to become an expert craftsman (just like any other craft) is a long and self-learning and rewarding one - full of pitfalls and ecstacies.
For the uninitiated - here's the manifesto
Manifesto for Software Craftsmanship
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Yes, it's very similar to the Agile manifesto and that's because the movement is sort of an offshoot from the Agile movement, and a lot of signatories are people who are "agile-minded and spirited" to the core..
We believe in the Agile principles (people oever processes, collaboration over negotiation etc etc) but more importantly, we believe that Software craftsmanship is a step further in the journey towards great software build by great teams....
Proud to be part of the movement....invite you to join in....it'll be a great adventure....
Saturday, August 15, 2009
LOVE YOUR JOB, BUT NEVER FALL IN LOVE WITH YOUR COMPANY BCOZ U NEVER KNOW WHEN COMPANY STOPS LOVING YOU
Extract of Mr. Narayana Murthy's Speech during Mentor Session:
I know people who work 12 hours a day, six days a week, or more. Some people do so because of a work emergency where the long hours are only temporary. Other people I know have put in these hours for years. I don't know if they are working all these hours, but I do know they are in the office this long. Others put in long office hours because they are addicted to the workplace. Whatever the reason for putting in overtime, working long hours over the long term is harmful to the person and to the organization.
There are things managers can do to change this for everyone's benefit.Being in the office long hours, over long periods of time, makes way for potential errors. My colleagues who are in the office long hours frequently make mistakes caused by fatigue. Correcting these mistakes requires their time as well as the time and energy of others.I have seen people work Tuesday through Friday to correct mistakes made after 5 PM on Monday.
Another problem is that people who are in the office for long hours are not pleasant company. They often complain about other people (who aren't working as hard); they are irritable, or cranky, or even angry. Other people avoid them.Such behaviour poses problems, where work goes much better when people work together instead of avoiding one another. As Managers,there are things we can do to help people leave the office.
First and foremost is to set the example and go home ourselves. I work with a manager who chides people for working long hours. His words quickly lose their meaning when he sends these chiding group e-mails with a Time-stamp of 2 AM, Sunday. Second is to encourage people to put some balance in their lives. For instance, here is a guideline I find helpful:
1) Wake up, eat a good breakfast, and go to work.
2) Work hard and smart for eight or nine hours.
3) Go home.
4) Read the comics, watch a funny movie, dig in the dirt, play with your kids, etc.
5) Eat well and sleep well.
This is called recreating. Doing steps 1, 3, 4, and 5 enable step 2.
Working regular hours and recreating daily are simple concepts. They are hard for some of us because that requires personal change. They are possible since we all have the power to choose to do them.In considering the issue of overtime, I am reminded of my eldest son. When he was a toddler, if people were visiting the apartment, he would not fall asleep no matter how long the visit, and no matter what time of day it was.! He would fight off sleep until the visitors left. It was as if he was afraid that he would miss something. Once our visitors' left, he would go to sleep.By this time, however, he was over tired and would scream through half the night with nightmares. He, my wife, and I, all paid the price for his fear of missing out. Perhaps some people put in such long hours because they don't want to miss anything when they leave the office. The trouble with this is that events will never stop happening. That is life !
Things happen 24 hours a day. Allowing for little rest is not ultimately practical. So, take a nap.Things will happen while you're asleep, but you will have the energy to catch up when you wake. Hence.
"LOVE YOUR JOB BUT NEVER FALL IN LOVE WITH YOUR COMPANY" .
- Narayana Murthy
I know people who work 12 hours a day, six days a week, or more. Some people do so because of a work emergency where the long hours are only temporary. Other people I know have put in these hours for years. I don't know if they are working all these hours, but I do know they are in the office this long. Others put in long office hours because they are addicted to the workplace. Whatever the reason for putting in overtime, working long hours over the long term is harmful to the person and to the organization.
There are things managers can do to change this for everyone's benefit.Being in the office long hours, over long periods of time, makes way for potential errors. My colleagues who are in the office long hours frequently make mistakes caused by fatigue. Correcting these mistakes requires their time as well as the time and energy of others.I have seen people work Tuesday through Friday to correct mistakes made after 5 PM on Monday.
Another problem is that people who are in the office for long hours are not pleasant company. They often complain about other people (who aren't working as hard); they are irritable, or cranky, or even angry. Other people avoid them.Such behaviour poses problems, where work goes much better when people work together instead of avoiding one another. As Managers,there are things we can do to help people leave the office.
First and foremost is to set the example and go home ourselves. I work with a manager who chides people for working long hours. His words quickly lose their meaning when he sends these chiding group e-mails with a Time-stamp of 2 AM, Sunday. Second is to encourage people to put some balance in their lives. For instance, here is a guideline I find helpful:
1) Wake up, eat a good breakfast, and go to work.
2) Work hard and smart for eight or nine hours.
3) Go home.
4) Read the comics, watch a funny movie, dig in the dirt, play with your kids, etc.
5) Eat well and sleep well.
This is called recreating. Doing steps 1, 3, 4, and 5 enable step 2.
Working regular hours and recreating daily are simple concepts. They are hard for some of us because that requires personal change. They are possible since we all have the power to choose to do them.In considering the issue of overtime, I am reminded of my eldest son. When he was a toddler, if people were visiting the apartment, he would not fall asleep no matter how long the visit, and no matter what time of day it was.! He would fight off sleep until the visitors left. It was as if he was afraid that he would miss something. Once our visitors' left, he would go to sleep.By this time, however, he was over tired and would scream through half the night with nightmares. He, my wife, and I, all paid the price for his fear of missing out. Perhaps some people put in such long hours because they don't want to miss anything when they leave the office. The trouble with this is that events will never stop happening. That is life !
Things happen 24 hours a day. Allowing for little rest is not ultimately practical. So, take a nap.Things will happen while you're asleep, but you will have the energy to catch up when you wake. Hence.
"LOVE YOUR JOB BUT NEVER FALL IN LOVE WITH YOUR COMPANY" .
- Narayana Murthy
Monday, August 3, 2009
Managing Tough Projects - Some points of advise
Steps for When the Project Starts to Fall Behind
1. Renegotiate. Discuss with stakeholders about increasing the budget or extending the deadline.
2. Recover during later steps. Reexamine budgets and schedules to see if you can you make up the time elsewhere.
3. Narrow project scope. Are there nonessential elements of the project that can be dropped to reduce costs and save time.
4. Deploy more resources. Can you put more people or machines to work? Weigh the costs against the importance of the deadline.
5. Accept substitution. Can you substitute a less-expensive or more readily available item?
6. Seek alternative sources. Can another source supply the missing item?
7. Accept partial delivery. Can you accept a few of a missing item to keep work going and complete the delivery later?
8. Offer incentives. Can you offer bonuses or other incentives for on-time delivery?
9. Demand compliance. Will demanding that people do what they said they would get the desired result? This may require support from upper management.
Steps for Building a Gantt Chart.
1. List phases of project, from first to last, down left side of page.
2. Add time scale across bottom from beginning to deadline.
3. Draw blank rectangle for phase one from phase start date to estimated completion date.
4. Draw rectangles for each remaining phase; make sure dependent phases start on or after the date that any earlier, dependent phases finish.
5. For independent phases, draw time-estimate rectangles according to preferences of people doing and supervising the work.
6. Adjust phase time estimates as needed so that the entire project finishes on or before deadline.
7. Add a milestone legend as appropriate.
8. Show chart to stakeholders and team members for feedback.
9. Adjust as needed.
Tips for Scheduling
1. Know which deadlines are hard-and-fast and which are not.
2. Compare your project to similar previous projects.
3. No task should last longer than four to six weeks. When tasks approach that time frame, they can probably be broken down further.
4. Don’t schedule more detail than you yourself can actually oversee.
5. Develop schedules according to what is logically possible: resource allocation should be done later.
6. Record all time segments in the same increments. Do not schedule a project so that overtime is needed to meet original target dates; this leaves little flexibility for handling problems that might occur later.
Tips for Monitoring Budgets
When monitoring actual costs against your estimate, watch out for these common contingencies that can send your project over budget:
1. Inflation during long-term projects.
2. Failing to factor in currency exchange rates.
3. Not getting firm prices from suppliers and subcontractors.
4. Estimates based on different costing methods; for example, hours vs. dollars.
5. Capital equipment purchased before the plan.
6. Unplanned personnel costs used to remain on schedule, including increased overtime.
7. A need for additional space.
8. Unexpected training costs.
9. Consultant fees for unforeseen problems.
The following contingencies contribute to costs being under budget:
1. Capital expenditures not made as planned.
2. Staff not allocated as planned.
1. Renegotiate. Discuss with stakeholders about increasing the budget or extending the deadline.
2. Recover during later steps. Reexamine budgets and schedules to see if you can you make up the time elsewhere.
3. Narrow project scope. Are there nonessential elements of the project that can be dropped to reduce costs and save time.
4. Deploy more resources. Can you put more people or machines to work? Weigh the costs against the importance of the deadline.
5. Accept substitution. Can you substitute a less-expensive or more readily available item?
6. Seek alternative sources. Can another source supply the missing item?
7. Accept partial delivery. Can you accept a few of a missing item to keep work going and complete the delivery later?
8. Offer incentives. Can you offer bonuses or other incentives for on-time delivery?
9. Demand compliance. Will demanding that people do what they said they would get the desired result? This may require support from upper management.
Steps for Building a Gantt Chart.
1. List phases of project, from first to last, down left side of page.
2. Add time scale across bottom from beginning to deadline.
3. Draw blank rectangle for phase one from phase start date to estimated completion date.
4. Draw rectangles for each remaining phase; make sure dependent phases start on or after the date that any earlier, dependent phases finish.
5. For independent phases, draw time-estimate rectangles according to preferences of people doing and supervising the work.
6. Adjust phase time estimates as needed so that the entire project finishes on or before deadline.
7. Add a milestone legend as appropriate.
8. Show chart to stakeholders and team members for feedback.
9. Adjust as needed.
Tips for Scheduling
1. Know which deadlines are hard-and-fast and which are not.
2. Compare your project to similar previous projects.
3. No task should last longer than four to six weeks. When tasks approach that time frame, they can probably be broken down further.
4. Don’t schedule more detail than you yourself can actually oversee.
5. Develop schedules according to what is logically possible: resource allocation should be done later.
6. Record all time segments in the same increments. Do not schedule a project so that overtime is needed to meet original target dates; this leaves little flexibility for handling problems that might occur later.
Tips for Monitoring Budgets
When monitoring actual costs against your estimate, watch out for these common contingencies that can send your project over budget:
1. Inflation during long-term projects.
2. Failing to factor in currency exchange rates.
3. Not getting firm prices from suppliers and subcontractors.
4. Estimates based on different costing methods; for example, hours vs. dollars.
5. Capital equipment purchased before the plan.
6. Unplanned personnel costs used to remain on schedule, including increased overtime.
7. A need for additional space.
8. Unexpected training costs.
9. Consultant fees for unforeseen problems.
The following contingencies contribute to costs being under budget:
1. Capital expenditures not made as planned.
2. Staff not allocated as planned.
Monday, July 20, 2009
PCI DSS 101
Here are the basic tenets of PCI DSS regulation. There are divided into six major principles/canonicals and a total of 12 requirements each of which fall in any of the 6 major canonicals.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software.
Requirement 6: Develop and maintain secure systems and applications.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know.
Requirement 8: Assign a unique ID to each person with computer access.
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data.
Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security.
So much for now.....may be there will be a PCI DSS 201 soon.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software.
Requirement 6: Develop and maintain secure systems and applications.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know.
Requirement 8: Assign a unique ID to each person with computer access.
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data.
Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security.
So much for now.....may be there will be a PCI DSS 201 soon.
Sunday, June 28, 2009
97 things SW Architects should know
Found this fantastic website. It's more of a wiki where people have collaborated to bring out a master list of "gems of wisdom" from SW architects for all future ones...
http://97-things.near-time.net/wiki
Here's the collected list (as of today)...I guess this has been distilled and released as a book by O'Reilly....would be a great book to get hands on....
http://97-things.near-time.net/wiki
Here's the collected list (as of today)...I guess this has been distilled and released as a book by O'Reilly....would be a great book to get hands on....
- Don't put your resume ahead of the requirements by Nitin Borwankar
- Simplify essential complexity; diminish accidental complexity by Neal Ford
- Chances are your biggest problem isn't technical by Mark Ramm
- Communication is King; Clarity and Leadership its humble servants by Mark Richards
- Architecting is about balancing by Randy Stafford
- Seek the value in requested capabilities by Einar Landre
- Stand Up! by Udi Dahan
- Skyscrapers aren't scalable by Micheal Nygard
- You're negotiating more often than you think by Michael Nygard
- Quantify by Keith Braithwaite
- One line of working code is worth 500 of specification by Allison Randal
- There is no one-size-fits-all solution by Randy Stafford
- It's never too early to think about performance by Rebecca Parsons
- Application architecture determines application performance by Randy Stafford
- Commit-and-run is a serious crime. Respect your Colleagues by Niclas Nilsson
- There Can be More than One by Keith Braithwaite
- Business Drives by Dave Muirhead
- Simplicity before generality, use before reuse by Kevlin Henney
- Architects must be hands on by John Davies
- Continuously Integrate by Dave Bartlett
- Avoid Scheduling Failures by Norman Carnovale
- Architectural Tradeoffs by Mark Richards
- Database as a Fortress by Dan Chak
- Use uncertainty as a driver by Kevlin Henney
- Scope is the enemy of success by Dave Quick
- Reuse is about people and education, not just architecture by Jeremy Meyer
- There is no 'I' in architecture by Dave Quick
- Get the 1000ft view by Erik Doernenburg
- Try before choosing by Erik Doernenburg
- Understand The Business Domain by Mark Richards
- Programming is an act of design by Einar Landre
- Time changes everything by Philip Nelson
- Give developers autonomy by Philip Nelson
- Value stewardship over showmanship by Barry Hawkins
- Warning, problems in mirror may be larger than they appear by Dave Quick
- The title of software architect has only lower-case 'a's; deal with it by Barry Hawkins
- Software architecture has ethical consequences by Michael Nygard
- Everything will ultimately fail by Michael Nygard
- Context is King by Edward Garson
- It's all about performance by Craig L Russell
- Engineer in the white spaces by Michael Nygard
- Talk the Talk by Mark Richards
- Heterogeneity Wins by Edward Garson
- Dwarves, Elves, Wizards, and Kings by Evan Cofsky
- Learn from Architects of Buildings by Keith Braithwaite
- Fight repetition by Niclas Nilsson
- Welcome to the real world by Gregor Hohpe
- Don't Control, but Observe by Gregor Hohpe
- Janus the Architect by Dave Bartlett
- Architects focus is on the boundaries and interfaces by Einar Landre
- Challenge assumptions - especially your own by Timothy High
- Record your rationale by Timothy High
- Empower developers by Timothy High
- It is all about the data by Paul W. Homer
- Control the data, not just the code by Chad LaVigne
- Don't Stretch The Architecture Metaphorsby David Ing
- Focus on Application Support and Maintenance by Mncedisi Kasper
- Prepare to pick twoby Bill de hOra
- Prefer principles, axioms and analogies to opinion and taste by Michael Harmer
- Start with a Walking Skeleton by Clint Shank
- Share your knowledge and experiencesby Paul W. Homer
- Make sure the simple stuff is simple by Chad LaVigne
- If you design it, you should be able to code it by Mike Brown
- The ROI variable by George Malamidis
- Your system is legacy, design for it by Dave Anderson
- If there is only one solution, get a second opinion by Timothy High
- Understand the impact of change by Doug Crawford
- You have to understand Hardware too by Kamal Wickramanayake
- Shortcuts now are paid back with interest later by Scot Mcphee
- "Perfect" is the Enemy of "Good Enough" by Greg Nyberg
- Avoid "Good Ideas" by Greg Nyberg
- Great content creates great systems by Zubin Wadia
- The Business Vs. The Angry Architect by Chad LaVigne
- Stretch key dimensions to see what breaks by Stephen Jones
- Before anything, an architect is a developer by Mike Brown
- A rose by any other name will end up as a cabbage by Sam Gardiner
- Stable problems get high quality solutions by Sam Gardiner
- It Takes Diligence by Brian Hart
- Take responsibility for your decisions by Yi Zhou
- Dont Be a Problem Solver by Eben Hewitt
- Choose your weapons carefully, relinquish them reluctantlyby Chad LaVigne
- Your Customer is Not Your Customer by Eben Hewitt
- It will never look like that by Peter Gillard-Moss
- Choose Frameworks that play well with others by Eric Hawthorne
- Making a strong business case by Yi Zhou
- Pattern Pathology by Chad LaVigne
- Learn a new language by Burk Hufnagel
- Dont Be Clever by Eben Hewitt
- Build Systems to be Zuhanden by Keith Braithwaite
- Find and retain passionate problem solvers by Chad LaVigne
- Software doesnt really exist by Chad LaVigne
- Pay down your technical debt by Burk Hufnagel
- You can't future-proof solutions by Richard Monson-Haefel
- The User Acceptance Problem by Norman Carnovale
- The Importance of Consommé by Eben Hewit
- For the end-user, the interface is the system by Vinayak Hegde
- Great software is not built, it is grown by Bill de hora
Other Things Software Architects Should Know
The axioms have been accepted into the web project but not the 97 Things book . Axioms here are complete and useful and should be considered great runner-ups to the axioms on the other two lists. Thanks to everyone who conributed these axioms as well as others - they all provide great advice and should be read in addition to the other axioms.- Architects should be Pragmatic by John Davies
- Applications are for making users as effective as possible by Ben Geyer
- Community by Evan Cofsky
- Know all the rules -- so you know which ones you're breaking by Kevin Bedell
- Not all problems are solved with a layer of abstraction by Apu Shah
- Learn to be humble by Apu Shah
- Architecture is more than just the pieces byPaul W. Homer
- Responsible explorer by George Malamidis
- Design for limited resources by Mncedisi Kasper
- The fastest system components are the one's that aren't there by John Tullis
- The closer the better by John Tullis
- It's not an architecture if it can't be managed by Dan Pritchett
- Your project does not exist in a vacuum by Charles Martin
- Design for needs, not wants by Claudio Perrone
- Consider application failures, and design for ease of recovery by Stephen Jones
- Risk priority by George Malamidis
- Test the Architecture by Matt McKnight
- An architect's responsibility never finishes after the architecture is created by Kamal Wickramanayake
- Change is a constant; architecture needs to be adaptable and the architect needs to be a change driver by Daniel Noguerol
- One alternative is a trap, two are a dilemma, three are freedom by Lior Bar-On
- Work on thy soft skills just as much as on your hard skills by Arnon Rotem-Gal-Oz
- Examine the sourcing of calculated fields by Stephen Jones
- Feel it by Mahomedalid Pacheco
- No, the goal is not the code nor the design by William Martinez
- Quality is a feature by Sam Gardiner
- Good Requirements Are Boring by Eben Hewitt
- Don’t Make Worlds, Make Containers for Worlds by Eben Hewitt
- Architecture = SPICE RTM by António Melo
- Know your limitations by Peter Gillard-Moss
- Tarchitects vs. Marketects vs. Carhitects by Yi Zhou
- Read Philoophy (and related Arts) by Keith Braithwaite
- Prioritize Challenges to Drive Architecture Decisions by Charlie Alfred
- Reduce Conceptual Distance by Charlie Alfred
- The User Interface drives the User Experience by Burk Hufnagel
- If you're unwilling to be hands-on, maybe you should keep your hands off by Barry Hawkins
- Lead by Influence by Travis Illig
- Software Should Be Invisible by Eben Hewitt
- Requirements are not the measure of success but the beginnings of a conversation by Christopher Dempsey
Sunday, June 21, 2009
Changes in PMBOK 4th Edition (as compared with 3rd Edition)
The 4th edition of PMI BOK has no major structural changes.
The idea behind this revision was to simplify some processes e.g dropping the Preliminary Project Scope Statements, Conditional and GERT scheduling and Activity on arrow (AOA).
One of the good things (and this has helped PMI is achieveing its position)that PMI has always followed is to keep abreast of the project management methodologies and also to be aware of deadwood (and dump it).
Based on my experience I can vouch that I never used (and doubt if I will ever) GERT scheduling or Activity on Arrow.
Also, PMBOK 4th edition has more details on project justification and project environment. Both of these make sense -
1) Project Justification - being in the IT industry I believe this is where most projects get delayed or "dead-on-birth" because too much or too else happens in justifying the project
2) Project Environment - There are just too many variables in the environment to overlook them. The best way is to be aware and track as many as possible...
Specific to the PMI notion of processes (44 current processes) the changes are:
1) Integration Management – reduced to 6 (earlier 7)- PPSS has been removed
2) Scope Management - – Unchanged(5) - but "Scope Planning" is replaced by "Collect Requirements" (I think this is a great change....in my experience eliciting requirement is a much broader aspect in scope management rather than planning)
3) Time Management – unchanged (6), minor edits but no major changes
4) Cost Management – unchanged (3), minor edits but no major changes
5) Quality Management – unchanged (3), minor edits but no major changes
6) HR management – unchanged (4), minor edits but no major changes
7) Communication Management – increased to 5 (earliuer 4) - addition of "Identify Stakeholders"
8) Risk Management - unchanged (6), minor edits but no major changes
9) Procurement Management - reduced to 4 (earlier 6) - However most of the content is same, some structural changes - content repackaging into Plan/Conduct/Admin/Close
Hope this helps...Will add more details as and when possible..
Ciao
The idea behind this revision was to simplify some processes e.g dropping the Preliminary Project Scope Statements, Conditional and GERT scheduling and Activity on arrow (AOA).
One of the good things (and this has helped PMI is achieveing its position)that PMI has always followed is to keep abreast of the project management methodologies and also to be aware of deadwood (and dump it).
Based on my experience I can vouch that I never used (and doubt if I will ever) GERT scheduling or Activity on Arrow.
Also, PMBOK 4th edition has more details on project justification and project environment. Both of these make sense -
1) Project Justification - being in the IT industry I believe this is where most projects get delayed or "dead-on-birth" because too much or too else happens in justifying the project
2) Project Environment - There are just too many variables in the environment to overlook them. The best way is to be aware and track as many as possible...
Specific to the PMI notion of processes (44 current processes) the changes are:
1) Integration Management – reduced to 6 (earlier 7)- PPSS has been removed
2) Scope Management - – Unchanged(5) - but "Scope Planning" is replaced by "Collect Requirements" (I think this is a great change....in my experience eliciting requirement is a much broader aspect in scope management rather than planning)
3) Time Management – unchanged (6), minor edits but no major changes
4) Cost Management – unchanged (3), minor edits but no major changes
5) Quality Management – unchanged (3), minor edits but no major changes
6) HR management – unchanged (4), minor edits but no major changes
7) Communication Management – increased to 5 (earliuer 4) - addition of "Identify Stakeholders"
8) Risk Management - unchanged (6), minor edits but no major changes
9) Procurement Management - reduced to 4 (earlier 6) - However most of the content is same, some structural changes - content repackaging into Plan/Conduct/Admin/Close
Hope this helps...Will add more details as and when possible..
Ciao
Thursday, June 11, 2009
Microsoft Project Tips and Tricks
The following is a collection of Tips and Tricks for Microsoft Project. Unless otherwise noted, these tips and tricks work with all versions of Microsoft Project.
I would try and keep this list updated as and when I get more cheats or tricks
1. In the Gantt Chart, doubleclick on the right edge of a column header to "best fit" the column.
2. To quickly change the name of a column, doubleclick in the column header and enter a new name for the field in the Title field. For example, you may want to abbreviate the Duration field name to Dur to allow the field to be narrower.
3. To quickly change the field in a column, doubleclick in the column header and select the new field from the Field Name list. While in the Field Name list, press the first letter of the desired field to go to that field.
4. In the Gantt Chart Table (or any table), to quickly hide a column, click on the right edge of the column header and drag it to the left until it disappears (becomes a 0 width column). To display this hidden column, place the cursor a little to the right of the column separator bar where the column used to be, click and drag to the right.
5. You can wrap text in the Gantt Chart to display text on multiple lines if you increase the row height. To increase the row height, place the cursor between any two row numbers (if the ID field is displayed in the first column and is "locked"), click and drag down to increase the row height. Only Text fields wrap and only if the column is narrower than the text in the field.
6. When printing Gantt Charts (or other timescaled charts) you can adjust the width of the timescale to fit the page without changing the timescale units. Doubleclick on the Timescale and increase the number in the % field (or Enlarge field in some versions of Project) to make the timescale take up more of the page or decrease the number in the % (or Enlarge) field to make the timescale narrower. The latter step is useful when a chart is just a little too wide to fit on a page.
7. To select two or more non-adjacent tasks, click on a task (in the table area), hold down the Ctrl Key and click on another task in the chart. Continue holding the Ctrl key to select other tasks. This is especially useful for linking or unlinking tasks that are not on consecutive rows.
8. To change information for a number of tasks at once, highlight the desired tasks (select non-adjacent tasks using the method described above) and select the Task Information button. Enter the common information in one of the fields displayed in the "Multiple Task Information" dialog box.
9. To remove a date constraint from a task, select the task (or multiple tasks) and select the Task Information button. Click in the Advanced tab, change the Type field to As Soon As Possible and click OK. This removes any date constraint in the task and allows it to be scheduled based on the dependencies rather than a date entered (perhaps accidentally) by a user.
10. If a task does not move (reschedule) based on a dependency, it may contain a "fixed" date of some kind. A fixed date could be an Actual Start or a constraint such as Must Start On or Start No Earlier Than. Use the Tasks with Fixed Dates Filter to view only those tasks in a plan that contain fixed dates. You can then determine if these tasks should have these types of fixed dates. Use the previous tip to remove an unwanted constraint.
11. If after removing the Actual Start and any constraint (such as Must Start On or Start No Earlier Than) a task still does not reschedule based on a dependency, check the Resource Leveling feature. Make sure Automatic Leveling is turned off by selecting Resource Leveling from the Tools menu and choosing Manual. If a task still does not move, it may contain a delay based on a previous Resource Level. Select Resource Leveling again from the Tools menu and choose Clear Leveling. Select whether or not to remove Leveling from the selected tasks or for the entire project.
12. After applying a Filter in a Gantt chart press F3 to view all tasks again instead of applying the All Tasks filter.
13. Press Alt-Home in the Gantt chart to position the chart on the start of the project.
14. If you have indented tasks to create Summary Tasks and Detail Tasks, click the little box with the minus sign to the left of the Summary Task name to quickly hide the detail tasks below it. Click the box with the plus sign to display the detail tasks that were hidden.
15. In the Gantt chart, you can create dependencies by clicking on the Gantt bar of a task and dragging to another Gantt bar to create a Finish-to-Start dependency between the two tasks.
16. To quickly modify or delete a dependency, doubleclick on the dependency line between the two tasks to display the Task Dependency form (be sure to place your cursor directly on the dependency line).
17. In any drop down list such as the list of Resource Names or the list of Filters you can press the first letter of the item you are looking for to quickly go that item.
18. Use the Insert key on your keyboard to quickly insert rows and columns. In the Gantt chart, click on a row and press the Insert key to insert a blank row above the selected row. Click on a column header to highlight a column and press Insert to insert a column to the left of the selected column. You can also use the Delete key to reverse this process but be careful…
19. In the Network Diagram (or PERT Chart in some versions of Project), to move multiple task boxes, click in the chart area, drag the cursor to select any number of boxes and release the cursor. Then, click on the border of a box and drag the entire selection of boxes to a new location. In Project 2000, 2002 and 2003 you must first select the Format menu, Layout and then Manual Box Positioning to enable the ability to move task boxes around.
20. An often overlooked but handy report is the Calendar view using a Resource Filter. Select Calendar from the View menu. Select the Using Resource… Filter and type in the name of the desired resource to display the Calendar for a particular resource. This produces a nice printout of a resource’s tasks with each month of a project on a separate page.
21. For Project 2000, 2002 and 2003, to prevent an item from appearing in the legend for the Gantt chart, select the Format menu, Bar Styles and place an asterisk (*) before the name of the item that you do not want to appear. In Project 98 you can delete the bar styles you do not use to avoid displaying them in the legend.
22. Right click in the Toolbar area to display the list of available Toolbars. A check next to a Toolbar indicates that it is currently displayed. Click on a Toolbar to display or hide it.
23. In the Gantt Chart (or any chart with a table and a chart area) doubleclick the separator line between the table and chart to automatically push the separator line to the closest column edge.
24. To split the screen and place a specific View into the lower pane, hold the shift key while selecting an item from the View menu. You can also split the screen by selecting Split from the Window menu or doubleclick the small horizontal split bar in the lower right corner of the screen. Doubleclick it again to remove the split (or choose Remove Split from the Windows menu).
25. Just for fun - Create two 10 day tasks. Place the cursor in the Finish field of the first task and click the Copy button. Place the cursor in the Start field of the second task and select Paste Special-Paste Link from the Edit menu. Place the cursor on the Finish field of the second task and click the Copy button. Place the cursor on the Start field of the first task, select Paste Special-Paste Link and watch the tasks "walk" across the chart. Delete one of the tasks to stop.
I would try and keep this list updated as and when I get more cheats or tricks
1. In the Gantt Chart, doubleclick on the right edge of a column header to "best fit" the column.
2. To quickly change the name of a column, doubleclick in the column header and enter a new name for the field in the Title field. For example, you may want to abbreviate the Duration field name to Dur to allow the field to be narrower.
3. To quickly change the field in a column, doubleclick in the column header and select the new field from the Field Name list. While in the Field Name list, press the first letter of the desired field to go to that field.
4. In the Gantt Chart Table (or any table), to quickly hide a column, click on the right edge of the column header and drag it to the left until it disappears (becomes a 0 width column). To display this hidden column, place the cursor a little to the right of the column separator bar where the column used to be, click and drag to the right.
5. You can wrap text in the Gantt Chart to display text on multiple lines if you increase the row height. To increase the row height, place the cursor between any two row numbers (if the ID field is displayed in the first column and is "locked"), click and drag down to increase the row height. Only Text fields wrap and only if the column is narrower than the text in the field.
6. When printing Gantt Charts (or other timescaled charts) you can adjust the width of the timescale to fit the page without changing the timescale units. Doubleclick on the Timescale and increase the number in the % field (or Enlarge field in some versions of Project) to make the timescale take up more of the page or decrease the number in the % (or Enlarge) field to make the timescale narrower. The latter step is useful when a chart is just a little too wide to fit on a page.
7. To select two or more non-adjacent tasks, click on a task (in the table area), hold down the Ctrl Key and click on another task in the chart. Continue holding the Ctrl key to select other tasks. This is especially useful for linking or unlinking tasks that are not on consecutive rows.
8. To change information for a number of tasks at once, highlight the desired tasks (select non-adjacent tasks using the method described above) and select the Task Information button. Enter the common information in one of the fields displayed in the "Multiple Task Information" dialog box.
9. To remove a date constraint from a task, select the task (or multiple tasks) and select the Task Information button. Click in the Advanced tab, change the Type field to As Soon As Possible and click OK. This removes any date constraint in the task and allows it to be scheduled based on the dependencies rather than a date entered (perhaps accidentally) by a user.
10. If a task does not move (reschedule) based on a dependency, it may contain a "fixed" date of some kind. A fixed date could be an Actual Start or a constraint such as Must Start On or Start No Earlier Than. Use the Tasks with Fixed Dates Filter to view only those tasks in a plan that contain fixed dates. You can then determine if these tasks should have these types of fixed dates. Use the previous tip to remove an unwanted constraint.
11. If after removing the Actual Start and any constraint (such as Must Start On or Start No Earlier Than) a task still does not reschedule based on a dependency, check the Resource Leveling feature. Make sure Automatic Leveling is turned off by selecting Resource Leveling from the Tools menu and choosing Manual. If a task still does not move, it may contain a delay based on a previous Resource Level. Select Resource Leveling again from the Tools menu and choose Clear Leveling. Select whether or not to remove Leveling from the selected tasks or for the entire project.
12. After applying a Filter in a Gantt chart press F3 to view all tasks again instead of applying the All Tasks filter.
13. Press Alt-Home in the Gantt chart to position the chart on the start of the project.
14. If you have indented tasks to create Summary Tasks and Detail Tasks, click the little box with the minus sign to the left of the Summary Task name to quickly hide the detail tasks below it. Click the box with the plus sign to display the detail tasks that were hidden.
15. In the Gantt chart, you can create dependencies by clicking on the Gantt bar of a task and dragging to another Gantt bar to create a Finish-to-Start dependency between the two tasks.
16. To quickly modify or delete a dependency, doubleclick on the dependency line between the two tasks to display the Task Dependency form (be sure to place your cursor directly on the dependency line).
17. In any drop down list such as the list of Resource Names or the list of Filters you can press the first letter of the item you are looking for to quickly go that item.
18. Use the Insert key on your keyboard to quickly insert rows and columns. In the Gantt chart, click on a row and press the Insert key to insert a blank row above the selected row. Click on a column header to highlight a column and press Insert to insert a column to the left of the selected column. You can also use the Delete key to reverse this process but be careful…
19. In the Network Diagram (or PERT Chart in some versions of Project), to move multiple task boxes, click in the chart area, drag the cursor to select any number of boxes and release the cursor. Then, click on the border of a box and drag the entire selection of boxes to a new location. In Project 2000, 2002 and 2003 you must first select the Format menu, Layout and then Manual Box Positioning to enable the ability to move task boxes around.
20. An often overlooked but handy report is the Calendar view using a Resource Filter. Select Calendar from the View menu. Select the Using Resource… Filter and type in the name of the desired resource to display the Calendar for a particular resource. This produces a nice printout of a resource’s tasks with each month of a project on a separate page.
21. For Project 2000, 2002 and 2003, to prevent an item from appearing in the legend for the Gantt chart, select the Format menu, Bar Styles and place an asterisk (*) before the name of the item that you do not want to appear. In Project 98 you can delete the bar styles you do not use to avoid displaying them in the legend.
22. Right click in the Toolbar area to display the list of available Toolbars. A check next to a Toolbar indicates that it is currently displayed. Click on a Toolbar to display or hide it.
23. In the Gantt Chart (or any chart with a table and a chart area) doubleclick the separator line between the table and chart to automatically push the separator line to the closest column edge.
24. To split the screen and place a specific View into the lower pane, hold the shift key while selecting an item from the View menu. You can also split the screen by selecting Split from the Window menu or doubleclick the small horizontal split bar in the lower right corner of the screen. Doubleclick it again to remove the split (or choose Remove Split from the Windows menu).
25. Just for fun - Create two 10 day tasks. Place the cursor in the Finish field of the first task and click the Copy button. Place the cursor in the Start field of the second task and select Paste Special-Paste Link from the Edit menu. Place the cursor on the Finish field of the second task and click the Copy button. Place the cursor on the Start field of the first task, select Paste Special-Paste Link and watch the tasks "walk" across the chart. Delete one of the tasks to stop.
Tuesday, June 9, 2009
Agile SW Development - Here are the Bibles (Books that you should read)
For all the hype about Agile, I have seen very few people who have really understood the concepts and processes (you can't understand unless you know how they came about). And this often leads to people making the wrong conclusions about Agile (It's too easy, It's too tough, It's too radical, I can customise it as I wish)...
Here are some classic books that you need to reference if you are serious about Agile. You may not be able to really read all but any one can be a start...
- Agile Project Management with Scrum, Ken Schwaber, Microsoft Press
- Agile and Iterative Development,A Managers Guide, Craig Larman, Addison-Wesley
- Agile Software Development with Scrum, Ken Schwaber and Mike Beedle, Prentice Hall
- The Enterprise and Scrum, Ken Schwaber, Microsoft Press
- Implementing Lean Software Development,From Concept to Cash, Mary & Tom Poppendieck, Addison-Wesley **
- Agile Adoption Patterns,A Roadmap to Organizational Success, Amr Elssamadisy, Addison-Wesley
- Scaling Software Agility,Best Practices for Large Enterprise, Dean Leffingwell, Addison-Wesley **
- User Stories Applied,For Agile Software Development, Mike Cohn, Addison-Wesley
- Agile Estimating and Planning, Mike Cohn, Addison-Wesley
There is a very good wiki on Agile too.
http://www.agilekiwi.com/charting_change.htm
Hope this helps...
Here are some classic books that you need to reference if you are serious about Agile. You may not be able to really read all but any one can be a start...
- Agile Project Management with Scrum, Ken Schwaber, Microsoft Press
- Agile and Iterative Development,A Managers Guide, Craig Larman, Addison-Wesley
- Agile Software Development with Scrum, Ken Schwaber and Mike Beedle, Prentice Hall
- The Enterprise and Scrum, Ken Schwaber, Microsoft Press
- Implementing Lean Software Development,From Concept to Cash, Mary & Tom Poppendieck, Addison-Wesley **
- Agile Adoption Patterns,A Roadmap to Organizational Success, Amr Elssamadisy, Addison-Wesley
- Scaling Software Agility,Best Practices for Large Enterprise, Dean Leffingwell, Addison-Wesley **
- User Stories Applied,For Agile Software Development, Mike Cohn, Addison-Wesley
- Agile Estimating and Planning, Mike Cohn, Addison-Wesley
There is a very good wiki on Agile too.
http://www.agilekiwi.com/charting_change.htm
Hope this helps...
Sunday, May 24, 2009
Bachche....Man Ke Sachche....
Time for some timepass....found this in an email...
Application to the principal ... FOR ???
Well... read it out to bring back that smile on your face
To,
The Principel
Govarment School, Patiyala,
Panjab.
Sir,
Gal E Hai Ki School wich hun Dil nai Lagda, Te Ratta Nu neend nai Aaandi Kyuki School wich kudiya Ghat rahi hai, Te Saddi Class wich ek vi ni hai, jo hai wo bhi Inni mariyal hai ki dekhan nu ji nai karda, te nakhare Asmaan pe. Madam vi koi enni khas patakha nai hai.
Kuch nai te tennu 4 kaam walian hi rakh lawo. Tainnu Bahut Dhanyawadi Howange.
Your Faithfully
All 3rd standard Students
Application to the principal ... FOR ???
Well... read it out to bring back that smile on your face
To,
The Principel
Govarment School, Patiyala,
Panjab.
Sir,
Gal E Hai Ki School wich hun Dil nai Lagda, Te Ratta Nu neend nai Aaandi Kyuki School wich kudiya Ghat rahi hai, Te Saddi Class wich ek vi ni hai, jo hai wo bhi Inni mariyal hai ki dekhan nu ji nai karda, te nakhare Asmaan pe. Madam vi koi enni khas patakha nai hai.
Kuch nai te tennu 4 kaam walian hi rakh lawo. Tainnu Bahut Dhanyawadi Howange.
Your Faithfully
All 3rd standard Students
Saturday, May 9, 2009
Lessons from "The Cathedral And The Bazaar"
Here's a summary of all the lessons learnt (acc to the author himself) in his seminal "The Cathedral and the Bazaar".
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.''
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 least-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 you.
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.
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.''
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 least-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 you.
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.
The Agile Manifesto..and the principles behind it..
For anyone who is starting to work on Agile SW Development, or already managing an Agile Projects, this is where it should all start...even if you have never heard of Agile but have been in Software Development, you'll immediately understand why Agile has become the "catchphrase" now...
First the MANIFESTO ()
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
And now for the 12 principles behind the Manifesto (equally powerful ...if not more)
1) Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2) Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3) Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4) Business people and developers must work
together daily throughout the project.
5) Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
6) The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
7) Working software is the primary measure of progress.
8) Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9) Continuous attention to technical excellence
and good design enhances agility.
10) Simplicity--the art of maximizing the amount
of work not done--is essential.
11) The best architectures, requirements, and designs
emerge from self-organizing teams.
12) At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Here's my 2 Cents to this: Take your time and read the manifesto and the principles several times(atleast 10 attempts) and try to assimilate or challenge each of these based on your experience...you'll realize that these ring the right bells in your mind..
That would be a right start for your move towards "Agile Reincarnation"...
First the MANIFESTO ()
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
And now for the 12 principles behind the Manifesto (equally powerful ...if not more)
1) Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2) Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3) Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4) Business people and developers must work
together daily throughout the project.
5) Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
6) The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
7) Working software is the primary measure of progress.
8) Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9) Continuous attention to technical excellence
and good design enhances agility.
10) Simplicity--the art of maximizing the amount
of work not done--is essential.
11) The best architectures, requirements, and designs
emerge from self-organizing teams.
12) At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Here's my 2 Cents to this: Take your time and read the manifesto and the principles several times(atleast 10 attempts) and try to assimilate or challenge each of these based on your experience...you'll realize that these ring the right bells in your mind..
That would be a right start for your move towards "Agile Reincarnation"...
Friday, May 8, 2009
A Primer to Open Source SW Development Ideas..
A nice modern Zen poem to start the blog:
To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.
Have been doing some study on the Open Source Initiative.
For those who want to have a primer (and it's a lovely read too), here's the most revered article on the subject. It's titles "The Cathedral And The Bazaar" and is written by Eric Raymond.
Coming from Unix background, he was taken in surprise in 1991 by the Open Source movement and became a beliver himself by 1996. He has actually drawn heavily from the experiences he had with Linus Torvalds or Richard Stallman and these have heavily influenced his writings.
Eric is the person who popularised the line "Given Enough Eyeballs, All Bugs Are Shallow". It's actually a one line summary of the concept of a Bazaar (which is how Linux was developed)...where there is no given protocol and ANYONE can say (contribute) whereas the Cathedral mode of development is when there is a Open Source development thru guidelines and frameworks.
Also interesting to note, when you read the article you will start seeing the myriad ways in which Open Source Development is so similar to Agile SW Development Practices.
I found the following ideas of open source development very similar to that of Agile Development.
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 least-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
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.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
18. To solve an interesting problem, start by finding a problem that is interesting to you
19: Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one
So much for today...see you soon
To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.
Have been doing some study on the Open Source Initiative.
For those who want to have a primer (and it's a lovely read too), here's the most revered article on the subject. It's titles "The Cathedral And The Bazaar" and is written by Eric Raymond.
Coming from Unix background, he was taken in surprise in 1991 by the Open Source movement and became a beliver himself by 1996. He has actually drawn heavily from the experiences he had with Linus Torvalds or Richard Stallman and these have heavily influenced his writings.
Eric is the person who popularised the line "Given Enough Eyeballs, All Bugs Are Shallow". It's actually a one line summary of the concept of a Bazaar (which is how Linux was developed)...where there is no given protocol and ANYONE can say (contribute) whereas the Cathedral mode of development is when there is a Open Source development thru guidelines and frameworks.
Also interesting to note, when you read the article you will start seeing the myriad ways in which Open Source Development is so similar to Agile SW Development Practices.
I found the following ideas of open source development very similar to that of Agile Development.
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 least-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
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.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
18. To solve an interesting problem, start by finding a problem that is interesting to you
19: Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one
So much for today...see you soon
Sunday, April 26, 2009
A Short Tutorial - What A to Z means to Bengalis
A is for Awpheesh. (as in Office).This is where the average Kolkakatan goes and spends a day hard at work. And if he works for the 'Vest Bengal Gawrment' he will arrive at 10, wipe his forehead till 11, have a tea break at 12, throw around a few files at 12.30, break for lunch at 1, smoke the 7th unfiltered cigarette at 2, break for 5th cup of tea at 3, sleep sitting down at 4 and go home at 4:30. It's a hard life!
B is for Bhision. For some reason many Bengalis don't have good bhision. In fact in Kolkata most people are wearing spectacles all the time....Bhishon Bhalo and Bibhotso.... though means opposite ...used for same situations.. .depending on the Beauty of fairer sex...are close ...almost in a tie for second spot....
C is for Chappell. Currently, this is the Bengali word for the Devil, for the worst form of evil. In the night mothers put their kids to sleep saying, 'Na ghumoley ebar Chappell eshey dhorey niye jabe.'
D is for Debashish or any other name starting with Deb. By an ancient law every fourth Bengali Child has to be named Debashish. So you have a Debashish everywhere and trying to get creative they are also called Deb, Debu, Deba with variations like Debopriyo, Deboprotim, Debojyoti, etc. thrown in at times....as creations of God himself !!
E is for Eeeeesh. This is a very common Bengali exclamation made famous by Aishwarya Rai in the movie Devdas. It is estimated that on an average a Bengali, especially Bengali women, use eeesh 10,089 times every year. 'Ei Morechhey' is a close second to Eeesh.
F is for Feeesh. These are creatures that swim in rivers and seas and are a favourite food of the Bengalis. Despite the fact that a fish market has such strong smells, with one sniff a Bengali knows if a fish is all right. If not, he will say 'eeesh what feeesh is theesh!'
G is for Good Name (as in .. “so what eej is your good name?”). Every Bengali boy will have a good name like Debashish or Deboprotim and a pet name like Motka, Bhombol, Thobla, etc. While every Bengali girl will have pet names like Tia, Tuktuki, Mishti, Khuku, et cetera.
H is for Harmonium. This is the Bengali equivalent of a rockstar’s guitar. Take four Bengalis and a Harmonium and you have the successors to The Bheatles!
I is for Ileesh. This is a feeesh with 10,987 bones which would kill any ordinary person, but which the Bengalis eat with releeesh!
J is for Jhola. No self-respecting Bengali is complete without his Jhola. It is a shapeless cloth bag where he keeps all his belongings and he fits an amazing number of things in. Even as you read this there are two million jholas bobbling around Kolkata, and they all look exactly the same! Note that 'Jhol' with mysterious condiments.. . as in Maachher Jhol is a close second. Jhaamela and Jachhetai are distant 3rd and 4th
K is for Kee Kaando! It used to be the favourite Bengali exclamation till eeesh took over because of Aishwarya Rai. Kee mushkil is a close second.
L is for Lungi, the dress for all occasions. People in Kolkata manage to play football and cricket wearing it not to mention the daily trip in the morning to the local bajaar. Now there is talk of a lungi expedition to Mt Everest.
M is for Minibaas. These are dangerous half buses whose antics would effortlessly frighten the living daylights out of all James Bond stuntmen as well as Formula 1 race car drivers.
N is for Nangto. This is the Bengali word for Naked. It is the most interesting naked word in any language!
O is for Oil. The Bengalis believe that a touch of mustard oil will cure anything from cold (oil in the nose), to earache (oil in the ear), to cough (oil on the throat) to piles (oil you know where!).
P is for Phootball. This is always a phavourite phassion of the Kolkattan. Every Bengali is born an expert in this game. The two biggest clubs there are MohanBagan and East Bengal and when they play the city comes to a stop.
Q is for Qoshchen (question) as in "Mamatadi Qoshchens Cheap Ministaar in Writaars Buiding."
R is for Robi Thakur. Many many years ago Rabindranath got the Nobel Prize. This has given the right to all Bengalis no matter where they are to frame their acceptance speeches as if they were directly related to the great poet and walk with their head held high. This also gives Bengalis the birthright to look down at Delhi and Mumbai and of course 'all non-Bengawlees'! Note that 'Roshogolla' comes a close second!
S is for Shourov. (as in Saurav) Now that they finally produced a genuine cricketer, (that too a captain) Bengalis think that he should be allowed to play until he is 70 years old.
T is for Trams. Hundred years later there are still trams in Kolkata. Of course if you are in a hurry it's faster to walk....Trams are still existing in Paris too.......you see !
U is for (A)Umbrela. When a Bengali baby is born he is handed one.
V is for Vhaayolence. Bengalis are the most non-violent violent people around. When an accident happens they will fold up their sleeves, shout and scream and curse and abuse, "Chherey De Bolchhi" but the last time someone actually hit someone was in 1939.
W is for Waatar. For three months of the year the city is underwater and every year for the last 200 years the authorities are taken by surprise by this!
X is for X'mas. It's very big in Kolkata, with Park Street fully lit up and all Bengalis agreeing that they must eat cake that day.
Y is for Yesshtaarday. Which is always better than today for a Bengali (see R for Robi Thakur)?. It is also for Jubraj Shingh and Joga.
Z is for Jebra, Joo, and Jipper.
B is for Bhision. For some reason many Bengalis don't have good bhision. In fact in Kolkata most people are wearing spectacles all the time....Bhishon Bhalo and Bibhotso.... though means opposite ...used for same situations.. .depending on the Beauty of fairer sex...are close ...almost in a tie for second spot....
C is for Chappell. Currently, this is the Bengali word for the Devil, for the worst form of evil. In the night mothers put their kids to sleep saying, 'Na ghumoley ebar Chappell eshey dhorey niye jabe.'
D is for Debashish or any other name starting with Deb. By an ancient law every fourth Bengali Child has to be named Debashish. So you have a Debashish everywhere and trying to get creative they are also called Deb, Debu, Deba with variations like Debopriyo, Deboprotim, Debojyoti, etc. thrown in at times....as creations of God himself !!
E is for Eeeeesh. This is a very common Bengali exclamation made famous by Aishwarya Rai in the movie Devdas. It is estimated that on an average a Bengali, especially Bengali women, use eeesh 10,089 times every year. 'Ei Morechhey' is a close second to Eeesh.
F is for Feeesh. These are creatures that swim in rivers and seas and are a favourite food of the Bengalis. Despite the fact that a fish market has such strong smells, with one sniff a Bengali knows if a fish is all right. If not, he will say 'eeesh what feeesh is theesh!'
G is for Good Name (as in .. “so what eej is your good name?”). Every Bengali boy will have a good name like Debashish or Deboprotim and a pet name like Motka, Bhombol, Thobla, etc. While every Bengali girl will have pet names like Tia, Tuktuki, Mishti, Khuku, et cetera.
H is for Harmonium. This is the Bengali equivalent of a rockstar’s guitar. Take four Bengalis and a Harmonium and you have the successors to The Bheatles!
I is for Ileesh. This is a feeesh with 10,987 bones which would kill any ordinary person, but which the Bengalis eat with releeesh!
J is for Jhola. No self-respecting Bengali is complete without his Jhola. It is a shapeless cloth bag where he keeps all his belongings and he fits an amazing number of things in. Even as you read this there are two million jholas bobbling around Kolkata, and they all look exactly the same! Note that 'Jhol' with mysterious condiments.. . as in Maachher Jhol is a close second. Jhaamela and Jachhetai are distant 3rd and 4th
K is for Kee Kaando! It used to be the favourite Bengali exclamation till eeesh took over because of Aishwarya Rai. Kee mushkil is a close second.
L is for Lungi, the dress for all occasions. People in Kolkata manage to play football and cricket wearing it not to mention the daily trip in the morning to the local bajaar. Now there is talk of a lungi expedition to Mt Everest.
M is for Minibaas. These are dangerous half buses whose antics would effortlessly frighten the living daylights out of all James Bond stuntmen as well as Formula 1 race car drivers.
N is for Nangto. This is the Bengali word for Naked. It is the most interesting naked word in any language!
O is for Oil. The Bengalis believe that a touch of mustard oil will cure anything from cold (oil in the nose), to earache (oil in the ear), to cough (oil on the throat) to piles (oil you know where!).
P is for Phootball. This is always a phavourite phassion of the Kolkattan. Every Bengali is born an expert in this game. The two biggest clubs there are MohanBagan and East Bengal and when they play the city comes to a stop.
Q is for Qoshchen (question) as in "Mamatadi Qoshchens Cheap Ministaar in Writaars Buiding."
R is for Robi Thakur. Many many years ago Rabindranath got the Nobel Prize. This has given the right to all Bengalis no matter where they are to frame their acceptance speeches as if they were directly related to the great poet and walk with their head held high. This also gives Bengalis the birthright to look down at Delhi and Mumbai and of course 'all non-Bengawlees'! Note that 'Roshogolla' comes a close second!
S is for Shourov. (as in Saurav) Now that they finally produced a genuine cricketer, (that too a captain) Bengalis think that he should be allowed to play until he is 70 years old.
T is for Trams. Hundred years later there are still trams in Kolkata. Of course if you are in a hurry it's faster to walk....Trams are still existing in Paris too.......you see !
U is for (A)Umbrela. When a Bengali baby is born he is handed one.
V is for Vhaayolence. Bengalis are the most non-violent violent people around. When an accident happens they will fold up their sleeves, shout and scream and curse and abuse, "Chherey De Bolchhi" but the last time someone actually hit someone was in 1939.
W is for Waatar. For three months of the year the city is underwater and every year for the last 200 years the authorities are taken by surprise by this!
X is for X'mas. It's very big in Kolkata, with Park Street fully lit up and all Bengalis agreeing that they must eat cake that day.
Y is for Yesshtaarday. Which is always better than today for a Bengali (see R for Robi Thakur)?. It is also for Jubraj Shingh and Joga.
Z is for Jebra, Joo, and Jipper.
Thursday, April 23, 2009
A Love Note…in C Minor
.r{}
#include
#include
#include
#include
#define Cute beautiful_lady
main()
{
goto college;
scanf(”100%” ,&ladies);
if(lady ==Cute)
line++;
while( !reply )
{
printf(”I Love U”);
scanf(”100%” ,&reply);
}
if(reply == “GAALI”)
main(); .r{}
else if(reply == “SANDAL “)
exit(1);
else if(reply == “I Love U”)
{
lover =Cute ;
love = (heart*)malloc( sizeof(lover) );
}
goto restaurant;
restaurant:
{
food++;
smile++;
pay->money = lover->money;
return(college) ;
}
if(time==2.30)
goto cinema;
cinema:
{
watch++;
if(intermission)
{
coke++;
Popecorn++;
}
}
P.S: This is not my original stuff….came across this nice poem in an email…felt it’s interesting enough to publish…
#include
#include
#include
#include
#define Cute beautiful_lady
main()
{
goto college;
scanf(”100%” ,&ladies);
if(lady ==Cute)
line++;
while( !reply )
{
printf(”I Love U”);
scanf(”100%” ,&reply);
}
if(reply == “GAALI”)
main(); .r{}
else if(reply == “SANDAL “)
exit(1);
else if(reply == “I Love U”)
{
lover =Cute ;
love = (heart*)malloc( sizeof(lover) );
}
goto restaurant;
restaurant:
{
food++;
smile++;
pay->money = lover->money;
return(college) ;
}
if(time==2.30)
goto cinema;
cinema:
{
watch++;
if(intermission)
{
coke++;
Popecorn++;
}
}
P.S: This is not my original stuff….came across this nice poem in an email…felt it’s interesting enough to publish…
Subscribe to:
Posts (Atom)