Estimates are bad (and I mean it!)

Recently I wrote about my belief that it is a good thing to estimate. After all thats one of the differentiators that distinguishes us from other forms of life on this planet.

There is a huge number of quotes one can draw from to see the difference:

“Plans are nothing, planning is everything”

-- D. Eisenhower (maybe)

“In preparing for battle I found that Plans are almost useless, but planning is indispensable”

-- perhaps D. Eisenhower or Moltke

“No plan ever survives the first contact with the enemy, but no one survives the first contact with the enemy without a plan”

-- probably Moltke or Clausewitz

It's not so easy to find out who really is the originator of each quote – and I haven't found one yet from Sun Tsu, although I am sure there is one. But the important thing is that all those quotes make a very clear distinction between the act of planning and the actual plan. And there seems to be a common understanding, that the activity is important while the artifact itself –“The Plan”– is very brittle. And has to be adjusted accordingly. Often.

In my experience the same is true for estimates: don't hesitate to adjust them to adapt to a changing situation, but gather enough information and do enough planning to start with estimates that seem plausible to yourself.

Think about harvest planning in the middle ages – having leftovers at the end of winter didn't kill villages, stretching the food for the second half of the winter didn't kill villages. Not knowing how much demand for food there is and living in splendor until Christmas would have been disastrous.

So here the art of the possible would be to do “just enough” estimation.

How much effort would that be? :-)

till next time
  Michael Mahlberg

Estimation is good (and I mean it!)

I am a huge fan of Pavel Brodzinsky's estimation poker cards and the whole “#NoEstimates” movement. But then again I think at last the amount of estimation Pawel suggest is necessary. And as even the long time proponent J.B. Rainsberger said farewell to #NoEstimates I find it helpful to distinguish between “harmful estimation” (my esteemed friend and colleague Tom Breur recently wrote about these) and helpful estimation.

Harmful estimation

Estimation can become harmful for a lot of the reasons pointed out by the followers of the #NoEstimates movements or – for example – by the reasons Tom states in his article I mentioned above.

In my opinion estimation becomes especially harmful when

• it is used to put pressure on people
• an effort is made to get “exact estimates”
• estimates are treated as “exactimates”

Helpful estimation

But – and it is a very strong "but" – just because it can be misused (and often is), it doesn't mean that there is no good in estimation.

A little while ago I wrote about planning already – how planning is what made it possible to evolve from hunter-gatherers to modern men.

And for me the same holds true for estimation. If there is no estimation, then there is no way to know whether it makes sense to even invest the effort to work on something. Planning and estimation go hand in hand. Even in "predictable" environments things sometimes only go partially according to plan. We have estimation all the time:

• estimated time of arrival
• estimated miles on this tank
• estimated payout
• etc.

We couldn't possibly handle our world in all its complexity without “estimating.“ Estimating if the car will fit into the parking spot. Estimating the width of a creek to jump over (or not).

So yes, I think we do need estimates. We just have to make sure, that we know where we need them. And why.

till next time
  Michael Mahlberg

The difference between a sprint-backlog and a product-backlog

Those who learned about scrum the old fashioned way might call me names for the title of this articles, but since I run into more and more people out there who mingle both terms I think a clarification might be beneficial.

A product backlog is about what you plan to accomplish

“The Product Backlog is an ordered list of everything that might be needed in the product[…]” (Scrumguide 2013)

And it is good practice to keep these things in the bounds of the INVEST properties. This implies that the product-backlog does not prescribe how the requirements are met, but what should be achieved.

A sprint backlog is about what you plan to do

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.“ (ibid, emphasis added)

Big difference!

So yes, sorry mates, if you want to do scrum (and not scrum but) you'll have to do what used to be called ”Sprint planning 2“: Sit down and plan your work.
There are some options to handle things differently – like breaking down the board and “kanbanizing” that part of the workflow – but then these approaches might no longer be exactly what should be called scrum.

Cheers
Michael

If you can't avoid Jira, at least have an admin on your team

I used to be one of the people in favor of electronizing your task board using jira with the Greenhopper plugin – of course only after starting with a paper version first. Greenhopper has morphed into something called Jira Agile, accompanied by something called Jira Kanban.

And I have to tell you: am very weary of Jira Agile and Jira Kanban.

Especially if there is a central administrator who is in charge of the tool-handling.

