Thursday, August 11, 2011

16 elevator pitches for scrum as a contribution to @boeffi's compilation

As an answer to a recent query for scrum elevator pitches on twitter from @boeffi (Who also runs German blog on software development) I asked myself (and him subsequently) a couple of questions regarding the setting and desired result to target the 140 character accordingly...
Unfortunately (for me) his answer was "All of them".
Please join the discussion at his site

Challenge accepted!

Given that I asked about four dimensions I think 16 "pitches" of less-than-140 characters will do for starters...

The collection of Scrum Elevator Pitches

Please read the disclaimer below - don't use them literally
  • The physically realized earned value from delivering fully functional slices in scrum takes ROI from estimatable to measurable
    MSLM: Management, Sell, Long term, Money
  • Proccesses like Scrum can help in the transformation of the whole organization towards lean by providing transparency throughout.
    MCLM: Management, Convince, Long term, Money
  • By concentrating on the most valuable parts in shippable slices Scrum reduces time to market considerably - often to a few weeks.
    PSLM: Users, Sell, Long term, Money
  • Instead of investing the subject matter expert's time in the test at the end Scrum involves him early to build a fitting product
    PCLM: User, Convince, Long term, Money
  • One scrum project, budgeted for 10 Mio $ was ended after spending only 2 Mio $ – because it had delivered all the important features
    MSSM: Management, Sell, Short term, Money
  • Scrum's focus on a "potetially shippable" increments ensures that the produced product-parts provide real value to the users
    MCSM: Management, Convince, Short term, Money
  • The proven prioritization models of Scrum enable you to get high value from the development team early for your time investment
    PSSM: User, Sell, Short term, Money
  • The continuous effort you put into specifications can be turned into continuously valuable and tangible results by Scrum
    PCSM: User, Convince, Short term, Money
  • Scrum can give organizations the information they need for a fundamental reorientation - or help to make them ready for it
    MSLB: Management, Sell, Long-Term, Buy-in
  • Having crunch times and lulls can be countered by adopting the basic Scrum rules - they create a self balancing, sustainable system
    MCLB: Management, Convince, Long-Term, Buy-in
  • Getting Scrum to both sides - developers and users - gives users a real strong lever over the scope of the final delivery
    PSLB: User, Sell, Long-Term, Buy-in
  • If all the effort that goes into upfront specs went into a Scrum-like collaboration the results would be closer aligned to the needs
    PCLB: User, Convince, Long-Term, Buy-in
  • Scrum is a set of techniques that generates transparency and makes projects predictable and controllable again.
    MSSB: Management, Sell, Short term, Buy-in
  • With scrum both parties of product development lay out rules that ensure - but also requires - mutual commitment and engagement
    MCSB: Management, Convince, Short term, Buy-in
  • With Scrum you get the opportunity to set the direction of the development at least once a month.
    PSSB: User, Sell, Short term, Buy-in
  • If you want to gain a real and direct influence over the priorities in the development team you might want to have a look at scrum.
    PCSB: User, Convince, Short term, Buy-in

Explanation of the Dimensions: Audience, Goal, Timeframe, Required Action
Audience: [Management=M, user representative or possible Product owner=P]
Goal: [Sell=S, Convince=C]
Timeframe: [Long term=L, Short term=S]
Required Action: [allocate Money or resources=M, Buy in=B]


These are examples of pitches for generic situations - don't use them! Forge your own given your specific situation and requirements.
In my opinion there is no such thing as one right elevator pitch for anything - it's all about the context.

Wednesday, July 06, 2011

One Inbox or Inbox Zero?

Since when does "Inbox Zero" refer to email?

When I first heard of the idea of an empty inbox it did not refer to you email inbox - instead it referred to a very physical inbox and to the management of workflows. Merlin Mann did an excellent Job of tying the inbox metaphor in the context of inbox zero to the email mailbox with his article series.

In GTD (getting things done) the inbox is something quite different

From what I understood from the GTD book by David Allen the point of an GTD-Inbox is twofold. First to get things out of your mind quickly and secondly to have one place of reference for your tasks/todos. Once you have that you can apply the two-minute-rule and other things from the GTD toolkit.
So actually in this model the inbox is a logical container for all the stuff you have to do.

