Archive for the 'Howto' Category

Separate the Zebra from the Herd

From Zebra Herd To Kanban

From Zebra Herd To Kanban.

Suddenly it was crystal clear to me. The evolutionary story of the stripes of the zebra told me why I don’t have to fail. I had so many important tasks to carry out. I fought the in-box from dusk to dawn. I reacted to new ideas and added them to Work-In-Progress. And the most important tasks remained undone. They hid in the herd.

The zebra stripes confuses the lion. Each individual’s stripes blends in with the stripes of the herd fellows around this particular zebra. The lion has trouble picking out any one zebra and he’s got no plan for how to attack. He can’t even understand in which direction the zebra is moving. The predator doesn’t see a prey, it can only see a lot of stripes – hundreds or thousands – moving around in an unpredictable pattern.

Each zebra is an activity in our To-Do. We are the lion that needs to focus on one zebra at a time. Our Work-In-Progress mustn’t be the number of individuals in the zebra herd. Our effort to complete any task, depends on our success in separating a zebra from the herd. And even more: to complete the most important task – to be maximum effective – we must separate the right zebra from the herd.

Great news is that there are good practices that come to rescue. The Now List is mandatory, i.e. you must limit the work in progress. You must also understand that focus mode (completing tasks) and overview mode (classifying, sorting, and prioritizing tasks) are not compatible. You need to alternate frequently between these two modes — in a controlled way. And a third practice is to visualize all potential upcoming activities. The recipe goes: create the big picture, choose your target, and don’t constantly switch.

Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC


Pivot – kanban token as a thought torn out of the thing

A sticky note on a kanban board is a pivot.

Sticky notes on a kanban board are pivots.

We can be incredibly efficient, but the users of the software we’re creating will only benefit from it if we are effective. Effectiveness is when our customers solve more problems and with higher quality – when they make better business. Implementing received specs is pushing paper. Pro-activeness is to make all aspects of software development to activities to develop our understanding of our client’s needs. Continues delivery is a great tool here and pivots can help us stuff these deliveries with the most effective content.

A pivot is an object used to function as another object in a play situation, like a sticky note with a user need written on it. The sticky functions as the work to write code that meets this need. Planning what to do right now is a play situation. The columns of our kanban board functions as time: future, present and past. (Actually, present seems to be near-future in most kanban implementations – nothing wrong with that.) Moving stickies across the board is a play situation.

Lev Vygotsky taught us that we need a pivot to tear the thought out of the thing. In order to reason about the priorities and the meaning of upcoming tasks, we need objects that represent these tasks. Vygotsky described a child that lets a stick function as a horse: “At that critical moment when a stick – i.e., an object – becomes a pivot for severing the meaning of horse from a real horse, one of the basic psychological structures determining the child’s relationship to reality is radically altered.”

In their book Personal Kanban (Modus Cooperandi Press, 2009), Jim Benson and Tonianne DeMaria Berry elaborates further: “Personal Kanban is an information radiator for your work. With it, you understand the impacts and context of your work in real-time. This is where linear to-do lists fall short. Static and devoid of context, they remind us to do a certain number of tasks, but don’t show us valuable real-time information necessary for effective decision  making.” The pivot is an information radiator. Playing with it develops our idea of the object it represents: our work.

Lego Serieous Play is a is a process designed to enhance innovation and business performance. By using Lego bricks as pivots, teams conduct exploratory workshops on various subjects:

  • Strategy development and exploration: Examine and evaluate relations to external partners and clients.
  • Organizational development: For management, teams and individual employees.
  • Innovation and product development: Unleash creative thinking and transform ideas into concrete concepts.
  • Change management: Facilitate and implement structural changes and mergers.
Lego Serious Play in action. (photo by Ulrika Park)

Lego Serious Play in action. (photo by Ulrika Park)

There are many more examples of pivots used in business. In an ever-changing world, we have to understand new concepts every day. By using pivots in a play situation, we tear the idea out of the object and sharpen our understanding of what the object really is.

Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC

Dot — The Regex Barbapapa

Remember Barbapapa — Annette Tison’s and Talus Taylor’s children’s books and films from the 1970s? The hero was a pink, pear-shaped guy with the ability to take on almost any shape whatsoever. The equivalent in Regex is dot ..

Dot is a character class — a generic character. Instead of using literal characters, like 2, a or #, you can use dot to specify that you accept almost any character.

Ruby> 'mama 2 ##'.gsub /a|2|#/, '¤' #=> "m¤m¤ ¤ ¤¤"
Ruby> 'mama 2 ##'.gsub /./, '¤' #=> "¤¤¤¤¤¤¤¤¤"