Agile processes (and lean approaches like Kanban as well) almost always include a section on how to improve the process – called a retrospective in some processes or an operations review in some others.
This means that the process is meant to be changed. Often. From within the team.

Modeling the team’s process in a tool that is so complex that it makes economic sense to have someone outside the team cater for its administration makes it almost prohibitively harder to change the process.

And a lot of the admins I’ve met are so overburdened by too many projects that they have to optimize. For example by using Jira workflows (i.e. process-definitions) for more than one project. Which might be good, because: reuse!

But then I hear things like “our jira admin doesn‘t allow that” or “I think we‘ll have word on that from our jira admin in a couple of days” or “yes, we could try that – but I’m afraid it might break some of our reports.”

How is a team self-organized when they have to ask for someone else’s permission to change the process? Not so much, in my opinion.
And if they are worried that their process might break, then obviously “working software” isn’t the primary measure of progress any more.
If they have to wait “a couple of days” to find out if they can implement the process changes they came up with in their process improvement meeting, then – I would say – their process isn’t exactly agile any more.

Don’t become that team. Keep control of your process – even if that means you have to administer yet another tool.

till next time
  Michael Mahlberg

Does PDCA equal “Plan the work, work the plan (and control that)?" – I don't think so!

I don't know how this came about, but a little while ago a friend of mine (whom I highly regard, both personally as well as as a project manager) came up with the notion that PDCA implies planning, having the plan executed (do), checking the results and (re)acting if they are not up to standard.

Maybe I am mistaken and that is, what Deming really means, but the way I understand his text and for example this talk by deming himself it is quite the opposite.

The way I understand it, it is an almost direct implementation of the scientific method:

• Plan: Formulate a hypothesis and design an experiment for its verification (on a controllable scale, including the definition of an expected outcome)
• Do: Execute the experiment (in a more or less controlled environment)
• Check: Verify the results from the experiment with the expected outcome
• Act: Either implement the changes from the hypothesis or don't! – Depending on the outcome of the experiment.

Am I wrong in my interpretation?

Cheers Michael

The Return of the Mainframe and the Arrival of Cyberpunk

Back in the days people who wanted to use a computer needed to go to very special places to access those computers.
Actually "access" doesn't quite represent the same concept we have about "accessing a computer" nowadays. Today accessing a computer refers to direct interaction via touchscreen, keyboard, mouse or even voice. Back in "the old days" it meant punching holes in decks of cards (on special machines) and handing them over to so-called operators. Then you had to wait a while; hours at least, if not days, to collect the results after the stack had been processed by the computer.

A little while later time sharing online transaction operating systems were introduced and it became possible to interact directly with the machines. In a way. If you call accessing computer via a terminal, hooked up by a 300 bit per second modem line, capable of displaying 25 rows of 80 characters each "accessing."

This was the landscape of computing when the idea of a "home computer" and later the "personal computer" was born. People where just yearning to explore this world of programming and informatics and just accessing the mainframe on the terms of the owners of said mainframe wasn't giving them the freedom they wanted.

Thus the whole home- and personal-computer universe came into existence.

Because people wanted their own computers. And use them, how they wanted.

Now everybody – given the time, knowledge and still a considerable amount of money – could make their computers do what they wanted.

Let's skip a couple of decades and see the internet (and not only the world wide web) bloom. Created from all the wild experimenting, the un-feasible ideas, the "we'll see if it works", the "I think it should look like this" that individually owned, run, administered and programmed computers brought forward.

One of the biggest success-factors (the 'killer-app') for a long time was e-mail. Electronic mail that was sent from one machine to another over an intelligent network of interconnected servers. A network that found the currently best route from sender to recipient. Computers that delivered those mails based on a very simple standard (RFC 822) independently of the concrete system that was on each side of this connection.

And what happens today?

We get things like Google-Mail and Facebook that run best when messages are sent while you're using their server (a.k.a. distributed mainframe) via a Web-Browser (which is actually just a more sophisticated Terminal than that old 25x80 TTY) on their conditions.

And of course mail is just one example here – office suites that run only "in the brwoser", graphic software with "a web interface" etc. are all following the same trend.

Looks like we have the same old mainframe back in our yards – just with shiny new color and so many bells and whistles that we're (mostly) just lulled into going with the convenience of the solution. And only few people nowadays care about the freedom of their data. And guess what: some of the stuff those people are concerned about, say data security and encryption, are being made illegal – or at least hard to achieve.

