TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Keeping a Project Journal

Viewing 1-10 of 4191     Collapse Descriptions

Sort by:   Date Posted  |  Title  |  Content Type  |  Relevancy


This is Free Content Original
COLUMN: Keeping a Project Journal
Author(s): Lee Copeland
Summary: If you think that keeping a journal is only for adolescent girls, read this week's column by Lee Copeland. Among other things, he suggests that a project journal helps you stay organized; teaches you what not to do next time; and makes it easier to explain what went wrong in a troubled project when you have to defend yourself. He also gives tips on being a good recorder.

Date Posted: Oct 28, 2002
Comments on this contentComments: 9

This is Free Content LINK: Visual Studio Project Management Journal
Description: Visual Studio Project Management Journal (VSPMJ) was created to reduce the number of software project failures. VSPMJ has no "VB Tips or Tricks," our site is targeted to project managers, QA managers, programmers, and anyone who wants to go beyond the VB code. We have book reviews, discussion groups, and articles to help you improve your VB project management skills.
Link: http://www.vspmj.com
Date Posted: Nov 30, 1999
 

This Content is Accessible by PowerPass UsersCONFERENCE MATERIALS: Testing Dialogues: Technical Issues
Author(s): Facilitated by Esther Derby and Johanna Rothman
Summary: Test professionals face a myriad of issues with immature development technologies, changing systems environments, increasingly complex applications, and 24/7 reliability demands. We must choose the right methodology and best testing techniques to meet these challenges, all with a limited set of tools and not enough time. In this double-track session, you'll be able to ask for help from your peers, share you expertise with the group, and develop some new approaches to your biggest challenges. Johanna Rothman and Esther Derby facilitate this session, focusing on topics such as model based testing, security testing, testing without requirements, testing in the XP/Agile world, and configuration management. Discussions are structured in a framework so that participants will receive a summary or their work product after the conference.
Conference: STARWEST 2003

This Content is Accessible by PowerPass UsersCONFERENCE MATERIALS: Testing Dialogues: Management Issues
Author(s): Facilitated by Esther Derby and Johanna Rothman
Summary: Testing dialogues are a unique platform for you to share your ideas and learn from experienced testers from around the world. In this double session, test managers engage in in-depth, small group discussions with their peers. You'll share your expertise and experiences, learn from others’ challenges and successes, and generate new topics in real-time. Johanna Rothman and Esther Derby facilitate this session, focusing on management issues such as: release criteria; determining ROI of test; coaching and feedback; managing new employees; estimating test time and resources. Bring your BIG issue and start a new dialog with your management peers. Discussions are structured in a framework so that participants will receive a summary or their work product after the conference.
Conference: STARWEST 2003

This Content is Accessible by PowerPass UsersCONFERENCE MATERIALS: Bulletproof your Review Program!
Author(s): Esther Derby, Esther Derby Associates Inc
Summary: In this article, the author explains how to bulletproof your review program by avoiding traps that typically kill technical review programs. She also details four common reasons why review programs fail and what you can do to successfully implement one for your team.
Conference: STAREAST 2003

This Content is Accessible by PowerPass UsersCONFERENCE MATERIALS: Introduce and Sustain a Worldwide Software Inspection Process
Author(s): Marc Rene, GTECH Corporation
Summary: In this presentation you will discover how to: understand the benefits that come with implementing inspections, understand the steps to rollout an effective inspection process, how to anticipate the problems that can be encountered during an inspection rollout, and learn the importance of monitoring to maintain effective inspections. This paper also details system inspection definitions.
Conference: STAREAST 2003

This Content is Accessible by PowerPass UsersCONFERENCE MATERIALS: Traps That Can Kill a Review Program (And How to Avoid Them)
Author(s): Esther Derby, Esther Derby Associates Inc
Summary: Technical reviews have been around for a long time, and they're generally recognized as a "good thing" for building quality software and reducing the cost of rework. Yet many software companies start to do reviews only to have the review program falter. So the question remains: How can you succeed with a review program? Management support and good training for review leaders is a good place to start. But it's the details of implementation that truly determine whether reviews will stick, or they'll fall by the wayside. Esther Derby offers her insights based on observations from both successful and failed review programs.
Conference: STARWEST 2002