There are two cultural problems with the dot, that is important to be aware of:

  1. The character class dot . and the closure function * are together and separately the most abused features of Regex. If you use them perfunctory, you’ll often end up with too general regexes — sometimes even incorrect. Every time you intend to write ., * or even .* You should consider if you really mean something more specific.
  2. A majority of Regex books, including the most popular one, are unclear or even entirely incorrect, as they claim that “dot matches any character.” In most cases dot matches “any character except line breaks.” It’s a very, very important difference.

Why doesn’t dot normally match line breaks?
The original implementations of Regex operated line by line. Programs like grep, handles one line at a time. Trailing line breaks are filtered out before processing. Hence, there are no line breaks. NASA engineer Larry Wall created Perl In the 1980s — the programming language that evangelized Regex more than anyhting else. The original purpose was to make report processing easier. What would then be more natural than to continue on the path of line-oriented work? Another argument is that the idiom .* would change meaning if dot matches line breaks. Perl set the agenda and now, a few decades later, we can only accept that dot typically don’t match line breaks, no matter what you and I believe is logical.

Ruby> "grey gr y gr\ny gray gr\ry".scan /gr.y/
#=> ["grey", "gr y", "gray"]

How can you force dot to match line breaks?
You set a flag. Unfortunately, this flag has different names in different Regex dialects. In Perl, it’s called single-line mode. Imagine what happens if dot matches all characters, including line breaks. Input data becomes a long line where the line break is a character like any other — hence the name. Single-line mode should not be confused with what in Perl is called multi-line mode. Multi-line mode affects the anchors $ and ^ and it’s orthogonal with single-line mode. To add more confusion, Ruby use the term multi-line line, when they mean Perl’s single-line mode. And the real multi-line mode is mandatory in Ruby — no flag available there. The best approach to this mess is if you and I call the flag Dot match all, no matter how it is written syntactically in different dialects. By the way, in Ruby you add m next to the Regex literal when we want the dot to match any character.

Ruby> "grey gr y gr\ny gray gr\ry".scan /gr.y/
#=> ["grey", "gr y", "gray"]
Ruby> "grey gr y gr\ny gray gr\ry".scan /gr.y/m
#=> ["grey", "gr y", "gr\ny", "gray", "gr\ry"]

And if there is no flag?
In some Regex dialects, most notably JavaScript, there’s no flag for dot match all. An workaround is to replace the dot with the idiom [\ s\ S]. This idiom matches exactly one character — either white space or anything that is not whitespace. These two classes are of course 100% of all the characters — including line breaks.

JavaScript> 'grey gr y gr\ny gray gr\ry'.match(/gr.y/g);
[ 'grey', 'gr y', 'gray' ]
JavaScript> 'grey gr y gr\ny gray gr\ry'.match(/gr[\s\S]y/g);
[ 'grey',
'gr y',
'gr\ry' ]

Is dot to general?
I also argued above that the dot is often abused in our community. What does that mean? Imagine that you want to find all time strings in a text. You’ve got the following specification:

  • Time always includes hours and minutes, sometimes even seconds.
  • Hours, minutes and seconds are always written with two digits
  • You don’t have to ignore impossible numbers, such as minute 61.
  • Inbetween hours, minutes and seconds you’ll find one of the separators dot . or colon :.

The results of a simple regex like \d\d.\d\d(.\d\d)? might surprise you:

Ruby> "12:34 09.00 24.56.33".scan /(\d\d.\d\d(.\d\d)?)/
#=> "12:34 09", "00 24.56"

That’s not what you wished for. Dot matches space! If you replace the item with the more specific character class [.:] you aim closer to target. You mustn’t forget that dot inside a character class means that you literally want to match the dot character ..

Ruby> "12:34 09.00 24.56.33".scan /(\d\d[.:]\d\d([.:]\d\d)?)/
#=> "12:34", "09.00", "24.56.33"

Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC

8 management ideas for 2013

It’s 2013 now — a new year — and you struggle with inspiration. How can I be a modern manager? Here goes eight management ideas you might want to put more focus on:

1. Autonomous Teams
An autonomous team has skills (cross-functional) and are empowered (self-organized) to make its own decisions. The team has clear constraints for its mission and works towards goals based on outcomes and impacts. Everyone must be comfortable with working in an autonomous team.

2. Beyond Budgeting
Swedish bank SHB has been managed for over 30 years without budgets. Norwegian Statoil is another similar example. Annual budgets encourage managers to focus on making the numbers instead of making a difference. The alternative is dynamic and relative targets, holistic reviews, dynamic forecasts, dynamic resource allocation, and being event-driven rather than calendar-driven.