Using the email inbox as a todo list harms your work organization

If my inbox is tied to the email system my work is tied to my computer. Assuming I wanted to set up a workflow system that is more pull oriented and does not necessarily contain only virtual to dos I would have to somehow bend your email workflow and it would be hard to use a different tool for your workflow management. Although I have to admit that there was a time when I had email folders called "Pending", "In Progress", "Waiting" and "Done" - but they didn't have WIP-Limits and it was at a time before David Anderson had even begun to write the Software Kanban Book.

Goals of the Inbox

Having one place to collect all todos is far more important for me than having an empty "unsorted pile" - which basically is what the "inbox" really is.

"Email Inbox Zero" is quite random IMO

Why the heck are so many people possessed with getting their (email) inbox to zero? What about their Twitter Inboxes, their Skype Inboxes their paper inboxes, their... you get the picture. So instead of trying to achieve inbox Zero I just scan my emails whenever they arrive or I have the time to do it. If I think I have to act upon one of them I create a ToDo in a secondary system. If I need to reply, i create an empty response, save that (so that don't have to search for the original) and create a ToDo in a secondary system.
The todos in this secondary system are completely independent from my mail workflow, my inbox contains literally tens of thousands of emails and I don't have any problem with that.
And I don't spend hours of thinking about ways to find an effective way to abuse my email system.

Plain text is king? Pen and Paper?

So what magical secondary system do I use?
None at all.
Right now I work with a three tiered approach consisting of Pen and Paper for the first tier, and two documents in plain text that get synchronized between all my devices.
I guess everybody has to find their own solutions. But that is not the point. The point is: It is not you E-Mail inbox and copying, deleting or moving hundreds of emails per day might even eat up time that you could spend getting things done.


(This post is v0.9 but the ship date has arrived...)

Thursday, May 26, 2011

Pre-flight checks are possible on planes but not on Enterprise Applications - why?

Pre-flight check
Unit testing is all pretty well but what about delivering these tests into production?
Is it a good idea? Or is it "nice for toy applications, but you can't do that with Enterprise Applications, because there is to much money/security/personal data at stake"?
And what kind of tests are we talking about anyway?

Basically this post is meant to debunk some believes that I encountered during a couple of Enterprise Application projects. Lets look at them:
  1. We write throw-away code for unit tests that that we wouldn't need if we didn't write unit tests

  2. [The] tests are only usefull during development - they /must/ be removed from production code

  3. We don't need to simulate the connected systems once we get the real systems connected

  4. Throw-away code is effort that's useless and could/should be avoided

While these claims seem very convincing at first sight and might be very appealing to managers who try to get a development team to be "more productive" their physical world counterparts tell that story quite differently. And my own - albeit to some extent seemingly counterintuitive - observation is that these believes seem to be quite wrong.

Now - if you're still with me (or against me - as long as you care about the matter) - let's debunk them one at a time

(Unit-) Tests require otherwise useless code - I don't think so!

Of course you need to write some things to automate the tests that would not be necessary if you did something else instead. Like testing the application manually. But that doesn't mean that you win anything by not writing "those things" in the first place. You'd just replace a checkable, repeatable way to test your program by one that’s dependent on the alertness of the tester (in fact: your alertness!), her or his mood, interruptions etc.

And let’s look at "those things" that you have to write. For me, three things come to mind - the tests themselves, some kind of test harness and some special diagnostic extension point where it is possible for the tests to get access (read and write) to otherwise unexposed information. I'll come back to the exposition of otherwise unaccessible information in the next section but the other two can be dealt with right away.

The tests themselves? Well, of course I could just test the System manually. But even if I was willing to re-test all possibly affected portions of my system each time I change my code - which I am not - it soon would become economically unsound. Apart from the sheer amount of time spent doing that, for any system that has reached a substantial size I would have to keep records of the test so that I can repeat them easily and know which parts have been retested since the last change and which still need some love. Just writing the tests is way less effort than the combined effort of writing specs, keeping track of the test I just did manually and the manual testing itself.

The test harness? I think this is addressed by the same consideration that hold true for the tests themselves. Plus the fact, that there often is no way to test without a test harness since the system under development relies heavily on surrounding components.

Test should be run only outside live systems - I don't think so!

So let's come back to those extra accessors we wrote for our test that are "only there for the tests". Well sometime they /are/ only there for the tests. Unfortunately. They could be so much more. Let's look at the real - sorry, physical - world for some comparison:

Airplanes and automobiles.
Have you ever wondered what all those dials on a typical airplane dashboard of the last century indicate? Well a lot of them show things that /should not be necessary to measure/ for example the exhaust gas temperature (egt). This also is a function of the manifold pressure and the fuel intake - both of which are displayed by other gauges. But measuring each of the components separately - which really is redundant if everything works as designed - gives the pilot the option to manually lean or enrich the fuel for optimal performance. And it serves as an indicator of possible related problems.

I still have to see an Enterprise Application where there is e.g. a counter for request, a counter for inserts and a counter for updates, that get monitored in production. Such counters usually are there - for the tests. And they are used - in the tests.
So why not take them to the production system?

Or take another element of pre flight checks (not applicable to jets), the mag-check. Usually airborne engines use a magneto based system for spark generation and two separate circuits with separate magnetos and two spark plugs per cylinder. The "normal operation" is to have both spark plugs running. But - and this is where Enterprise Applications differ hugely - the pilot can control this. Even in mid-flight. And it's part of the pre-flight check to test those unwanted conditions.

Like "Both" - Revs should be 1400, "Left" - Revs should drop (only one plug), "Both" - Revs should rise again, "Right" - … you get the picture.

But I've never seen something like that done to an Enterprise Application:
"Cache Available" => All pages should show in less than n milliseconds
"Cache not Available" => Pages x,y and z should show much slower
"Database available" => Data should be written to the database
"Database not available" => Data should be written to files

But wait - that's not possible.
Because we removed all the rods and knobs that enable direct access to those internals from the production code.

And more often than not it's not even possible to take the delivered application an debug it because the debug information - and even the symbol tables where applicable - have been removed. So it's necessary rebuild the production version including debug information from the source control and try to recreate the failing scenario.

If automobile engines where build like that you would have neither the yellow "general engine failure" light on the dashboard nor the option to go to the garage and have them plug in the diagnostics computer and tell you exactly that there are air bubbles in the fuel pipe every time the engine revs over 5521. (that's an example of course…)

Instead the garage would have to rebuild an engine exactly like the one you've got in your car and analyze the error from that one. Or at least completely disassemble your engine, insert probes, reassemble it and run it in an environment simulating your car.

Although there are numerous implementations where you can probe a running system - especially on Apples OS X - they are mostly aimed at system level functions or the core frameworks. Actually I think it's very sad that it is so uncommon for programs and especiall Enterprise Applications to reveal relevant information about their internals.

It's preferable to use The Real (connected) System for development - I don't think so!

Do you really think that, in the car supply industry, they fit each wiper motor in bodies of all targeted cars before they ship them? Last time I checked they used test rigs that have nothing in common with cars except for the interface to the wiper motor - but they might have some additional features like an instrument that measures the torque of the motor and another one that measures the current drain. And by mounting the wiper motor in that rig and measuring those values they can verify that it actually confirms to the contract to which both the car manufacturer and the supplier designed their part. (Which opens the road to Design by Contract - but that would be another story)

If you write code that get's deleted later than it's waste - I don't think so!

Gimme A HandThere are lots of examples from the ream world that tell a different story. The simple one of course is the paper cup you get with your coffee to go. It does get 'deleted' later on, when you throw it away, but I don't think it's feasible to do completely without it. At least I would either burn my fingers or at least ruin my shirt if I tried to take "only the coffee and nothing but the coffee" from my local takeaway. (Replacing the throw-away cup with a mug for multiple usage might be a good idea from an environmental point of view, but replacing it is not the same as "just don't do it”)

The Casting Process * Craft & Design / Product DesignThe Casting Process * Craft & Design / Product Design
The Casting Process * Craft & Design / Product DesignThe Final Casting * The Casting Process * Craft & Design / Product Design
Another examples - that is perhaps more suitable from production point of view - is almost anything that has to do with casting metal. A wide range of casting techniques requires a cast that gets destroyed in the process. Those are made up of a multitude of materials and usually require serious work before the casting process can begin. And after the casting and cooling and hardening it often gets destroyed by brutal force - with hammers and pickaxes if needed. I really don't think you could build those metal things without the cast. So if I write code that for example simulates a calculation that will be build much later and gets thrown away once the more complex "real" function is implemented that - for me - is the mold that allows me to form the rest of my code around it.

Theres a ton of related material out there, but "PPP" by Uncle Bob and the original edition of "Extreme Programming explained" by Kent Beck do a pretty good job of conveying the fundamental concepts. And throwing in some TDD by Kent Beck, BDD by Dan North plus Refactoring by Martin Fowler et. al. for good measure wouldn't do much harm either - but that's on my 2¢ and of course YMMV.

PPP = Agile Software Development, Principles, Patterns, and Practices by
Robert C. Martin
TDD = Test Driven Development: By Example by kent Beck
Refactoring = Refactoring: Improving the Design of Existing Code by Martin
Fowler, Kent Beck, John Brant and William Opdyke

Thursday, April 28, 2011

Re: [Airbnb Community Support] Re: iPhone Support Request

Dear Airbnb, (CC'd to the same Blog as before)

please do me the courtesy of at least reading what I write.

Which part of "I don't want you to help me track the information down" did I write in such a way that it was so easily misunderstood?

Now I am not only a customer who feels that he is not in Control of his data but also a customer who infers from your actions that his concerns are of no real importance to you.

Yours, Michael

On 28 Apr 2011, at 17:07, Cathy H <> wrote:

-- Please respond above this line. --

Cathy H, Apr-28 08:07 (PDT):


Our records indicate that your reservation with Hannes in Vienna has been accepted. As payment you supplied us with a Mastercard ending in nnnn and were charged: $nnn / €nnn EU This charge was pushed through manually a moment ago, because when you entered your payment information you forgot to select the country you live in. We've done that for you and now you should see the charge on your credit card.

Your request with Eva in Vienna is no longer possible because she did not respond to your request within 24 hours. You were not charged for that.

Please let us know if we can provide further assistance.

Kind regards,

Cathy H
855.4.AIRBNB (Toll Free) or 415.800.5959
Help Airbnb win a Webby Award, vote now!

Michael Mahlberg, Apr-28 07:14 (PDT):

Dear Airbnb, (CC'd to one of my blogs)

In the meantime the registration has expired and /after that/ the payment information is visible on the website - for a brief moment until I confirm the information. Then it's inaccessible again!

So, in the name of open Business-2-Customer relationships, here is what I would expect:

I don't want you to help me track the Information down - I want control over my data!

I want to be able to see /exactly/ which data you have on file for me.
I want to be able to see, which transactions are pending right now!

As much as I like the idea of your service, I don't feel comfortable if you play it so unreasonably close to the chest.

( @MMahlberg on twitter )

Cathy H, Apr-28 06:57 (PDT):

Hi Michael,

We'd be happy to help you track this down. Can you please provide your reservation code?


Cathy H
855.4.AIRBNB (Toll Free) or 415.800.5959
Help Airbnb win a Webby Award, vote now!

Michael Mahlberg, Apr-26 09:18 (PDT):

Please enter the details of your support inquiry below:

User Information
Name: Michael M.
ID: 533213

How can I find out, which of my credit cards I used to make a reservation?

Situation in case: 6 credit cards, one booking with airbnb - no movements on any account. Host has not yet (21 hours) responded.
Which c-card is on your files? which one can I max out?

Cheers Michael

User Information
Name: Michael M.
ID: 533213

(von unterwegs gesendet)

Airbnb Community Support
Phone: 1-855-4-AIRBNB | 415-800-5959

Monday, April 18, 2011

Why Google-Checkout sucks - at least for me

I just tried to buy the electronic version of David J. Anderson's Kanban book, because I'm traveling the world quite a bit right now, left the paper book at home and wanted to look up a few specifics for the design my own personal kanban system.

Two things delayed my decision to buy it - and actually will delay it for a couple of days to come. Which is unbelievable for a process that takes a mere minute on amazon and the pragmatic bookshelf.

1) I have to buy the eBook twice to read it in iBooks and on the Kindle [see below]
2) I have to become a Google-Checkout Customer (which is the dealbreaker)

The Problems with Google-Checkout

  • They (Google Checkout) added my credit card info to the currently logged in google account
    Really? The currently logged in account? That's just silly.
  • They (Google Checkout) stored the credit card information
Actually Amazon also stores the credit card data. But amazon is a store - Google is a search engine and an information broker. So I'm supposed to give my credit card information to an information broker, who adds new services to it's portfolio every day?
So, what I'll have to do now - to get the electronic version of a book I already own - is to get a prepaid credit card, put some money on it, connect that to google checkout, buy the book, disconnect the card from google-checkout.
[Aka: No, I don't want others to be able to control my credit card and identity management. That's where I really want a push system]
What a waste of time!

The Problem with buying the book twice

I use the Kindle for reading and the iPad for Browsing, and since the Kindle UI is only mediocre compared to iBooks I would love two have both formats available as it is possible with the pragmatic bookshelf. I admit that the Kindle UI is not as bad on the iPad as it is on the Kindle itself, but still it's a drawback compared to the iBook experience. So the current option for buying the book online isn't "quite" as pleasant as it would be to buy it from the pragmatic bookshelf - or perhaps I'm just spoiled by the latter's focus on customer value.

Thursday, March 17, 2011

Note to self 15 - If a project has no risk - don't do it.

Dear Michael,
Liz Keogh in her QCon London session on different kinds of incentives last week reminded me of this quote from Tom DeMarco and Timothy Lister's "Waltzing with bears".
As DeMarco and Lister put it in the book each and every project that is worth it's while has to have risk.
For me the implication of a project with "no risk" is not only, that it could be done by anyone in any environment but also that it doesn't matter if this project fails - essentially that is what "no risk" means in the end, right? - and who would want to work on such a project?

Friday, March 11, 2011

Digital Taskboards I'm aware of as of 2011-03-11

At the Agile London usergroup meetup last night the topic of digital taskboards came up and I promised one of the participants to send a link to /one/ of them… since I couldn't remember which one I was referring to (it was kanbanery, I found my note eventually) I went through the list in my head and realised that the list isn't so short any more…

  • Qanban…a very promising (and free as in speech) project from @xlson which unfortunately doesn't undergo much development right now. But… it's open source, the source is on github - you know what to do!

  • Kanbanery…got a lot of mentions lately on twitter, but I only did a testdrive

  • Pivotal tracker…A friend of mine uses that a lot (Cheers @jcfischer) and is quite pleased with it

  • See Now Do… haven't tried it, but I know the product owner and from that I infer that it ought to be good

  • Atlassian / Jira / Greenhopper
  • … that was the one we where searching alternatives for...

@Lynne: Sorry - to many to tweet directly

Thursday, February 03, 2011

Note to self 14 - Backups don't matter, what you want is recovery

It really doesn't matter how good or how fast your backup process is - it's fastest if you just copy to /dev/null - if the recovery doesn't work. 
This is one of the times when the practices of ITIL and the like are very applicable even to the smallest IT department - like your own personal laptop computer.
Do a trial run of the recovery every now and then!

(At least I was told that ITIL emphasizes these trial runs. If it doesn't – well, to do them still seems like a good idea to me)

Edit: As Robby Raschke said on Twitter: IT Service Continuity Management (ITSCM) in ITIL is where testing your business recovery is a critical component.

Tuesday, February 01, 2011

Note to self 13 - you can't assign responsibility, it has to be assumed

Michael, you might be able to say - or even order - that somebody is responsible for something but that doesn't really make them feel responsible for it. If he is assigned that responsibility without assuming  the responsibility he will most likely find ways to delegate this responsibility and to redefine the borders of the responsibility. 
An example for assumed responsibility would be this guy I know who develops his own software for a living - they lengths he goes to circumvent the glitches of the operating systems are impressive. For example even if the java installations on the client machine are completely effed his software will still try to figure out the best match for his needs and will 'just work' - Although he could just lay back and take a position of "Well, if the user can't correctly install java it's his problem" he doesn't. He feels not only responsible for implementing his software. He feels responsible for the users experience with his software. (And given the fact that he is able to make a living from a $30 software package his commitment seems to pay off)
It's unrealistic to expect this kind of behavior from people who are assigned responsibilities - especially if they don't believe in the goals or the underlying beliefs of the people who try to assign the responsibilities. 

Saturday, January 29, 2011

Big scale 'Agile', enterprise 'Agile' - what went wrong?

I'm just trying to understand the idea of large scale 'Agile'
"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

Note to self 012 - Write it down immediately - with a pen!

Dear Michael,

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

Context does matter in UX und UI design

In a recent tweet a friend of mine (Selena Delesie) stated that she is "Surprised to discover there are programmers who still don't put limits, data type restrictions, and error handling on form fields."

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 checks

This 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 checks

On 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 13, 2011

Note to self 010 - Parkinson's law strikes - again!

It may not sound very nice, but the sad fact is that people tend to use up the available time for a task in a lot of situations. Therefore: If you want to be over with the meeting in 30 minutes send out an invitation for only 30 minutes - if you make it 45 minutes in the invitation it will take 45 minutes.

Parkinson's original quote from 1955 is:
Work expands so as to fill the time available for its completion.

Note to self 009 - it's called Hanlon's razor

And it goes: Never attribute to malice that which is adequately explained by stupidity.

Although sometimes Heinlein's Razor or Napoleon's unnamed version of it seem more appropriate...

Heinlein's razor:
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.


Note to self 008 - It's not "You are " it is "I observe "

Dear Michael, [talking to myself as usual] I noticed that you complain about incompetent people. When I hear that I tend to put you in the category "egomaniac". What can we do about that?

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

Note to self 007 - I still can't handle incompetent people

More a point I still have to work on than an actionable note to myself:
Don't get overconfident. It's not enough that somebody is incompetent - you've got to be able to convince people of this seemingly obvious fact. If you can't pinpoint it - just let it go for the moment. Especially if you can't put a number to the incompetence.

As a matter of fact this is something that I've never really gotten around to. 

[Explanation of the note for reader who are not myself] 
There is a certain kind of incompetent people (e.g. they just have no expertise in the very thing they are doing, they are literally incompetent in such a way that they lack the competences that they need to perform their job) that I still don't know how to handle - those that don't know the details of the job their doing but are yet well versed in easily graspable abstractions of the work they should be doing
The only way to handle these people - who sometimes have a real bad effect on the morale of whole teams - seems to be a very detailed breakdown of their shortcoming. But that on the other hand leaves me in the position of a nitpicker [erbsenzähler] who wastes everybodys time - including my own - by going through seemingly unimportant details.

Of course - applying the rule of three - that can't be the only solution - but although I've been trying for years I haven't  been able to find any other angles. At leas not up until now - still trying!

Notes to self 006 - Be aware of the focus of the reciepient

In an oversimplified view there are generalists (often sporting an NT of NF in MBTI speak) and there are "detailists" (often sporting an SP or SJ in MBTI speak).
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

Notes to self - 005, Get it in writing - even if you have to put it there yourself

As I wrote a while back it is always a good idea to get important agreements in writing - Today I just had to remind myself that - especially in these days of electronic communication - there is always the option to put it writing yourself.
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 we also mentioned - would it be OK for you to treat these separately?" thus getting a written - and circulated - record of without offending my negotiation partner.
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

Notes to self - 004, Keep local backups - The Cloud might dissolve

Keep local backups - The Cloud (aka the web) might dissolve locally

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.

Notes to self - 003, Write each email as if it will reach your worst enemy

=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----

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

Notes to self - 002, Keep Records! Measurement & Calculation beats guesswork

=====8<---------- Start of note-to-self 002, Keep Records! Measurement & calculation beats guesswork ----
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

Notes to self - 001, Always put up a visible agenda

Each working day I learn something new - or relearn something old.

=====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.