Two screens are bad? 3

Posted by steve on February 01, 2009

In the last meeting we had an interesting presentation/discussion on the Joel Test: 12 Steps to Better Code led by Julian Harley.As expected, some of the ideas were accepted by all, but a surprising number were contentious and threw up some good debates: (Apologies if my memory don’t match your recollection of the evening, I’ll blame the holiday I’ve just been on and the copius of amounts of saki which my parents-in-law forced me to drink. :) My fuzzy memory summarised the discussion as follows: 

  1. Do you use source control? Heck yeah! All agreed it is crazy not to do this.
  2. Can you make a build in one step? All agreed.
  3. Do you make daily builds? Daily builds were viewed as an absolute minimum and continuous integration and immediate builds were preferred.
  4. Do you have a bug database? All agreed.
  5. Do you fix bugs before writing new code? It depends. If a bug is found by the developer then it should be fixed, but we wouldn’t drop all our plans just because a bug was reported. The bug should be viewed alongside the new features to be developed priorities should be chosen (ideally by the client).
  6. Do you have an up-to-date schedule? Again, it depends. How detailed should a schedule be?
  7. Do you have a spec? Mmmmm. Once more, it depends. Everyone felt requirements were important but there was discussion about what level they should be and I can’t say a consensus was agreed upon.
  8. Do programmers have quiet working conditions? It was generally felt that there needs to be a balance between an environment which allows for osmostic communication so the team can benefit from the spred of knowledge and one which allows for quiet so the developer can concentrate.
  9. Do you use the best tools money can buy? This one was hard to pin down. Some people argued that not providing two screens for a developer should be a crime, whereas some argued that having two screens can be distracting and they often preferred just one screen.
  10. Do you have testers? All agreed.
  11. Do new candidates write code during their interview? Again surprisingly for me, this one had more discussion than expected. Some argued that judging people by a small coding sample could be unfair and too much emphasis was placed on this.
  12. Do you do hallway usability testing? All would like to follow the agile practice of having a customer or a proxy in the team so that we could have even better feedback than a random passer-by.

The discussion then focused on what we felt could be added to the list:

  1. Documentation was high on most people’s list but we found it hard to agree on exactly what kind of documentation.
  2. Collaborative aspect/tool. Something as simple as a wiki is often beneficial so that the team can record plans/discussions/decisions etc.
  3. UI designer. Having the app being designed by trained people instead of being designed by developers who think they can design a UI.
  4. Client presence. As mentioned in the final point, we felt that having a client or proxy see work as it is being developed was of great benefit.
  5. Automated Testing. Well we are agile after all :) Currently you can follow an interesting discussion between Joel Spolsky (and Jeff Atwood) on their stackoverflow podcast (#38 and #39) versus Uncle Bob Martin about automated testing. Hopefully Bob will appear on the stackoverflow podcast next week to sort out Joel and Jeff. [If you’re looking for a good podcast, the stackoverflow podcast is usually good (even though they can’t get the TDD idea!). I’ve also enjoyed the last two Hanselminutes, which discussed Uncle Bob’s SOLID principles and TDD]

Once again thanks again to Julian for hosting a great discussion.