3. Holistic Thinking
Effect on customer’s or the customer’s customer’s business is more important than whether the individual projects hits estimated time, quality and cost. Fewer parallel projects, less formal roles and more decisions just-in-time makes the organization more flexible to adapt to the prevailing reality. When allocation of individuals is limited to 70-80%, there’s even more room for dynamics. Collaboration and shared goals across the project boundaries increases the total effect. Profitability is more important than cost control.

4. Non-financial incentive models
Team-based incentive programs might reduce the individual’s willingness to corrupt the system. And incentives don’t always have to be financial. With creativity and by listening to the employee, we can discover completely different things that are highly valued by our employees. With digital social tools, some of the rewards may come from colleagues as real-time feedback.

5. Knowledge-creating
Innovation-driven product development is more long-lasting than maintenance driven product development. Successful innovation requires that people from all levels of the organization put effort in monitoring the external environment. New combinations of explicit knowledge need to be internalized and shared by all colleagues. To grow employee’s tacit knowledge (talent) rather than build formal processes (structural capital) gives us an outstanding capacity.

6. Real-time Performance
Rather than annual performance reviews, try 15-30 minutes coordination meetings every week or every second week with your employees. Focus on individual development, not individual measurement. Targets are based on outcomes and impact. The manager’s mission is to help employees achieve their goals by removing impediments.

7. Recruit the right people, rather than the right experience
Don’t overvalue experience from your own field, your tools and your processes when recruiting. Other proficiencies have high value, such as personal energy, ability to complete, ability to learn, social skills, and ability to help the team grow. The new employee shouldn’t only look for the best financial solution. It must be her strategic decision, that this is the best environment for me to grow. She values teamwork and aim for t-shaped skills: depth of related skills and expertise in a single field.

8. Transparency and Visualization
To make all employees feel really involved, decisions must be accessible to everyone. The fact that information is stored somewhere isn’t enough. Abstract views of the current state are visualized on walls of wonder, in office areas where most people are. The visualizations are used as decision support while prioritizing.

And finally, here’s a bonus idea: The office as a laboratory where there´s always small experiments under way.

Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC

Regular Expressions – a brief history

Regular Expressions is a programming language with which we can specify a set of strings. With the help of two operators and one function, we can be more concise than if we would have to list all the strings that are included in the set. Where does Regular Expressions come from? Why is it called Regular and how does it differ from Regex?

The story begins with a neuroscientist and a logician who together tried to understand how the human brain could produce complex patterns using simple cells that are bound together. In 1943, Warren McCulloch and Walter Pitts published “A logical calculus of the ideas immanent in nervous activity”, in the Bulletin of Mathematical Biophysics 5:115-133. Although it was not the objective, it turned out this paper had a great influence on computer science in our time. In 1956, mathematician Stephen Kleene developed this model one step further. In the paper “Representation of events in nerve nets and finite automata” he presents a simple algebra. Somewhere at this point the terms Regular Sets and Regular Expressions were born. As mentioned above, Kleene’s algebra had only two operations and one function.

In 1968, the Unix pioneer Ken Thompson published the article “Regular Expression Search Algorithm” in Communications of the ACM (CACM), Volume 11. With code and prose he described a Regular Expression compiler that creates IBM 7094 object code. Thompson’s efforts did not end there. He also implemented Kleene’s notation in the editor QED. The aim was that the user could do advanced pattern matching in text files. The same feature appeared later on in the editor ed.

To search for a Regular Expression in ed you wrote g/<regular expression>/p The letter g meant global search and p meant print the result. The command — g/re/p — resulted in the standalone program grep, released in the fourth edition of Unix 1973. However, grep didn’t have a complete implementation of regular expressions, and it was not until 1979, in the seventh edition of Unix that we were blessed with Alfred Aho’s egrepextended grep. Now the circle was closed. The program egrep translated any regular expressions to a corresponding DFA.

Larry Wall’s Perl programming language from the late 80’s helped Regular Expressions to become mainstream. Regular Expressions are seamlessly integrated in Perl, even with its own literals. New features were also added to Regular Expressions. The language was extended with abstractions and syntactic sugar, and also brand new features that may not even be possible to implement in Finite Automata. This raises the question if modern Regular Expressions can be called Regular Expressions. I don’t think so. The term Regex denotes not only Kleene’s algebra but also the additions made by Perl, Java, Ruby, and other implementations.

Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC

Interview on Time Management and Future Book Projects

Baris: Effectively managing your to-do list is a big part of the Pomodoro Technique. I really like the simplicity of having a super simple list with items grouped as “now”, “today”, “later”. Is the “now list” your invention? Please tell me the thought process behind it.

Staffan: I think it’s my invention, even though many other people most certainly have similar concepts. Even if you decide to focus on just one thing, your thoughts easily starts to wander now and then. Writing the title of your current activity on a slip of paper and putting it next to the keyboard reminds you with in a fraction of a second what it was.

I’m interviewed by Baris Sarer. The full text is here:

  • Part one:
  • Part two:
  • HTML5 Form Validation With Regex

    Client side validation has always been a potential headache for front-end programmers. Embedded blocks with a mixture of imperative JavaScript and declarative regex can be a mess. HTML5 has ambition to add abstraction layers that would make this a bit easier. As I’ll explain below, theres’ still a long way to go before it’s rock solid.

    There are two ideas that enters the scene now:

    1. The <input> tag has new type attribute values like url, email, date, telephone number, and color.
    2. The <input> tag has the new attribute pattern where you can describe allowed input with a regex.

    Note that it’s only validation. It would have been nice to have filtering (e.g. remove spaces in a credit card number) or even replacing (euro is sent to server, whether the user enters euro or ).

    In case (1) as well as (2), a nice red-green feedback lets the user know if the user entered text is correct. The tool-tip of the input widget can also have a descriptive message of what the system expects from the user. You just set a value of the title attribute. More on that below.

    1. New values for the type attribute of the <input> tag

    To use the type attribute is simple. Here’s an example with the new value email:

    <input type="email" required />

    This made me curious. I guess that email is implemented with a regex under the hood. What does it look like? I don’t know, but it’s not correct. As a matter of fact the spec for the email attribute value is incorrect. It looks like this:

    A valid e-mail address is a string that matches the ABNF production 1*( atext / “.” ) “@” ldh-str *( “.” ldh-str ) where atext is defined in RFC 5322 section 3.2.3, and ldh-str is defined in RFC 1034 section 3.5.

    So currently, the HTML5 browsers accepts the email -@- and doesn’t accept "staffan nöteberg" — I tried. It should be the other way around. (Yes, spaces and diaeresis makes sense to the left of the @ sign, as it’s a local mailbox routing that might involve a not so SMTP:ish system. For the record I tried…

    echo 'hello!' |
      /usr/lib/sendmail '"staffan nöteberg"'

    …and it works!).

    However, even though it’s already implemented in many browsers, W3C makes it clear that it’s only a working draft. For the moment there’s a note in the document that they are aware of this error:

    NOTE: This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the “@” character), too vague (after the “@” character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

    My recommendation is to NOT use the email attribute until it has a better implementation.

    2. New attribute pattern of the <input> tag

    The input tag has several new attributes to specify constraints: autocomplete, min, max, multiple, pattern, and step. I’m particularly interested in the pattern attribute. It’s more generic than the new values of the type attribute mentioned above.

    The pattern value is a regex. In what regex dialect? Yes, you guessed it: JavaScript according to ECMA-262 Edition 5. This is a major drawback, since the regex support in JavaScript is modest (e.g. there’s even no meta class to match a letter — many other regex engines support the Unicode \p{L}). The whole user input must be matched by the regex, not only a fraction. You can look at it as if your regex is prefixed with ^(?: and suffixed with )$.

    Here are three pragmatic (but not globally perfect) examples I created:

    • Strong password: <input title="at least eight symbols containing at least one number, one lower, and one upper letter" type="text" pattern="(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,}" required />
    • Email address: <input type="text" title="email" required pattern="[^@]+@[^@]+\.[a-zA-Z]{2,6}" />
    • Phone number: <input type="text" required pattern="(\+?\d[- .]*){7,13}" title="international, national or local phone number"/>

    I leave it as a reader exercise to interpret these regexes. And you can try them too! They are online in this test page:

    If you combine type="email" and pattern then both constraints must be fulfilled.


    HTML5 form validation is a good idea. The pattern tag is very generic, albeit its rather limited regex dialect. Be careful with the new values of the type attribute, as they are only in prototype status currently.

    Finally: What about browser support. I’m in deep water here, but I understand it as there’s support for this kind of validation in IE 10+, Firefox 8+, Chrome 16+, Opera 11.6+, and Opera Mobile 10+. There’s partial or none support in Safari and Android.

    Pomodoro Technique Illustrated -- New book from The Pragmatic Programmers, LLC