For example, owning some tools which allow me to verify my systems integrity can become illegal is becoming illegal in some places nowadays and the development of such "hacker tools" has been made a public offense...

So we live in a time time where average people perform most of their information related tasks using corporation owned computers at the discretion of the corporations while system programmers and developers of safety critical software are bordering on the verge of criminalization – pretty much what cyberpunk authors predicted decades ago.

Just my 2¢...

Cheers Michael

Scrum is abstract

Over the last decade or so I found that more and more sotware developers struggle with scrum.

Especially since so many people treat agile the way it is described in the half-arsed agile software development manifesto or the dark agile manifesto.

So if I change Scrum (my process) - is it still Scrum (the approach)?

One thing that puzzles a lot of people is the fact that Scrum has to be amended past the 16 pages of it's official definition. The definition itself says so.
Yet on the other hand the battle cry of a huge body of people who call themselves agile professionals is "You are doing Scrum-But."
So where does that leave the teams? Torn between "Inspect and Adapt" "Responding to Change" and "Don't do Scrum-But."

Is it Scrum-But, Scrum-And or something completely different?

Of course it is possible to philosophize about this question a lot, but for the experienced software developer it should be easy to grasp. If you have a background in "clean-code" (as Uncle Bob calls it) or are familiar with the SOLID principles for other reasons the following picture says "it all": (metaphorically speaking)

If you look at it as a programming construct Scrum is an abstract class – it defines behavior, data, interactions etc. but some parts are just defined via template methods and stuff has to specified for the concrete implementation.

And for the concrete implementation it makes sense to apply the same rules that make sense when designing object oriented software.

So your subclass should only interact at the designated points without meddling with the innards of the superclass (OCP Open Close Principle). And your implementation should be usable wherever the super-type is usable (LSP Liskov Substitution Principle)

I'm not sure about the other aspects of SOLID, but transferring this thinking for the LSP and the OCP to Scrum implementation – together with the idea that Scrum is an AbstractSuperClass – helps to answer the question whether we're facing a scrum-but or not.

TTFN Michael

DevOps – Karl Marx to the rescue?

Karl Marx made a very distinct point on the fact that in certain societies the means of production are not in the hands of the workers.

Whether the means of production should be in the hand of the society (or the state) is a question beyond the realms of this blog, but one thing I have come to experience over and over - not having the means of software production (i.e. computers and operating systems) in the hands of the developers is a surefire way to extremely inflated development costs.

In software development the means of production need to be in the hands of the workforce

What is so special about computers and software developers?

Who “owns” the computers in software development?

In my work I have come across numerous organizations of all the different sizes, but one thing most of them have in common – even a lot of the smaller ones – is some specific department responsible for the supply of hardware. Especially computing hardware. In a lot of cases these departments are also responsible to ensure that the computers work.
What could be wrong with that? A dedicated department of highly specialized people taking care of the computers for the rest of us. Well... the problem is in the details of course. Developers are unlike normal, “average” workers. While the biggest part of the workforce uses software, the developers create the software. While the biggest part of the workforce is using the computers as tools, the developers are using them as material (well, and also as tools, but there is a fundamental difference in the approach).
Now the problem is that – more often than not – the department supplying the hardware is treating software developers just the same way they are treating the rest of the workforce. And that in turn leads to dire problems.

So what's the problem?

• A software developer, developing software that will be installed eventually has to install that software on his own computer numerous times. It is bad when they have to wait for someone for the “IT-Department“ to enter the password each time they try to do that. (real story)
• A software developer will have to stop running programs on servers from time to time. Is is bad if they have to create tickets in the customer service system to have the "IT-Department" issue a command to stop a process (true story)
• A software developer has to explore new tools from time to time. It is bad if he has to go through a lengthy clearance process to get the permission to install a trial version. (true story)
• and so on...

DevOps to the rescue?

What I noticed about the DevOps movement in the first couple of years, DevOps tried to bring exactly this (or rather: the cure to this) to the development teams – the capability to really own their machines and employ their means to the full extent of their education. (After all they are highly trained professionals in terms of computer usage)

I wonder if that is still the focus of the current DevOps movement. I am skeptical, but I strongly hope so.

