Fang Bo B2X Table Tennis Blade

Now for a recreational break...

I used to play table tennis in uni, but hadn't played in decades.  Recently, my interest got fired up (I don't recall why). 

Today, I received my copy of a Double Happiness (DHS) Fang Bo B2X blade (B2X). I wanted to try out an ALC blade but didn't want to spend much.  The most popular ones, the Butterfly Viscaria, and Timo Boll ALC, the DHS Hurricane Long 5, and others, were too expensive for my needs. The B2X fit the bill. 

The internet chats say the B2X plays very similarly to the Hurricane Long 3, at 1/3 of the price, and of reasonably good quality ("the Hurricane Long without the quality control", some say).

The Setup: B2X,  Forehand: Hurricane 3 (H3) Hard Black 2.2mm. Backhand: Hurricane 3 Hard Red 2.2mm. But rubbers are unboosted, both are the commercial version you get from tabletennis11.com.   I had tabletennis11.com assemble the racket. I also asked them to lacquer the blade.  I don't bother boosting since I no longer play competitively, and can't be bothered with the routine.

I have two other blades that also have H3 on both sides, all 2.2mm, all unboosted, so I can do some comparisons. I have a Donic Person Powerplay (DPP), and a Yasaka Extra Offensive 7 Power (YEO7P). 

My YEO7P has 'H3 Hard on the forehand, and regular H3 on the backhand, and my DPP uses regular H3 on both sides.  I actually couldn't notice much difference between H3 Hard and H3 regular, except that H3 Hard is 'not softer' than H3 regular.  If I didn't know one of the rubbers was Hard, I wouldn't know,  so it probably doesn't matter.  Maybe the difference shows up when you boost them, which I don't.

The B2X comes in a silver sturdy cardboard box that locks magnetically.  This case a big step up from the flimsy carboard box that comes with Donic blades, or the transparent plastic case that Yasaka blades come with. However, the case is really irrelevant. If you're not a fan of Fang Bo, you might be a little uncomfortable about his large photos on the outside and inside of the box.

Thankfully the B2X no longer comes with Fang Bo's face at the bottom of the handle. The cheap looking plastic seal is still there, but the design is an outline of a trophy.

In most cases, tabletennis11.con usually does as exceptional job assembling my rackets. Whoever assembles the racket there has some superpowers. But he made a minor mistake. He attached the black rubber at the back of the blade, and the red at the front. This is a minor thing because both sides of the blade are the same.  However, the plastic seals on the blade handles, the orientation of the trophy at the bottom of the blade, and the serial number imprint on the side of the blade make it unmistakable (albeit easy to miss) which side is forehand and which side is the backhand. Superpowered, but mortal.

Quality of Workmanship

First, quality of workmanship. The handle and neck of the blade is quite well polished. Not as well polished as Donic blades, but it is smooth. There's no need to sand them. (I received the blade with the rubbers already attached, so I can't comment on the quality of the blade face). 

Playing Impressions

On soft play, the feel reminds me of my DPP, which is a wonderful blade.  Maybe not quite the same as DPP, but way closer to DPP than YEO7P.  The B2X has significantly more vibration than the DPP in soft play. At first I was underwhelmed with the B2X.  Why would I need it if it plays like the DPP?

On harder hitting, I feel like the B2X has more power to give than even the YEO7P, especially in looping. It feels both sharp and at the same time solid. The ball travels faster when looped or driven by B2X. The YEO7 has a walnut surface and feels hard and stiff. It feels very different to the B2X.

With the B2X, all my loops against a lightly overspin serve went waaaay past the table. I had to really close the angle (almost 0 degree, almost perfectly horizontally, it feels like!) before my loops went in. Each time I open the angle a bit, the ball flies off the table again. 

One negative thing is the handle. For some reason, it hurts the inside of the second joint of my index finger. It's not because of any roughness in the blade handle; as I mentioned, it's quite well-sanded and smooth. The problem has more to do with the shape.  The blade face widens up a more slowly than my Donic and Yasaka blades. I never had this problem with Donic, Nittaku, Yasaka, Tibhar, or Butterfly, and never realised a problem like this was possible.

