Category: project management

Total 11 Posts

Douglas Crockford – Quality

A coworker pointed me to the following video: Quality Software Development by Yahoo Architect Douglas Crockford (181 MB). The presentation from from the Yahoo 2007 FrontEnd Engineering Summit (March 7-8, 2007).

Below are my notes of the slide titles.

  • The Software Crisis
  • Craft vs Engineering
  • Computer Science has not taught us how to manage software projects
  • Software Construction (Good and Bad Analogy)
  • Nature of Software
  • Programming is Difficult
  • Lack of Metrics
  • Lines of Code – not good
  • Programmers are optimists
  • Programmers do not understand how they spend their time
  • Actual time typing is pretty small
  • Skeptical of anything that requires more keystrokes
  • Programming is a social activity
  • Cost of Innovation
  • Legacy
  • Leaps (of productivity? software capability?)
  • Object Oriented Programming (History)
  • Failed Leaps
  • Software does not have enough self awareness to be afraid of bugs
  • Bugs
  • Snake Oil / Silver Bullets
  • Mythical Man Month (1975)
  • Literate Programming (Knuth)
  • Significant difference in individual ability
  • Surgical Team (Harlan Mills)
  • Incrementalism
  • Beta (Perpetually Unfinished)
  • Application triad (skill, technology, requirements)
  • Feature Cost
  • Code Value
  • Code Quality (Micro and Macro View)
  • Simplest thing to enhance value of codebase – make more readable
  • Yahoo Javascript coding convention
  • Programs are a medium of intentional communications
  • Good architecture – necessary structure to keep from collapsing
  • How do we change a correct program into another correct program?
  • Cruft – “Software Scar Tissue”
  • Causes of Cruft
  • Bloat – “Software Cancer”
  • Insecurity
  • Cruft accumulates -> complexity groups -> progress slows
  • Refactoring
  • Sometimes it is best to start over
  • The pain of the crash
  • The illusion of completion
  • An experienced team can cross that ground again very quickly
  • Conclusion


Standing Agenda for Weekly Distributed Team Meetings

I am not currently managing any distributed teams. However, I used to and we always struggled with effective team meetings. Through trial and error we came up with the agenda below. This was a waterfall project and the agenda reflects that.


  • What modules are completed ready for handoff to QA?
  • What modules are expected to be completed this week?
  • Proposed changes to code already handed off to QA (refactoring, new features, non-QA generated bug fixes, re-organization of repository, etc.)
  • Any additional tasks that have been identified
  • Current target milestone date(s) – reason for delta (if any)


  • What modules has testing been completed?
  • What modules are expected to be tested this week?
  • Any blocking issues or high priority bugs outstanding?
  • Any additional tasks that have been identified
  • Current target milestone date(s) – reason for delta (if any)

Current Open Topics From Past Meetings

  • First item
  • Second item
  • etc.


Jason Fried of 37Signals – Business of Software 2008

One of the things I love is being able to see presentations from conferences I was unable to attend. A coworker passed on a link to this video (55 minutes) from the Business of Software conference. In the talk, Jason Fried of 37Signals, makes of Ruby on Rails and Basecamp, speaks on many aspects of running a software company and keeping teams working effectively.

Here are some of the slide titles, topics and items Jason discussed:

  • Planning is vastly overrated – no roadmaps, specifications, projections. Get rid of distractions. Functional specification does not reflect reality and leads to an illusion of agreement.
  • Decisions are temporary – optimize for now
  • Red flag words – need, can’t, easy, everybody, nobody. These are the words that cause projects to be late
  • Interruption is the enemy of productivity – the closer the team is physically, the less you get done. Interruption is not collaboration. A fragmented day is not a productive day.
  • Underdoing – target non-consumption
  • Find the right size – imagine the software as a physical item
  • Follow the chefs – what is your cookbook?
  • Always be questioning – Why are we doing this? What problem are we solving? Is this actually useful? Are we adding value? Will this change behavior? Is there an easier way?
  • Give up on hard problems – there is an abundance of easy problems
  • You’re an editor – Curate your product. Say no to more things than you say yes.
  • Work Less
  • Q&A – Starts 28 minutes into the video