This Content is Accessible by PowerPass UsersCONFERENCE MATERIALS: Automating Reusable Test Designs
Author(s): Robin Goldsmith, Go Pro Management, Inc.
Summary: Vendors and gurus agree that having a structured testing methodology is key to gaining maximum advantage from automated testing, but what this means in practice isn't always clear. One of the biggest potential paybacks comes from the ability to automate tests based on reusable test designs, which can be a key benefit of proactive structured testing. In this interactive session, Robin Goldsmith describes how to develop reusable test designs that can be automated to start testing sooner and run more tests in limited time.
Conference: Test Automation Spring 2002

This is Free Content Original
ARTICLE: Passing the Buck
Author(s): Allen I. Holub
Summary: One way object-oriented systems address the maintenance problem is by using "implementation hiding." Clients of an object shouldn't be dependent on its inner workings--they should only have to know how to talk to it.

Date Posted: Sep 30, 2008

This Content is Accessible by PowerPass UsersMAGAZINE ARCHIVE: The Trouble with Derivation
Author(s): Allen I. Holub
Summary: This article discusses the dark underbelly of derivation: the fragile base class. It's possible to modify a base class in such a way that, even though you've improved its implementation and all your tests work just fine, you've nonetheless damaged the derived classes, perhaps fatally.
Type of Article: Dept: Code Craft
Better Software Issue: April 2009
Date Posted: Mar 30, 2009


Sort by:   Date Posted  |  Title  |  Content Type  |  Relevancy

Viewing 1-10 of 4191 
Collapse Descriptions

Viewing Item 1 of 4191


A StickyMinds.com Original
Article Picture
Keeping a Project Journal
A Key to Personal Growth

By Lee Copeland

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: If you think that keeping a journal is only for adolescent girls, read this week's column by Lee Copeland. Among other things, he suggests that a project journal helps you stay organized; teaches you what not to do next time; and makes it easier to explain what went wrong in a troubled project when you have to defend yourself. He also gives tips on being a good recorder.


MKS
Yesterday I was helping my youngest son, Rajan, with a report on John Muir, one of the first environmentalists. Remembering a journal of Muir’s I had read many years ago, I dug through dusty boxes in my basement to find My First Summer in the Sierra. It is Muir’s record of his experiences as he first explored the magnificent Yosemite Valley in 1869. As I read passages to my son I remembered journals that I have kept—project journals—that recorded my experiences as I worked on various projects. I’d like to suggest that you too should keep project journals.

Why keep a project journal? I can suggest a number of reasons:

  • Remembering. By recording in my journal, I have all the information in one place, nothing gets lost, and it is organized.
  • Evaluating the project. Often we will be called upon to evaluate some part of the project’s activities or deliverables. Your project journal will be filled with the details that make an accurate evaluation possible. Rather than having to depend on anecdotal evidence (I call them "campfire stories") we will have real data to use.
  • Evaluating ourselves. In order to grow we must change. In order to change we must establish a new direction. Your project journal will be an amazing source of data for your own self-evaluation and improvement.
  • Protecting. When involved in a troubled project, you may find yourself in a round of "Place The Blame." At this point your journal may have great value as a contemporaneous record of what transpired earlier. Many people may be very interested in what you have written. It may save your skin (and other important body parts).