My finger hurts when I use my normal grip with the B2X. I have to hold the blade further down the handle, kind of like how Ma Long holds his blade, with the bottom half of my thumb on the crescent top of the blade handle, and the upper half on the rubber.  I'm not sure if I will adjust my grip or if I should look at shaping the blade -- I don't know how I would do that.

One of my favourite blades I have is a Donic Waldner Legend Carbon (WLC). This blade has a fantastic soft and crisp feel to it.  I want to compare it against B2X to see which one is more powerful.  The WLC seems has a thicker carbon layer than the YEO7P and feels much more carbony than YEO7P (but the hinoki surface gives it great control). My WLC has Friendship 729 Super FX on both sides, so any comparison with the B2X will have to be mindful of that difference.

At this stage, these four blades play differently from each other, and I have no favourites. I like them all.

I will continue to update this as I get more used to the blade.

Juran on Quality by Design (Chapter 2)

Reading Chapter Two of Juran on Quality by Design (paid link)

Chapter 2 "Establish Quality Goals"

NOTES

A goal is an "aimed-at" target. A quality goal is a quality target you are aiming for. The goal would typically include "a number" and a "time table"

Some consider that setting quality goals is part of quality planning, whereas others have the view that quality goals are set outside of quality planning -- the purpose of planning in this case is establishing how to achieve the quality goals.

A vision has no connection to reality until it is translated into quality goals.  Planning is impossible until goals are established.

Tactical quality goals refer to goals designed to meet human (customer) needs. These include product features, process control features, etc.  They are set by middle management in order to meet the strategic goals.

Strategic quality goals are set at the highest level of the organisation. They are often driven by the company's strategic vision and policies. Examples of strategic goals are: "Improve product and service quality ten times (Motorola)", and "Reduce billing errors by 90% (Florida Power and Light Company)". 

Upper management should not become involved with individual tactical quality goals as there are too many, but they need to be involved with them at the 'collective' level.

Quality goals do not only come from customer needs. They can be driven by a company's concept which may need to be marketed to customers (an example is Walkman, which no customer 'needed' or asked for). Goals can originate from regulations, or from internal human desires to be meticulous.

Some of the most important bases of quality goals:

• Technology - in the form of specifications and procedures
• Market - quality goals that affect saleability should be based on the market
• Benchmarking - quality goal made with reference to what other companies are achieving
• Historical - performance in the past is used as the basis for performance in the future. Sometimes the goal is to improve on past performance. Sometimes the goal is ensure stability with past performance.  This basis can be a double-edged sword.

Quality goals are a hierarchy. Primary goals are at the top. These include 'personal health' or, for a car, 'effective transportation'.  Secondary goals are essential in achieving the primary goal, tertiary goals help achieve the secondary goals, and so on until each sub-goal is achievable in technological terms.

Planning is an essential part of achieving generating and achieving quality goals. Planning helps identify what sub-goals are needed (by asking: how can we achieve the primary goals?) and how each sub-goal can be achieved.

Deployment of Quality Goals

'Deployment' means allocating the goal to someone who will deliver the goal.

Strategic goals are subdivided in smaller and smaller sub-goals which are then allocated to someone (eg a middle manager). In Japan, that someone determines what resources they need to accomplish the sub-goal. This arrangement enable participative two-way planning.

Strategic goals are too big and systemic to assign to one person. However, it is imperative that every goal be 'deployed' (ie, allocated). One solution is 'teams'. A team is formed and assigned to deliver the goal. The example mentioned in Chapter 2 is 'Team Taurus', tasked to deliver the strategic goal of making Taurus quality best in class.

Provision of Resources

Goals need resources to achieve them. A key blocker to achieving strategic quality goals is the non-provision of resources to achieve them. The practice of developing strategic quality goals seeks to reuse the existing practices in business. Businesses have processes to allocate resources to define, administer, and delivery business goals.  Strategic quality should be approached the same way.

