Notes from a fry-up lunch - A System of Names

Today we were discussing the wiki entry by Ward Cunningham on a System of Names

These were the thoughts that we had:

* Sometimes you need a name that doesn't mean anything - like MacGuffin

* The best names are the ones that you've arrived at with others that you're working with.

* Sometimes getting the name right completely changes the way that you think about things e.g. Changing the idea of a file being encrypted to a file being sealed

* Sometimes there's a terrible wrench every time you use a "properly" named object because what the object is/how it's used has changed since you named it. You need to be able to carry on changing the name of things throughout the process. In some languages, this is very difficult, if not impossible (Rails was mentioned as one).

* Ward Cunningham's suggestion that you use a thesaurus isn't a very good one - it betrays a misunderstanding of what language is, how it works. What are you going to use instead of "Master"? "Dominator"? "Dominatrix"?

* The canonical "misunderstanding" cases like "add" and "plus" can't be solved by just getting the right name. They can only really be solved by having some kind of convention of usage. It's not a list of names - it's a system.

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Notes from a fry-up lunch

I had a fry up lunch on Wednesday with a friend of mine who's a developer and two of his fellow developers (he can own up in the comments if he wants to) a few things came up in conversation that I want to note down here - I might write longer pieces on them later.

• Quote: "The two projects that we made money on are the two projects where we said [admitted?] that we don't know". The standard case where the customer comes to you and says "How much for X" and you say Y pounds RARELY MAKES MONEY! But the model where the customer come to you and says "How much for X" and you say "Mmm, dunno. Do you want to pay me a little bit of money to have a look?" THAT MAKES MONEY! Maybe you can't get there straight away, maybe you have to do some fixed price stuff to get to that stage, but isn't good to know where you should be heading?


• A compelling reason for becoming involved in open source is that you get the respect of your peers. You also get coached by people who know what they're talking about. This is very different from the kind of feedback that you get from customers which is all about bugs or things not looking the way that they should. Perhaps pair programming could be a kind of mini, in-house open source in this way.


• Related to this - the loneliness of the self-taught programmer. Most programmers are autodidacts - they teach themselves. This means that some areas are very strong and some areas are very weak. When other people look at their code self-taught programmers can feel very foolish. If you're a self-taught programmer and you're trying to work within a framework which is supposedly helpful to development, such as test driven development, or pattern-based design, this can be very traumatic and cause you to really lose self-confidence. Maybe this is why some guru/surgeon programmers are so reluctant to pair program.