Saturday, January 29, 2011
"Apply the principles that we found out to work so well in small groups - which is what makes small groups so successful, because only in small groups these principles can work - to large projects?"
Whom are you trying to be kidding?
Let me put it another way:
1995 to 2008: 7 plus/minus 2 is the ideal team size because of [the usual arguments]
2008 ff. : 'Agile' works so well, lets just apply it to the enterprise level
Yes I know: the 7±2 team size thing is way older than 1995 - I was referring to usage in the 'Agile' (capital A) community
Tuesday, January 25, 2011
your short term memory is mediocre at best - deal with it.
If you've got a bright idea while you're on the phone, write it down. Immediately.
If you've got an important thought while browsing the web, write it down. Immediately.
If you've got a sudden intuition while you're at the beach, write it down. Immediately.
There is a clever toolset designed for this task - it's called PenAndPaper. No, really using pen and paper has some huge advantages over iPhones, Blackberries, iPads and the like.
- You don't have to leave the application you're working with right now.
- You don't have to search for the application
- You can use it while you hold the phone to your ear.
Oh, and it doesn't run out of batteries and even survives coffee spills (albeit at the loss of some legibility if you keep on insisting on using these antique fountain pens)
Therefore, dear Michael: Get back in the habit of almost always carrying a minimum amount of paper and a pen.
P.S.: But of course putting it down on paper doesn't eliminate the need to consolidate the notes at some place - in your case I wuld recommend something electronic, virtual and distributable. Like a plain textfile. A text based mind map might also be in order as long as it really helps and doesn't come in the way.
P.P.S: Oh, and since you're such a keyboard fan - as long as you're on a 'real' computer and can acces your notes faster via a the keyboard that by reaching for pen and paper (e.g. <Cmd>-<Space>, "Scribbles", <Enter> or <Windows>-<R>, "Scribbles.txt", <Enter>) I guess it's OK to use that instead of paper...
Saturday, January 22, 2011
As much as I like twitter I soon came to realize that I couldn't put my answer in 140 characters - not even with unicode tricks.
But I'm not surprised at all - and I don't even think it's a bad thing that there are unchecked fields on forms.
As I said in my reply:
"depends on context & is a tradeoff between effort & possible harm.
user ∈ inhouse dev ⇢ lax checks"
user ∈ public ⇢ strict checks [didn't fit in the 140characters limit]
The scenario for user ∈ inhouse dev ⇢ lax checksThis would probably also be a 'C' or a very small 'D' on the cockburn scale, wich is explained in more detail at Alistair's own site.
If I build a 3-hour effort tool for me and my fellow developers to manipulate database metadata and that is intended to run only on our development machines I probably
- won't put too much effort into checks against SQL-Injection - we can do all the harm we want anyway [and it doesn't matter much if we accidentally write "drop database;" in the database's command window or in an unchecked entry field]
- won't put to much effort into checks against the wrong type - I'm pretty sure all of the intended users (e.g. me and three co-workers) can handle an error message like "invalid type at line 8745 in <name_of__3rd_party_sql_library>"
- won't care if it's possible to enter 4gb of data through one of the entry field - the possible harm is well within acceptable limits for the stakeholders (me and my colleagues) and the harm could be achieved in much simpler ways
The scenario for user ∈ public ⇢ strict checksOn the other end of the spectrum would be a piece of software used by a large number of people who might or might not have have malicious intentions and where incorrect values might cause harm to serious money or even life (that would be a bigger 'D' an 'E' or an 'L' on the cockburn scale IMO.
The classic 'E' example for me is the ATM where I probably
- would make sure that only numbers are entered by using a hardware keyboard that only consists of numbers [and check the input values to be a little bit safer with respect to physical attacks]
- would replace drop-down boxes by large hardware buttons at the edge of the screen
- and so forth
The 'L' examples that come to my mind are mostly related to heavy machinery or medical equipment - in both cases the aforementioned principle - limit the choices and represent data entry through manipulation of physical objects - are heavily applied.
Most application fall somewhere in between and nowadays more and more applications that deal with essential money (e.g. online banking) are realized without the hardware representation. In these cases, especially for applications running on the internet, I would
- Put limits on the length of input data - on the client if possible and on the server just to make sure
- Make sure the data that get's typed in represents the correct types * as early as sensible [that might be on the client - I'd add a server side check for good measure in all cases and might drop the client side check if it becomes to intrusive for the user.
- Implement an error handling scheme that gives helpful information to the use with as much detail as he requests and informs the developers and maintainers of the system of the possible quirks in the system at the same time so that the UX can be optimized to have less occurrences of that specific error in future releases.
The problem with the two scenarios "user ∈ inhouse dev ⇢ lax checks" and "user ∈ public ⇢ strict checks"is that most applications are somewhere between them. And sometimes application evolve from a little developer-on-the-team-only helper application to something that is used by more and more people so the last responsible moment ** to rework my three our project to a product becomes hard to determine. But if I as a developer kept my options open (e.g. because clean coding has become a second nature) it should be possible to productize the tool.
But - it has to be a conscious decision!
In my opinion it neither makes sense to make a cheap tool cat-proof nor is it responsible craftsmanship to offer a product to the public that doesn't employ proper checks.
* but that is a topic for another article - the only type that a user with a keyboard can key in is "array of characters" - what it represents is 100% context: e.g. "feed" might be a word in one case - it's the hexadecimal representation of 65261 in others.
** See e.g. Mary and Tom Popendiek on the topic of the last responsible moment and the keeping of options. Due to a fancy website design on their side I can't provide a link though - but as of 2011-01-22 the statements can be found after clicking on "focus on learning" in the principles box on the left hand side of their website.
BTW: I really wonder how this page with the "is element of" and the arrows will display on other browsers and systems...
Thursday, January 20, 2011
Thursday, January 13, 2011
- Work expands so as to fill the time available for its completion.
Although sometimes Heinlein's Razor or Napoleon's unnamed version of it seem more appropriate...
Never ascribe to malice that which is adequately explained by incompetence, but don't rule out malice
Napoleon's unnamed epigram:
Never ascribe to malice that which is adequately explained by incompetence.
Sounds much nicer than: "Michael, you are an egomaniac. I know that because you complain about incompetent people" doesn't it?
Even if you're convinced that the other Person (or team for that matter) is malicious, unhelpfull or in any other way "bad" remember that that's just the way you perceive it. Talk about yourself - that is something you can be sure about and that can't be argued away. [It is very hard to tell somebody "no, you do not feel that way" - although sometimes there are people who try.]
Tuesday, January 11, 2011
You (I'm talking to myself here) are a NF generalist. If you want to convince an detailist you need to use arguments with lots of actionable detail - not the abstract mumbo jumbo you're used to.
(Wish I had thought about that two weeks ago)
Monday, January 10, 2011
As a last resort - e.g. if an official protocol would be taken as an offense - I take the tangential approach as in "When we agreed on
I most cases though it should be quite OK just to communicate openly and agree on putting the agreements in writing just to make sure that there are no misunderstandings.
Wednesday, January 05, 2011
Just now a wiki that was on my list of important resources (the former wiki of the AYE conference) vanished with no clue about it's future.
It not only sadden's me because Cool URIs don't change but also because there was a lot of content even at the simple members pages, that I didn't bother to make a copy of.
The saddest thing is that it would have been easy for me to make a local copy of the wiki - after all, that is what tools like SiteSucker are for, right?
I just have to use them more often...
Therefore this very serious note to self: Keep local backups!
====8<------ End of Note to self
Comment to self:
Now the last resort for this case is the Way Back Machine, but that of course doesn't always have snapshots that include all I want to retrieve.
Write each email as if it will reach your worst enemy because the chances are - it will!
Email might look like instant messaging or conventional mail - depending upon your background - but it isn't.
While it's not very common for IMs to get copied and pasted (although it happens) and conventional mails are only forwarded for a fee it is common practice to just press "forward" on an email. Considering that you might want to re-consider the idea to vent in an e-mail like "Hey Adam, I can't get Bob to do [whatever] - he's just to stupid and ignorant. Please do something about it".
Chances are that Adam just presses forward, adds "Bob, please do [whatever]!" and sends it directly to Bob.
If Bob wasn't your worst enemy before he probably won't be after - but I think the chances are high that your relationship with Bob won't exactly get better after this exchange.
As usual YMMV. I just had to remind myself about that yesterday. Again. (But at least I caught myself in time.)
=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----
Tuesday, January 04, 2011
Sometimes I have to reminded myself to "eat my own dogfood" (or "take my own prescriptions")
Why should I not apply the same principles to facilitation that I recommend for software development?
Yesterday's Weather is perfectly applicable to meeting facilitation - if you know your tasks.
It's rather a high probability that the same task with the same amount of people in a retrospective (e.g. gathering data via a FrIm Chart) will take more or less the same amount of time.
So - to develop a plausible agenda - it's helpful to record the time each task took and the relevant circumstances (Time of day, number of participants etc.)
Therefore: Keep Records!
In the case of retrospectives you get a very sound foundation base your planning on data instead of guesswork very quickly. I'd say 3 Iterations should gauge your instruments [for that team] pretty precisely.
=====8<---------- Start of note-to-self 002, Keep Records! Measurement & Calculation beats guesswork ----
Sunday, January 02, 2011
=====8<---------- Start of note-to-self 001, Always put up a visible agenda ----
Today I recalled a lesson from AYE - When facilitating a meeting with different personality types it helps everybody to set up a visible agenda and adhere to it - as log as it leaves enough room for deviation.
Some people need a clear picture of where the discussion is going while others are comfortable by "going with the flow". While it doesn't do harm for the latter if you put up an agenda - as long as the topics are liberal enough - it enables those who are in favor of the clear picture to focus on the topic at hand without worrying to much about what might come next.
The fact that the agenda might be helpful for the facilitator as well might be noteworthy as well - for example as a tool to direct the focus or as a tool to postpone the discussion to a later topic. Mixes well with a 'parking lot' to keep track of topics/issues to cover. But of course YMMV
[And of course "Always" should always be used with caution - in this case it is
meant to be read as "Whenever it is applicable, use common sense"]
=====8<---------- End of note-to-self 001, Always put up a visible agenda ----
What are these notes-to-self?
As Alan Weiß' calculation "if one improves 1 percent a day, one will be twice as 'good' in 70 days" shows the possibilities for self improvement are enourmous. (according to Kn = K0 * (1 + (p/100))^n => 1 * ( 1 + (1/100))^70 => 1.01 ^ 70 => 2.0067633... it is even a little bit more...)
But in my experience that math doesn't compute - or at least not for me.
Although I do work on getting better every day there also is a constant loss going on with me. I forget things, I don't apply learnings to new situations, I fail in the application some piece of knowledge that I posses and so on.
When (and if) I realize these events I have a chance to get my 1 percent for that day. (Nah - not really - make it 0.1%)
Up until now I tried to make a "mental note" of these learnings - both old and new. But after only one year it's hard for me to go over 365 purely mental notes, so I thought I should explicitly put them somewhere.
Starting today I'll try to pick the most important one of these aha-effects for each working day (no correlation to business days - I work freelancing) and put it down here. Each note-to-self will consist of the note itself plus a short explanation of it's meaning and context, as can be seen above in the first one.
Topics might be from a very wide range - don't expect notes on CxO level if I spent the day knee deep in code. I guess I'll cover:
- very low level (like: Note to self: ci
in vim is important or Note to self: make sure you're laptop is in powersave if you give a presentation in an hour)
- development related (like: rvm helps with the descendants of the dll hell)
- coaching related (Note to self: What looks like resistance is often lack of safety)
- Facilitation related (see above)
Or something that I haven't yet thought of.