Welcome to the Programmers Pledge web site

The programmers pledge is an idea/tool to encourage developers to improve code quality.  My original blog post about the idea is here: http://csharpdeveloper.wordpress.com/2011/01/09/a-programmers-pledge-to-quality-assurance/ .  Some people consider programmer pledges to be very similar to coding standards.  And they are.  But the purpose of creating this as a pledge is to encourage the desired behaviors using a different tactic.  To encourage people to work overtime we can either threaten to fire them, or we can pay them double.  Likewise, to encourage well-written code we can document coding standards, or ask developers to consider a pledge.  Personally, I don't think this pledge should be signed, or agreed to in person.  I simply think it should be a list of items that any programmer, in your development environment, would agree to for personal reasons.  A programmer that does not adhere to the coding by the rules in the pledge is basically admitting that they are not very good at programming.
I have created some discussion groups to welcome feedback on my initial list and to obtain additional ideas for items that you feel should be included on a list.  I believe each development shop should create lists specific to their environment (hopefully by borrowing heavy from ideas here and on the forums); and that each development shop should devote an hour or two to discussing all the ideas on the list relevant to their environment. 

Pledge to QA (original blog post):

I recently took some time to review the list of bugs we completed in the last year. I noticed that the majority of bugs found during development and entered into our tracking system were similar to this list:

  • “Change the dropdown list to be sorted…”
  • “Change the fields on the form to have the correct tab order…”
  • “Change the fields on the form to move and resize appropriately if the form is resized”
  • “Change this to be spelled correctly…”
  • “Change … to be consistent…”

Each of these items takes time away from our development in many ways:

  • for a tester/QA to recognize it,
  • for a tester/QA person to record it,
  • for a development team member to confirm it,
  • for a development team member to assign it a priority,
  • for a development team member to assign it to a person to fix it,
  • for the assigned person to make the change,
  • for the assigned person to mark it complete in the tracking system,
  • for a tester/QA to retest it after the next build  for a tester/QA to mark the item as done.

That is a lot of Project Management for items that are just the result of sloppy programming.  We should strive to reduce these cosmetic “bugs” from ever being included in code that is “ready to test”.

Here is my idea.  Create a pledge that a programmer makes to QA because these are not the kind of “bugs” that QA should need to waste time on testing and tracking. I don’t think this pledge should be formalized and signed by each developer. I hope that it motivates programmers to pass code along to QA only after it is free of cosmetic bugs.

Our team held a meeting to discuss the items on this list. I was surprised that there was little agreement about any items, even items I thought would be non-controversial such as sorting listboxes alphabetically by default. I only led the discussion, I did not try to dictate or persuade, and in the end, after much arguing back and forth, most our of programmers did come to accept most of the items on the list as best practices. I provide our list as a starting point. I hope you can suggest other items to add to it. I realize that this list is very similar to coding standards, but by phrasing it as a pledge, I hope to increase the adoption of these tenets.

Expectations from developer (I pledge to):  (This is a pledge a programmer makes to QA because these are not the kind of “bugs” that QA should need to waste time on testing and tracking)

  1. The code will not error right away for all users when they try to run it
  2. The messages visible to users will not have any misspellings
  3. The tab order on forms will be correct (reasonable)
  4. The first field to receive focus on forms will make sense (be optimal)
  5. When a form is resized, controls should move or resize appropriately
  6. Form colors should be consistent across forms.
  7. Form elements (button captions and placement) should be consistent across forms.
  8. Keyboard shortcuts should be consistent per policy
  9. Form icons and captions, including popup messages should be consistent.
  10. Don’t ask testers to start testing until all these above items are correct.
  11. Captions will fit on buttons, text won’t get truncated on screen.
  12. Code runs fast
  13. When you run my code, I would be surprised if you can find any “syntax” errors such as cases where null values were not handled
  14. If an error does occur, it will be gracefully handled with a user friendly message and helpful debugging details will be logged.
  15. If there are any conditions/scenarios I have not tested, I will let you know what those are. (I didn’t test on Vista, or against Oracle db)
  16. Error messages will be complete sentences.
  17. All data in lists will be in alpha order

Pledge to other programmers:

I pledge to write code that:

  • is so intuitive that anyone can follow the logic; but if the code must be complicated, it will be clearly documented.
  • has low cyclomatic complexity.
  • has a full set of unit tests around it.
  • has no more than 40 lines in a method, and averages less than 10 lines per method.
  • uses correct names and not temporary variable names like asdf.
  • use professional business names in all code that could be visible to clients or other developers using our API instead of names like StupidRoutineToMakeThisWorkRight.
  • does not break the daily build.