Once you commit to keep a journal, the basic question is what to write. I use an approach derived from Virginia Satir’s Interaction Model:

  • First, I record what I saw and heard. I try to capture the event exactly—word for word, scene for scene, with no embellishment or evaluation on my part. As Joe Friday on Dragnet used to say, "Just the facts ma’am. Just the facts."
  • Second, I add my interpretation and understanding. If the meaning I attach to the event is different from the exact words and actions I observed, I write my interpretation in my journal. I also consider whether this interpretation is mine alone or if others would have the same interpretation.
  • Third, I add my feelings about what has transpired. Yes techies, it is okay to have feelings about things. I once worked for a man who said, "Feelings are facts to those who have them." In my youth I thought that bit of sloppy thinking was nonsense. Now that I am much older and a little wiser it makes perfect sense. Our feelings influence us in the same way our facts do.
  • Fourth, I record my response—what I said or did at the time. Again, I note exactly what I said and did. If I meant to give a different response I note that also.
  • Fifth, I note my feelings about my response. Was my response appropriate? Was it too sharp? Too judgmental? Too passive? Not only is it okay to have feelings about our responses, it is vital to evaluate them. Our feelings often give excellent guidance about the appropriateness of our responses.

Later, as I put Muir’s journal back in the box in the basement, I noticed a project journal I had written a few years ago. As I thumbed through it, these passages caught my eye:

10 Feb
Is there a use case model? (No)
Is there a list of actors? (No)
Can we meet with the developers to discuss some questions we have? (No)

15 Apr
Downloaded the latest build from the configuration management system. It won’t even compile. A number of files are missing.

26 Apr
Development has announced that source code will not be turned over to testing because it "previously appeared to have created some confusion." What that means is that when we saw how bad it was and said so publicly, it embarrassed development.

29 Apr
THE DATE SLIPPED A YEAR!!
What we all knew was finally admitted by management.

26 May
That’s it. I’m done. My three months of consulting are up. I’ll miss my apartment on the beach. I can’t say the same about this project.

Remembering this project, its successes, its difficulties, and most of all the friends I made, I smiled, put the project journal back in its box, and walked back upstairs.

Reference
Satir Model: Family Therapy and Beyond. John Banmen, Jane Gerber (Contributor), Maria Gomori (Contributor), Virginia M. Satir. Science & Behavior Books; ISBN: 0831400781; (July 1991)



About the Author
Lee Copeland has more than thirty years' experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. He has developed and taught a number of training courses focusing on software testing and development issues based on his experience. Contact Lee at lcopeland@sqe.com.

Back to Top
 

StickyMinds.com Weekly Column From 10/28/02 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Jeremy Singer 10/6/2004

I use my journal as a scrap book. Important emails (or parts of them) configuration info, anything that needs to be kept track of. Things that I need to have constantly available, I put at the end (important contact lists, ip addresses, etc.) My name and contact info is in the front, in case I leave it in the rest room (at least I have a chance getting it back.)

 
 
Comment:    
by Michelle Crouan 11/1/2002

It has over the past few months frequently crossed my mind that I cant remember everything and that I should keep some sort of diary or 'journal'. My intention to do so has been marred by a) remembering to do it, b) concerns over the time I would spend and c)what to actually put in it that would be beneficial long term. After reading this article it has only strengthened my thought that I should start a journal. Having to make quick-fire decisions that frequently come back to haunt me and not being able to record the detail or what I was thinking at the time has caused some concern for me, even though it hasnt yet been an issue. One...Read On

Author's Response:
11/1/2002    
As the shoe folks say, "Just do it."

 
 
Comment:    
by Ann Godfrey 10/30/2002

I have just finished a four month course which introduced me to keeping a journal. I found it invaluable, not specifically for the technical aspects of the learning, but for recording my reactions and feelings about items. I revisited my previous comments after about a month each time and added notes on how I could have done things differently. I've continued with the journal on projects I've been working on, and find this an excellent media for remembering things which happened and how I (and other people) dealt with them. Formal project notes will record the processes/standards and systems progress, but won't necessarily provide the...Read On

Author's Response:
11/1/2002    
Ann, thank you for the unsolicited testimonial. Your word "invaluable" rings true to me. And your process of reviewing your journal entries after a period of time and considering what you might have done differently is a key to personal growth. Thanks.

 
 