So... do you own your means of production? Do you want to? What can you do to get there?

till next time
  Michael Mahlberg

How to find the cards

When teams turn towards kanban as a process control method I often see people standing in front of the board asking “Where the #*$+%+ is the card with task #12345?“

Is that a problem of physical boards?

One could easily argue that this is because it is much harder to find a card on a board than it is by using an electronic search engine.
And I guess that is true.
But that is not the problem here. In my opinion the real problem here is that the board is not yet used as a tool but only as a reporting system.

If you use the board as a tool you never have to search a card

If you use the board as a tool to drive your work it is hard to image a situation where it would be necessary to really search a card. Since you would be working on one, and only one topic at a time you would know exactly where the card you’re working on right now is. And when it’s finished you would move it to the respective «done» column and select a new card on the board according to the station you're working on and the prioritized cards on the board.
In most cases that card would be the topmost card in the «done» sub-column upstream from the one you're going to work in. And once you select this card as your new item to work on, you would move it in the «doing» column of your selected station (e.g. development).
Since this is the card you are working on (perhaps together with somebody else, but in your responsibility) that card won't move on it's own. So you know exactly where it is. So once you're finished with it you would move it to the respective «done» column... (see above)
Rinse and repeat.
No need to search for a card.
Unless you let your work be driven by another system – then of course the question arises “which is the leading system?”

till next time
  Michael Mahlberg

We don't do sprints any more ...

... we do iterations instead.

A couple of month ago a client of mine started with an effort to work in an agile way – inspired by scrum, as far as possible.

One of the first things we agreed upon was to avoid scrum-speak whenever possible. For example we don't (yet) deliver (potentially) working software to the end-user at every iteration. So we do not call the iteration a sprint.

There are many other things –like not having a truly cross-functional team etc.– that would make it a plain lie to say that we are using scrum in this project, so we don't call it scrum. We don't call the process-coach a scrum master and so on.

The surprising by-product: better communication

The most fascinating thing here for me was the effect the wording had on upper management. "Cancelling a sprint because the sprint-goal is no longer attainable" is somewhat hard to discuss with people outside the agile world without some in-depth discussion of the terms. "It makes no sense to continue with this iteration because the thing we wanted to achieve with it is no longer achievable" is much easier to grasp.
[Language remark: And this was German by the way – for those who know the language "Wir müssen den Sprint cancelln, weil wir das Sprint-Goal nicht erreichen" is way harder to understand for outsiders than "Wir brechen die Iteration ab, weil das Iterations-Ziel unerreichbar geworden ist"]

There is an adage from Jerry Weinberg wich comes to my mind here:

«If you call the tail of a dog a leg – How many legs does the dog have? Still only four – just calling the tail a leg doesn't make it a leg!»

So, how about you? Do you do Sprints? Do you do Scrum? Do you have a Product Owner? Really?

Why not try an experiment? Instead of using vaguely fitting terms from a process framework, start using terms that describe what you’re doing in “layman's terms” and see what happens.

You might spark a whole new conversation.

till next time
  Michael Mahlberg

Don't neglect software craftsmanship

Even though the software craftsmanship manifesto doesn’t really stand on it's own (it just adds to each of the values from the first page of the agile manifesto) the general points made there are now more true than ever.

In Germany alone for example the number of people writing software doubles every 3 years. That means half of the people writing software in Germany have less than three years experience in doing so.

Three years is exactly the time it takes for a baker in Germany to get through his apprenticeship and become a “Bäckergeselle” (a journeyman baker). Same for a carpenter.

In the kind of crafts where there still is an apprenticeship-period those three years are spend honing the relevant craftsmanship-skills – is the same true for software-developers?

How much time do you spend on honing your craftsmanship?

Books like “The pragmatic programmer” or “Clean Code” do a great job in explaining how software craftsmanship can be embodied – but how often do we take the time to follow their advice?

I don't know for sure about other countries, but at least in Germany there is the non-profit organization softwerkskammer which is dedicated to fostering software craftsmanship through activities outside work but focusing of professionalism in the area of software development.

And with an area that moves as fast as ours and with respect to the Japanese mindset of keeping “A Beginners Mind” all of your life, for me it pays off to be active or at least participate in such an organization.

So – have fun with your local chapter of the closest software craftsmanship organization.

till next time
  Michael Mahlberg

