Home | Login | Recent Changes | Search | All Pages | Help

NotesFromSessionThree012

also known as EffectiveHabitsofSoftwareDevelopment Shared Approaches from Session Led by Jerry Weinberg, Nov 3, 2003

1. �Memorizing� = Understanding the code, visualizing its structure

   - compare vision to reality, gives insight on where bugs are
   

2. Daily Team Meetings, 10 minutes, share approaches and issues

   - get team help on handling problems
   

3. Talk to individuals on team, develop relationships

   - ask: how are things going?
   

4. Show appreciation, reward success and milestones

   - include customers when working together on team
   - public rewards build teams, identify what is working
   

5. Get away and exercise during lunch
6. Awareness of emotional health on team

   - listen to the music of what�s going on
   

7. Build conformance test of code, enforce standards

- identify style problems when checking code in - rigid standards don�t work, creative people will circumvent

- �Be Reasonable� and establish conventions or guidelines

8. Establish personal plan for what needs to be done today

- achieve balance of hard and easy tasks, - don�t postpone hard tasks until they�re all that�s left

- do �session planning�, keep a log, review it for insight

9. Avoid over committing
   10. When someone is reacting defensively, agree with him, �you�re right�

- diffuses tension, saves time, can get back more quickly to solution

11. Do more 1-on-1 (interpersonal) meetings, be informal, in work area

- avoid non-useful team meetings

12. Be able to explain problem and solution to someone non-technical
13. Give opportunities to vent, listen well, be available but limit dumping

- ask if the person needs sympathy or solutions

14. Use focus to handle crises but don�t be frantic

- make lists, correctly frame the problem

15. Know when you�re being productive

- you�re not productive if a lot of re-work is needed

16. Confirm your understanding of problem

- encourage debate, don�t take criticism personally

17. Keep notes in a project notebook, consolidates activity in one place

- Review, identify what was committed, check off when complete - include diagrams and post-its to rearrange ideas when brainstorming

18. Identify patterns by doing retrospectives
19. Visible success can lead to staff loss, so do �Stealth� Projects

- or, consider as positive, ie. �seeding� of other projects for influence

20. �Budget� for failure because mistakes have a cost
21. Have QA review of Requirements and Specs, are they understandable?

- especially needed when project is geographically dispersed

22. If team is working late, be there or be available, buy the pizza
23. Know your business, be specific about what is needed

- identify where assumptions are being made - don�t assume that anyone�s contribution is easy

24. Build relationships, treat as invested time, will result in trust
25. Hire talented staff with background in customer�s business

- try not to lock staff down, allow growth & transfers to customer areas - will establish credibility with customer

26. Do internal seminars (brown bag lunches), provide food, share ideas
27. Reimburse staff for technical/topical books they purchase and read
28. Evaluate complexity of problem, do triage when there are many

- if problem is ultra-low (30min-2 hours max), allow customer walk up

for immediate service (in and out)

- sample results could be ad-hoc report, advice and alternatives

29. Practice your solutions and plans, obtain experience before implementing

- experiment and learn from it

30. Do �walkabouts�, get away from your desk, return refreshed
31. Try to verbally greet everyone on team every day

- if you can�t because of bad mood, ask for help

32. Manners work, make people comfortable
33. Build self-documenting applications by planning early

- anticipate the effect on customers/end-users - have team step into customer�s shoes, roles

• Good or Bad Habbits -- diner with the family (and what is the value of what you are doing
• Super Here syndrome -- do the wrong thing for the wrong reason
• Memorize code (Jerry Weinberg) and 'see' where you do not remember -- that is where there may be a problem in the code
• When hiring my entire team joins me in a group interview
• Rita test (but you do not need Rita): describe difficult problem to Rita -- if I cannot describe problem, I do not understand it -- If I cannot describe solution, I do not understand it
• Session planning: write what I accomplish, write steps expected to be needed, follow the steps unless there is a point where they are found not to be as expected -- this is good for self, good to explain problem to others and good for manager/mentor to discovere where a problem lies
• if you perceive in yourself (or others) confusion about how something works, post your interpretation in a public place
• be aware of your creative state/energy level of clear thinking -- adjust what you are working on etc. accordingly
• give appreciation (including self)
• Scrum technique -- daily meeting, raising problems
• comprehensive project notebook
• write and use patterns
• project retrospectives
• focus is a substitute for time
• do person to person with developers
• chose when not to code
• great everyone verbally everyday
• try to find time every week to drop by the labs -- places where staff and students work
• every day try to do something interesting
• once a week try to do some big piece of work, something creative
• be careful about making a good project visible -- might be cut to pieces... or made just different enough to turn into a problem
• automated conformance testing framework
• listening to the music (with others)

Contributed by MartineDevos based on cards I collected

Contributors:

MikeMelendez 2003.11.07

Jerry: memorize code, attempt to reproduce

• sharing problems at team meetings
• listen to problems, connect people
• developer talking to Acceptance test writers
• give appreciation
• exercise, physical exercise
• focus on own and team emotional state
  • listen to the music of what's going on
• simplify test entry

Jerry: Standards

1. Be reasonable
2. Provide two alternatives
3. If nobody's doing it, it's not a statdard.

Jerry: Watt Humphrey's PSP screws up a good idea because it requires all to be the same.

• base work choices on personal state
• keep work log, especially of time
• talk to simple truths
  • but avoid autoimmune reactions

Jerry: To calm an insistent talker, tell them "You're right." Ask "What is it you want?"

• management one-on-ones weekly
  • person-to-person
  • subordinate sets agenda
• explain a proposed solution to an uninvolved party
• remember to focus, i.e. refocus on the right thing
• don't code when you can't -- know that such times exist
• broadcast (mis)understanding to public forum
  • they will correct you
  • don't take the correction personally
• capture lessons learned in a single place
• retrospectives, patterns
• avoid too much visibility -- the flatworm theory might be applied
• encourage teams to fail on occasion

Jerry: I maintain a failure budget for each person who works for me, including me.

• get external feedback
• make yourself available
• make every requirement unambiguous
• establish relationships with people you want to influence
• hire people who understand business better than endusers
• let people grow, even out of your hire
• read a shared book -- discuss it in techno lunches
• fund books for personal ownership if read
• call a learning exercise a practice session
• be aware of don't-ask-don't-tell
• recognize others -- greet them
  • start with someone who knows you to improve mood
• imagine limited access customer failure, design accordingly

Additions from my notes:

• Use an interrupt (Jerry's watch, which is really an alarm clock) to keep focus
• Warning signal while coding - patching initial write of code
• Broadcast your flawed understanding - those who know will correct you
• Keep all project stuff in one notebook
• Aim to fail regularly. Have a failure budget (I love this idea)
• Envision experiments, not prototypes

My notes are on my page (IzaakAlpert), would they be better here?

Yes, please, Izaak. That way we can compare and fill gaps in each other's notes. MikeMelendez 2003.11.11

Jerry, would you please describe a "failure budget." I have not heard of this term. What does it mean and how do you use it? What affects have you observed from it?

DwaynePhillips 14 November 2003