Comment:    
by edA-qa mort-ora-y 10/30/2002

There are situations where a journal is probably not needed. In our environment almost all details and comments are already tracked, a journal would not add much more: we use version control for all our documents, with history notes; primary QA activity uses a time log tracking major areas of activity; deployments and test builds are recorded; all of defects, feature requests, and review points are tracked in an issue system (timestamped); our requirements allow immediate commenting, along with date entry; the fault analyis has the same feature; assets used for testing are stored and dated; email history is archived; meeting minutes are...Read On

Author's Response:
10/30/2002    
You've mentioned many important project documents that you control. I'm suggesting journals as a way of recording personal decisions, responses, feelings, ideas, etc.

 
 
Comment:    
by John Daughety 10/30/2002

A couple of thoughts on this article: 1. This is an excellent idea I had never applied to software testing, although I was religious about this when I was a member of a strategic planning meeting that negotiated contracts and mergers. I also thought of the time it would take to write a journal entry every day. One other means of recording this information could be a small dictation recorder. They are inexpensive, as are the tapes, and I can still talk much faster than I can type. The only real danger is getting carried away with the dictation. 2. Cem Kaner could address this much better than me, but what is the danger that a...Read On

Author's Response:
10/30/2002    
Cem,Can you enlighten us further on the risks of personal journals?

 
 
Comment:    
by Srinivasan Desikan 10/29/2002

Keeping a project journal really helps. Couple of instances I could remember that helped me in the past; 1. When I got NCR (Non comformance report - ISO 9000) for not following the customer accptance of req. to proceed with the project, I could pull out what customer said in the telecon that he was not serious about this and he would send it when required. When quoted this I was able to satisfy the auditors and subsequently get the email from the customer. This happened in 1994. 2. I left my previous organization but I got a call from them saying one of my past customer didn't pay for the project 3 years back and they came to know...Read On

Author's Response:
10/29/2002    
Thanks for your excellent comments. I'm glad a journal helped.

 
 
Comment:    
by Cem Kaner 10/29/2002

This is important advice, but it is important to learn (before you start keeping the journal) whether your notes will be private or public. Most software employment contracts would treat these journals as corporate property, which means that your manager, and other executives, can read them. One of the important prerequisites to success in PSP (Personal Software Process) is buy-in from management that programmers' journals will be their private property, never subject to inspection by anyone else. I suggest that you get a written agreement from your manager that the journal will be treated by the company as private, and never open to their...Read On

Author's Response:
10/29/2002    
Cem has an very important comment and one I hadn't considered. Thanks Cem.

 
 
Comment:    
by Fabrizio Stortoni 10/29/2002

I think that a journal is as useful in a well run project as it is in the type of situation that Lee describes. There will always be deviations from plan as circumstances change. If your process includes a test summary document at the end, it is almost impossible to create a good one if you haven't been taking notes along the way. And even when you have access to programmers who answer your questions, you need some place to record their answers. I started keeping project journals early on in my testing career, and at first I thought of it as a secret shame, a crutch that real testers shouldn't need. But it helped me, and I met other testers...Read On

Author's Response:
10/29/2002    
Fabrizio, thanks for your comments. I think you will find the idea of recording feelings very useful.

 
 
Comment:    
by Andy Dent 10/29/2002

Keeping one project journal is a good start. My superlite software process involves keeping separate journals for different reasons. The most important is the Design Decisions Diary which describes the alternatives considered and reasons for rejecting them, in succinct form, for each decision made as you work. Examples and more rationale at http://www.oofile.com.au/adsother/sse.html

Author's Response:
10/29/2002    
Thanks for this suggestion. I always considered things like a Design Decisions Diary as part of project/product documentation while I considered a journal as personal reflections but I agree that both are useful.

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Avnet

HP Software




STAREAST 


Better Software Conference