Corporate Interference

Expect resistance from various areas of an organisation when developing strategic goals. The key cause of resistance is the reduction in autonomy of the various divisions and functions. Strategic goals are directions from above, plans to achieve them by the divisions are approved from above, and people from above will be monitoring the division's achievement of those goals.  All three aspects are reductions in the autonomy of the division, and can cause friction, even in the most harmonious relationships.

Idenitfying the Customer

It's curious that Juran says the "next step" after establishing the quality goals, is identifying the customers.  It seems counterintuitive. Wouldn't you need to know your customers first before meaningful quality goals can be established?

Software Development Tools

 A job ad for a software engineer listed the following tools. I'm not familiar with half of them (not even by name).  Writing down the list as I'm curious to do some digging and find out what each are:

• Jenkiins (a continuous integration and deployment framework)
• AWS Cloud
• Azure
• Splunk (for logging and metrics)
• App Dynamics (for loggin and metrics)
• ECS
• Github
• Artifactory
• Kong
• OAuth
• Serverless technologies
• Node.js
• Automation
• Ansible
• Terraform
• Python 
• Java
• Linux
• CloudFormation
• RDS
• PostGresSQL
• NoSQL
• Angular
• ReactJS
• GIT
• Spring Boot

Make Up Your Mind (Chapter 2)

I have quite a number of books in my library, virtually all of them non-fiction. I'm starting to think there's not enough time to read them all. Skimming each one doesn't really help me absorb them, so I thought it might be interesting to explore the books by reading Chapter 2 of each.

Today's book is Make Up Your Mind, by Hal Mooz. The author is well-known in the Systems Engineering community as co-author of Visualizing Project Management, and Communicating Project Management.

Chapter 2 of this book is "Decision Fundamentals for Thinking Clearly". It's a short chapter and touches very briefly several topics relevant to thinking clearly.

We get a reminder that decision rigor is 'driven by the fear of a negative outcome'. This is something we all instinctly already know. We become more anxious when the decision has serious consequences (eg, which univerisity to go to), and are rightly less rigorous when the consequences are not serious (eg, what to have for lunch).

