Archive for the ‘Quality’ Category

• Best Links of the Week – Mar 27th 2010

  Date: 2010.04.27 | Category: Agile, Coaching, Extreme Programming, Lean, Links of the Week, Planning, PMI, Quality, Refactoring, Testing | Response: 1

  More good links to share with others.

  1. Ouija Board Estimation\Seance Sizing – a new method for estimation that relies on team, not the undead.
  2. Is the Agile Community Being Unreasonable? – InfoQ takes a look at the friction between the PMBOK and Agile principles.
  3. Toyotas’ Journey from Waterfall to Lean Software Development – Henrick Kniberg takes a visit to Toyota and peaks under the hood to see how a Lean company develops software.  What he finds will surprise you!
  4. Defining the Last Responsible Moment - Karl Scotland puts some meat on this fuzzy Lean concept by looking at the cost vs benefit of delay.
  5. Managing vs. Coaching vs. Mentoring - Jurgen Appelo makes the distinction between these three concepts.
  6. The Problems With Acceptance Testing – thoughtful entry by Jim Shore reevaluating the importance of automated acceptance testing on Agile projects.
  7. Alternatives to Acceptance Testing – more from Jim Shore on what can be used in place of automated acceptance testing.
  8. More on Automated Acceptance Testing - George Dinwiddie adds his perspective to the topic of automated acceptance testing.
  9. The Path to Frequent Deployments – a report from Kent Beck, author of Extreme Programming, on how to  increase development speed by moving from annual to quarterly to monthly to weekly and finally to daily deployments.
  10. How to Be a Great Tech Leader – Richard Kasperowski talks about the technical elements needed to succeed when running an Agile project.

• Pair Programming Might Not Work For You,

  Date: 2009.01.30 | Category: Extreme Programming, Pair Programming, Quality | Response: 0

  … but don’t prohibit other people from giving it a try.

  I heard the MOST ignorant statement the other day while facilitating a workshop.

  “Pair programming is useful when you’re 23.  When you turn 24, there is no need for pair programming.”

  From the tone of the speaker’s voice, I knew this individual was not interested in dialogue.  I also could not let their comment go unanswered and be accepted as a true, so I responded:

  “I have had a different experience and I disagree with you.”

  

  Pair programming – probably the most controversial practice to come out of Kent Beck’s Extreme Programming Explained and continues to remain controversial almost 10 years later.  The practice has evolved over the years, but it is still essentially two people working together at one keyboard solving a code and design problem.  Since I have had such a different experience pair programming, I am not sure why some people have such a knee-jerk hatred for it.  Some of the most productive code and the best designs have come out of my pair programming sessions.  In my experience pair programming is a practice that allows the sum of two programming minds to exceed the individual parts.  

  So where does this resistance come from?  I think much of it comes down to fear – fear that we are not as good as we think and the other person we are coding with will find that out.  As I have heard Ron Jefferies say, “You are not as bad as you think.”  Since I am not a zealot, I will be the first to admit pair programming is not for everyone.  It is an extremely intense shared design experience.  If you are not good at expressing yourself and having your ideas challenged, you will not like pair programming.  If you simply work best by thinking in silence and hammering away at the keyboard until the app is done, then pair programming probably will not be for you.

  However, just because pair programming might not fit your personal style of writing code, that does not mean no one should be allowed to use it.  Let other people try and figure out how to succeed where you might have faltered.  There are a lot of ways to write high quality code and for some people, pair programming is their way of doing that.  Let us have some variation and see what produces the best code before limiting our options.

• Is Code Foreclosure In Your Future?

  Date: 2008.12.12 | Category: Agile Design, Quality, Refactoring | Response: 0

  I want to use this post to talk about the concept of design debt (or technical debt) to describe the variety of “shortcuts” software developers take to compromise design quality in order to gain a short term boost in productivity.  While there may be many good reasons to take these “shortcuts” at the time, from that point forward any future design changes to that section of the code are more difficult, i.e. expensive to make.  In almost all cases, most well-meaning software developers really do intend to return to the code and fix these shortcomings, but due to schedule pressures they rarely do.  The cumulative effects of these “shortcuts” are called design debt and are very toxic to your software.

  Much like credit card debt, a small amount of design debt is acceptable.  Unfortunately, due to the nature of software, if real attention is not spent “paying back” the design debt, eventually the system in question collapses under the weight of its highly coupled design.  I created the list below to help you spot the four stages of design debt in your system, so to avoid a “repo” of your software.

  1. Impulse Buy - Not doing the right thing today or having the attitude of “I’ll fix that tomorrow”.
  2. Late Payments - Adding new features to new code begins to take longer and longer.
  3. Notice of Default - The project stops adding new features to enter a “refactoring phase” or “just a week for clean-up”.
  4. Foreclosure - It simply becomes easier to re-write the system rather than modify it.

  As you get into later half of Stage Three, more and more of your resources go into paying back debt and you cannot extend the functionality of your system to keep up with market demands.  The competitive advantage your software provided the business falls to the wayside as all your time is spent in maintaining a brittle system your customers don’t even like anymore.  Like most ailments in life, the longer you wait to apply a remediation, the more “painful” the cure.  It is far more economical to apply an ounce of prevention, by taking your vitamins in the form of daily refactoring, than wait for the “foreclosure” process to overcome your business assests.