Blocking it to get free

Product development can greatly benefit from the Kanban-practice of ‘managing flow’.

Let’s look into one aspect that seems counterintuitive, but helps a lot in managing flow – the option to mark ongoing work as blocked.

Even if only the first core property of Kanban – visualize the work – is implemented, the agreement to mark stuck items (items that can’t be worked on right now) in a highly visible manner sends a very recognizable message to anybody looking at the visualization.

Having a blocked Item in the system means that there ‘is a disturbance in the flow’ and thus work downstream – and upstream – of this blockage might be affected. When the disturbance is highlighted and openly visible, all parties involved can act in their own area of influence to handle this disturbance. They might decide to delay some work, swarm to get the blocked item unblocked, or find completely new ways to get rid of this blockage.

Therefore marking a work-item as blocked in a Kanban system is a powerful measure to get the system free again and get the ‘flow’ flowing – leading to less work in progress and thus to shorter lead times and effectively a shorter time to market.

How do you handle tasks you can't work on right now? How many people can really see that the flow is ‘impaired’?

till next time
  Michael Mahlberg

The difference between bugs and requirements – and how to handle them

What's seems evidently different for some people might appear identical to others. Let’s see how different bugs and requirements really are.

There are different ways to look at this question...

By definition

If you look up the definitions of at the terms “bug” and “requirement” they may seem only vaguely similar, clearly distinct

Bug: “A [...] bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” Software Bug, Wikipedia

 

Requirement: “1) A […] capability needed […] to […] achieve an objective.
2) A condition […] that must be met […] by a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3) [omitted]” IEEE, via Wikipedia

By point in time

But if you look at them by the point in time when they become manifest, they become a bit more similar.

A thing (like maybe some ‘feature’) that is not ‘available’ now, is just a requirement: “Cars should have visible (blinking) indicators that show where they want go” was a requirement before indicators were invented.

A thing that has been there once, but subsequently has disappeared, sometimes is a bug "That car's indicator should blink" is a bug report for a car on the road today.

So in some cases whether you look at a bug or a requirement just depends on the point in time you're at.

By reaction

When one looks at bugs or requirements with regard to the possible ways to handle them it somehow pays off to be sure who is looking. For now lets focus on the customer (product owner, product manager etc. – the person who pays for the things that the development team spends time on).

I don't see any reason at all to react differently – except with regard to further context.

Given that a so-called ‘bug’ surfaces in an already published piece of software that is used regularly the fixing of a bug has to have some budget allocated. And obviously it needs to be prioritized. From a business point of view this means that fixing a bug just is fulfilling ’a condition that must be met to satisfy the formally documented desired behavior’ for this bug ... sounds familiar?

If, on the other hand, the bug surfaces during the acceptance phase of a feature (or ‘system capability’) the situation is straightforward. Since the error wasn't present in the previous version of the software the new feature can't be accepted. The instruments of the respective process should be used to remedy the situation. That could be blocking the work-item, swarming, stop the line etc. – each way the error has to be fixed before the new feature can be accepted. Not a bug – just a requirement that has not yet been met.

By common (agile) sense

Now if we believe in test driven development (tdd) we start implementing each thing by writing some tests that tell us when we are done. If we follow behavior driven development (bdd) we might be able to map requirements directly to one or more bdd-specifications. Which we write first, before we implement the capability.