An interesting paragraph is on when do we actually 'make' a decision? Does deciding one way or another constitute making the decision or is further action required?  Some decision experts say you make the decision when you irrevocably allocate resources. (I had not heard of this before.  I think it's a good criteria). The author argues against it because it fails in some cases. His example is the decision to lose weight and deciding to eat less. Contrary to this criteria, the decider has actually decided NOT to allocate resources (food).

The author defines a good decision as 'applying informed judgment based on relevant facts and quality ethics to select an alternative and act on it'.

A short paragraph reminds us that the outcome does not define whether a decision is good or not. This is pretty much an obligatory topic in any decision making text.  Another paragraph covers another obligatory topic -- the fallacy of sunk costs.

Mooz introduces a concept new to me: 'Cost / Price of Indifference'. It is the purchase price at which you don't care (emotionally) whether you get the goods or not. He suggests this is a time saving concept when purchasing or selling anything. Rather than agonising hours and hours over how much to bid, just bid at this price.  He did not discuss this in the context of buying stock market shares. I think that will be interesting to consider. 

There are two stages to decision-making. The first is Decision Preparation. This is about getting the decision statement right, setting up the decision type frame, and the decision solution frame correct.  The second stage Deciding, which is about the act of selecting from the alternatives that were set up in the decision solution frame.  (The author didn't mention this, but I recognise this 2-stage framework as  classically systems engineering).

Other short topics covered is the decision maker's viewpoint, decision fitness, and decision fatigue. Decision Fitness is another concept I had not heard of before. This is a concept about the fitness of the person making the decision. They must be proficient at the following skills:

• Specifying the decision and context
• Determining the decision type
• Creating the decision type frame
• Developing the decision solution frame
• Creating viable alternatives
• Identifying and geting the comparative information
• Knowledgeably selecting the right judgment basis
• Skillfully applying the appropriate judgement process

A quick glance at the table of contents reveals many of these topics are covered in the rest of the book. 

This is a short book. At only 166 pages and with larger than normal font, it is misleadingly light-looking. Judging from the concepts introduced in the Chapter 2, it seems like a concept-heavy, deeply useful text.  Just considering the list of skills listed in order to be 'decision fit' shows you how much is required to be a good decision maker.  I'm not sure this thin book will be able to cover what is required to be decision fit, but if it gives exposure and awareness of the concepts, it will be worth further study. 

Agile vs Waterfall

Often heard: "What you experienced was not true Agile."

Never heard:"What you experienced was not true Waterfall."

Not So SMART Objectives

In a VUCA world, objectives must be SMART:

S – Subjective

M – Machiavellian

A – Adjustable

R – Reactionary

T - Tentative

The Real FR vs NFR Requirements

Any professional working with requirements is familiar with the abbreviations FR (Functional Requirements) and NFR (Non-Functional Requirements). This categorisation attempts to distinguish one type of requirement from the other. It's an unfortunate exercise to separate them so distinctly because FRs often need to be described with their accompanying NFRs, while NFRs are often met by implementing a set of FRs.

However, we can reuse the FR vs NFR distinction in some other ways. Proposed below is a list of the more important ones:

Fictional vs Non-Fictional Requirements – Fictional requirements are not really requirements. They are designs, solutions, or wishes masquerading as requirements.  Non-fictional requirements are real requirements.

Factional vs Non-Factional Requirements – Factional requirements are those pushed for by only a certain set of stakeholders. Other stakeholders couldn’t care less about these. Non-factional requirements are required by the system and transcend individual factions.

Frictional vs Non-Frictional Requirements – Frictional requirements are contentious, either to some stakeholders or to other requirements. They also cause friction in the system development by causing the majority of the delays. 

Fallacious vs Non-Fallacious – Fallacious requirements are requirements that are properly written (they are Non-Fictional), but aren’t what is needed. Non-Fallacious requirements are requirements that are needed.

Fundamental vs Non-Fundamental – closely related are Fundamental requirements, which are essential to meeting the objectives. Non-Fundamental requirements are 'nice to haves'. Ironically, building only Non-Fundamental requirements does not result in a nice system.

Function vs Non-Function – Function requirements are about what the system needs the user to be able to do (‘The user must be able to cancel a transaction’). The user is replaced if they cannot perform the function. Non-function refers to user attributes and capabilities (‘The user must have the ability to view the most recent transactions' -- perhaps by possessing SQL skills?)

Familiar vs Non-Familiar – requirements that are common to many systems. These include management reports, etc. Non-familiar requirements are those that haven't appeared before in the project's collective experience.

Favourite vs Non-Favourite – Favourite requirements are flashy requirements sponsored by someone. They tend to be given attention. Non-Favourites languish or are implemented and tested perfunctorily. No one notices if they run away.

Falsifiable vs Non-Falsifiable – Falsifiable requirements are those that can be shown to not exist. Non-Falsifiable requirements cannot be proven to have been met. A quintessential example being ‘The system must be user friendly’. 

Fat vs Non-Fat – Fat requirements are a clump of requirements stated as one single requirement, often with multiple adjectives.  They tend to clog the process. Too many can result in a project heart attack. Non-Fat requirements are singular, and are processed through without harmful effect.

Fiscal vs Non-Fiscal – Fiscal requirements relate to cost ( ‘The solution shall not cost more than $X per transaction’)

Filial vs Non-Filial – Filial requirements are those that can be traced to a parent requirement. They show respect, and obedience, and conform to their parents wishes. Non-Filial requirements are either orphans or contradict their parent requirements. They cause family infighting and should be made to either conform, or else be cut off from family tree.

Fecund vs Non-Fecund Requirements - Fecund requirements are prone to keep popping out new requirements -- annoying, smelly, little new requirements that need lots of care and feeding.