An enjoyable video, especially the first half before the Q&A session.


FDD – Interview with Jeff DeLuca

Feature Driven Development (FDD) is one of the agile methods I think does not get enough attention. In particular, the principles of FDD – as they impact project management -are very useful in agile and non-agile environments. The book that I used to learn about FDD is A Practical Guide to Feature-Driven Development by by Stephen R. Palmer and John M. Felsing. This book has a good description of FDD but is weighed down with a specific modeling approach.

Recently, Software Engineering Radio had an interview with Jeff DeLuca, one of the creators of feature driven development. I found it to be a good introduction to the topic. However, for a practitioner of FDD there will be nothing new here.


Agile Practices that Tend to be Problematic

As I have mentioned before, I attended a breakfast talk by Steve McConnell ( entitled “Legacy of Agile Software Development”. During the talk, Steve skipped over the section of the slides labeled “Agile Practices That Tend to be Problematic”. I grabbed the slides after the presentation to see what he had to say.

Note: Steve is not necessarily saying these are bad — just that the teams his company has evaluated, these practices have not provided the value that they promise.


  • System Metaphor – Least understood practice
  • On-Site Customer – Difficult to achieve
  • Collective Code Ownership – Uneven code quality and sometimes results in lack of ownership.
  • Pair Programming – Sweet spot between junior and senior programmer
  • Refactoring – Good practice whose name is used to cover up bad behavior

Lessons from Improv

Last week, I attended an ASQ dinner meeting where the speaker was Izzy Gesell ( The title of the talk was “Tools for Transformation”. I think I would have named the talk “Lessons from Improv”. Izzy is a former improvisation artists and he applies the lessons and techniques from improvisation to the business world.

Izzy’s talk was dynamic and interactive. I took away 3 items which can be applied to a software (or any other) team:

  1. Acceptance – Accept what is given and move forward
  2. Focus – Concentrate on the essential
  3. Trust – In the process and the people

The idea behind acceptance is instead of complaining or trying to change the unchangeable, it is more productive to take what is given and move it to the next level. This does not necessarily imply agreement. Concentrating on the essential – Focus – I believe is a key attribute of all the successful teams I have been a part of. In the case where the team was not performing well, a lack of focus was definitely a component. And finally trust. Once again, the best teams operate in a an environment of trust.


Personal Worklog

Years ago, I was stuggling to meet all of the committments I had made. When discussing this with my manager, he suggested keeping a log of what I did each day for a couple of weeks to identify items that I could eliminate or postpone (or now that I manage others – delegate). The exercise was useful and got me through the commitments. I then promptly forgot about it. Some time later, I was in a similar situation and started to keep the log. This time, I made it into a habit. Since then, I have kept a simple work log at my last 3 companies.

It is a simple format:

Date      * Description of what I did
Date      * Description of what I did
Date      * Description of what I did

No more than a line for each item. (The details can always be found in my engineering notebooks, wiki entries, source code control comments, bug reports, etc.) At the end of each week, I archive that week’s log and start a new one. I review the prior weeks log when I file my weekly status report. At longer intervals, I will review larger blocks of time.

The work log has helped me numerous times. It is especially useful when I need to answer questions like “when did we do A, B and C?”

I am currently in the process of moving out of my current position. One of the first things I did was review my work logs for the last 12 months and identify

  • What types of items should my replacement do?
  • What should be delegated to existing team members?
  • What items do I need to discuss with my boss about who should take on these duties?
  • Without these logs, I am sure I would let something slip through the cracks. This is definitely a habit that has been useful and that I will continue.


    Personal Status Reports

    Over the years, I have seen many forms of status reports used by my team and the teams I have worked on. (I am distinguising these reports from those used for project status. Often, there may be corporate standards or contractual requirements associated with them.) I have settled on the following format which works well in a variety of submittal formats (email, word document, wiki, etc.):

  • Notes
  • Highlights
  • Lowlights
  • Plans
  • The notes section is optional. It is used as a reminder of upcoming items or circumstances that the manager should be aware. I have used it to record upcoming vacations, travel plans, customer visits, release dates, milestones, etc. This section often spans multiple reporting periods. The highlights section enumerates those items that went well during the reporting period. These are just bulleted lists – not a lot of text. The lowlights section are those things that did not go as planned. Once again, it is just a list of bullet points. The plans section lists what the individual intends to accomplish in the next reporting period. If this information is captured elsewhere, say in a project plan, then just reference it.

    I use these reports in two ways. The first is in my regularly scheduled one-on-one meetings. I review the status report beforehand. (I am opposed to receiving both written and verbal status.) I make notes of those items I need more information on – these are usually the lowlights. I encourage my staff to include items in their reports that they want to discuss with me. The second way I use these are during performance reviews. This is especially useful in countering the “recency effect” – only remembering what has happened in the last 1-2 months. Unfortunately, it is usually the details of the good things I forget, so I review the highlights sections in detail for the last year. I only look for trends in the historical lowlights.

    I have used this format consistently over the last 3 years. As an organization, we have tried collecting different information or collecting it in different ways but I keep coming back to this format.


    Pragmatic Programmer Tips for Non-Programmers

    I finally got around to reading The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. While an excellent book for programmers, I believe that it is equally useful for testers (both doing automation and doing manual testing), project managers and technical writers.

    In particular, I think many of the traits described in the first section of the book are as valuable (or maybe even more valuable) for non-programmers. The following tips leaped out at me as traits that should be shared by all team members:

    Tip 1. Care About Your Craft
    Tip 2. Think! About Your Work
    Tip 3. Provide Options, Don’t Make Lame Excuses
    Tip 4. Don’t Live with Broken Windows
    Tip 5. Be a Catalyst for Change
    Tip 8. Invest Regularly in Your Knowledge Portfolio
    Tip 9. Critically Analyze What You Read and Hear
    Tip 10. It’s Both What You Say and the Way You Say It
    Tip 11. DRY – Don’t Repeat Yourself
    Tip 27. Don’t Assume It – Prove It
    Tip 46. Test Your Estimates
    Tip 56. Start When You’re Ready

    Some of these tips require explanation. Please see the book for details. It is my belief that if every team member acts in these ways – regardless of position or seniority – then the team will be much better for it.


    Extraneous Document Text

    I have been looking at standardizing some document templates for various software artifacts. As I review these things, there are several items that annoy me. As I think about it, I think the difference comes to how the documents are viewed (and in particular whether they are handled in hard copy vs. looking at them online).

    Typical documents I see look like this:

  • Title Page
  • Revision History
  • Table of Contents
  • Bunch of standardized boilerplate text mixed with the content I am interested in
  • Many times, I need to page through 3-5 pages before I get to the information I am interested in.

    Title Page: In a printed document, this may or may not be a nice touch. However, generally, it does not add significant value over just a title, author and update date at the top of the first page of text. Whether to include a title page or not in the printed document is a question of your audience. In an electronic document, this is text and whitespace that must be skipped over to get to the “meat” of the document.

    Table of Contents: If I see another 3 page document with a table of contents, I think I will scream… My general rule for printed documents is that a table of contents is useful once the “meat” of the document is over 10 pages. In an electronic document (where I have full text search), I want the table of contents to be hyper linked enabled so I can use it as a navigation tool.

    Boilerplate Text or Background Info: In a printed document, it is a matter of preference. In general, I prefer background information on a project to be kept in a separate document that is referred to in the main document. However, this may make using the printed document unwieldy if the reader needs to shuffle between multiple documents. In an electronic document, I want the background information to be a link to the definitive source. It is easy for me to skip over and if it changes, there is only one location that needs to be updated.

    Boilerplate text is often seen in document templates. These are usually instructions for how to use the template or perhaps generic text that describes corporate policies or procedures. This text may be useful to a new employee or someone who is using the document for the first time. However, after that initial experience, this is text that most people will skip over and generally ends up wasting space. If instructions are needed or a reference to a procedure needs to be included, make it a reference (or link) to another document.

    Revision History: Some documents include a detailed table of every change made by every person ever in the history of the document. While this is valuable information, I consider this document meta-data rather than content of the document itself. I would prefer to see this data stored in the version control or content management system rather in the body of the document. That being said, it is nice to have some version identifier in the document (perhaps in the header or footer) to distinguish between versions.