The first thing we do with a bug is to check whether we can reproduce it. Some people then write a test that demonstrates the bug. (according to the rule, that you just don‘t write any code that isn't required by some broken test)

So bugs and requirements are both firstly described by a test that is ‘red’ (or breaking) and then implemented – not much of a difference here.

By work item type

Now this a thing that even in my opinion justifies to differentiate between a bug and a requirement – or isn’t it?

I think in some cases bugs (from a system that is already in use) are different from other requirements in the ratio between size and value. So while most system capabilities that can be described by user stories are comparatively expensive while bugs sometimes are cheap to (e.g. with little effort) fix and yield a high value by making the user experience much more enjoyable (for example if they don’t have to confirm erroneous error messages any longer).

There is no bug

In the end a bug just is special kind of requirement. And when and whether to fix it should be a business decision just like any other prioritization of requirements. For a web-based shop-system that has the bug “’stay logged in’ doesn't work” and a feature request “Add the capability to use the most commonly requested credit card” the decision what to do next might very well favor the feature over the bug. From a business perspective it might be acceptable for a while if users have to re-enter their credentials every time, even though they activated the “stay logged in” box while not having the capability to pay by credit card can be a real problem for the business.
Some bugs are quite easy to live with, while it’s really a nuisance to live with some unmet requirements.

So – how do you handle your so-called bugs?

till next time
  Michael Mahlberg

Keep your product in ship shape

Originally ship shape meant to adhere to the standards of tidyness and alertness necessary on seagoing vessels of the old times, where things tended to get turbulent from time to time.

Nowadays, with paradigms like ship it or the famous potentially shipable product increment another meaning emerges, at least in my perception.

Don't strip the headlights to get the tail lights working

When I was much younger than today I used to repair my cars myself. Partially out of interest, partially out of distrust towards the garages and partially because of financial restrictions. And of course, because in those days it was still possible to work on ones own car.

One of the things we used to do when some part didn't work was to exchange it with something that did. (duh!)

For example one time when the headlights where not working me and a friend tried a variety of things – after exchanging the bulbs and some tweaking with the wires we finally concentrated on the fuse which looked fine. But to make sure, we exchanged it with a fuse we knew to be in working order – the one that was wired into the headlight circuit.

And sure enough the taillight lit up. So we changed everything else back to the original state – bulbs and wires and all. Or so we thought.

The one thing we did not change back was the fuse. Silly – we simply forgot.

Happy to have working taillights again (the bug was fixed) I drove home. Almost. At least as far as the next police station, where a friendly officer motioned me to stop and explained that I could not drive with a car with only one headlight.

Today I see this happening with software all the time – people fixing just the problem at hand, without realizing what havoc they bring upon the rest of the system.

So please – whenever you “fix” a piece of software: Make sure that you can still ship the whole system.

My car was definitely not shippable at that time – make your software-craftsmanship better than the car-mechanic handywork of an untrained teenaged boy and keep your product in shipshape. In a state where it can be shipped to the real customer all the time.

till next time
  Michael Mahlberg

The next big thing...

... probably won't save your project.

If you have seen the Gartner hype cycle model you are probably familiar with the terms “Peak of Inflated Expectation” and “Trough of Disillusionment”

Gartner Hype Cycle Model

While the hype cycle model itself is heavily debated and criticized, I for one see that a lot of “new things” follow this kind of adoption curve.

But why is that? And why is it so common around things as diverse as programming languages (e.g. Java), Infrastructure (e.g. Build Servers), Methods (e.g. eXtreme Programming) and techniques (e.g. test driven development, TDD) to name a few?

What works for Early Adopters doesn't have to work for everybody

One reason I have seen for this is the simple fact that tools in the hands of experts can become menaces in the hands of laymen. This is not only true for things like the beautiful Katana (a Japanese sword) a friend of mine inadvertently used to cut an artery in his arm. No worries: he got treated real soon and has no lasting injuries. And the tatami (floor mats) got cleaned as well by now.
But back to the question at hand – other tools are also often quite dangerous in the hands of the “non-expert.” While it is hard to injure yourself on the sharp edge of the Java programming language, it still is quite possible to use it in a harmful way – for example by over-using mechanisms like reflection, a powerful feature that makes it possible to change the program from within while it is running or change the accessibility of parts of the software.

In my experience this is what happens when the tool reaches the “Trough of disillusionment” – badly trained people start cutting themselves too often and the effectiveness of this tool for the masses becomes a subject of discussion.

In Iado (an art of moving the Japanese sword) there are several ways to avoid the self-injury of the novice swordsmen. They either use a Bokken – a wooden sword look-alike – or a Katana-like thing with a blunt edge, the so called Iaito.

This, to me, seems to be what happens, when these tools reach the “plateau of productivity” – they get blunted down to make it harder to injure oneself.

And of course it works. In a way. With their blunted down instruments, it is much easier to let more people with less training do jobs similar to the ones that the early adopters did. Those early adopters whose efficiency with these tools made the tools so compelling.

But there is a drawback – with a Katana you can easily slice through a steel plate (for example). You just can not do that with a Iaito.

So please – if you use the blunted down version of a tool – don't expect it to still work like the real thing.

Adjust your expectations and always take into account who is wielding the tool.

till next time
  Michael Mahlberg