Also see my other blog on Wordpress : Stochastic Thoughts
Why Stochastic?  Since a in a stochastic system the next state is determined both by the system's predictable actions and by a random event. A bit like life. Or me. 

Innovation Technique: SCAMPER

SCAMPER stands for
Substitute
Combine
Adapt
Modify
Put (to other purpose)
Eliminate
Rearrange

When you have several ideas in the the general areas, trying each of those strategiesto create variants may hit on the nail with a variant that makes sense or works well.

Innovation Technique: HIT matrix

HIT stands for Heuristic Ideation Technique.

The critical observation is that new products are often a combination of two (or more) of existing products.

How to:

• Choose existing products (not too similar).
• List Characteristics / features that make out the item.
• Create a matrix. For each 2 - feature combination, evaluate the benefits of combining the features.

E.g. Scratch resistant pan + Car paint leads to considering 'scratch resistant car paint'

Innovation Technique: E/R/A

Eliminate, Reason, Alternatives.

For an existing process or product, choose several important features or aspects, and answer:
1. Can we eliminate the feature?
example: "credit card and signature is carried with you"
Usually - no
2. Reason - why can't we eliminate it? what is the crucial benefit provided?
Example: "Credit cad possession and signature used to authorize purchases"
3. Alternative(s): How else can wee achieve that goal?
Example: "use fingerprint to identify credit carrier"

Doing so for multiple features may hint at areas of innovation.

What is 'Rude Q&A'

Rude Q&A is a process I commonly encountered in Microsoft.
The idea is to prepare for difficult and possible hostile questions as part of the review of a product, design, or presentation.
Ask yourself - what are the meanest, smartest people going to ask you?

Rude Q&A is not just about testing the quality of your ideas. Rude Q&A forces you to think though your feature set, requirements, customers, and market assumptions.

Tips:

• If you introduce 'rude Q&A' in someone elses' design review preparation, be sure to explain the "rules of the game" to not surprise by standers.
• You may want to reserve part of the Q&A time for 'Rude Q&A' after other questions have been answered.
• Make sure to include questions that are unfair or based on erroneous information
• The hardest part can be coming up with the questions.

The challenges of a software API Design

Designing APIs poses multiple challenges, among them:

• APIs are targeted at developers
• APIs have 'stickiness'. A bad APIs is a nightmare for years as many internal and extenal apps depend on it.
• APIs are shared by many applications, so problems can impact multiple applications (differently)
• APIs must be discoverable, intuitive, and use consistent conventions
• Versioning and backwards compatibility on change
• Good (and updated/correct) documentation is required
• Likewise, automated testing is required

But there are benefits for exposing APIs even internally:

• hide implementation
• reuse code
• reduce duplication
• easier to optimize

Exposing APIs externally has many market benefits that we'll discuss separately. Just note that all major platforms (Facebook, Linkedin, Windows/Win32) are really APIs; and being a 'platform' can be very beneficial to a provider.

Good Writing using the Madman Architect Carpenter Judge system

Write in four phases

Madman 
- jot down all ideas
Architect
- look at your ideas. try to think of a sensible order. identify three main points
- now you have an outline
Carpenter
- rapidly, write down paragraphs in support of the outline
- don't edit in this phase
Judge
- Now review everything you wrote, and try to judge it
- How would someone who is not friendly to me look at it.
- Would it look self serving? insincere? am I making unjustified claims? etc..


HT to guide to better business writing

Optimize Your Life with Lean Software Development

Lean (a concept in manufacturing optimization, and now in software development) has some general 'life-lessons', focusing on "Add Nothing But Value - eliminate waste".

* Eliminate Overproduction
In software, unneeded features.
In life - eliminate hoarding, interruptions, unneeded focus? or is this stretching the analogy too far?

Innovation Technique: Job Scoping

For a specific Job To Be Done, try to answer:
1. What is a broader problem, and why it is important
2. What is a narrower problem, and what is the barrier that makes this narrower problem important to the JTBD

Do those answers provide any useful insights?

Internal vs. External Quality

Internal vs external quality OR why software design matters.
 Internal quality (known bugs, code quality, design, extensibility, refactoring) doesn't matter to the customer NOW. The customer may not be able to conduct any (blockbox) tests to determine the internal quality of the software anyhow, so it may as well not exist.
So... marketing/management may be tempted to concur.
They would be wrong... because, in time code quality impacts the bug rates, performance, cost of development of new features, and time to market for new features. The current code base results in debt. Like all debt, you can pay off the principal early or pay off the interest on an ongoing base. Either decision is fine in some circumstances, as long as it is the right decision for the organization
==> more important to keep the changing and critical areas 'clean'.

Sources of tech debt
=> some debt is taken by design
==> some by being reckless
===> and some debt is only visible in retrospective as we learn more about the problem space.

Predicting the next new song

A few interesting questions in the cross of 'big data' and music:
1/ Predicting the next song a -particular- user will like. (e.g. Pandora)
2/ Predicting the next song that will become popular
 Last I heard, Pandora uses analysis of the music itself. But there is so much data out there:
* The singer
* The Lyrics
* Social networking and google mentions
* Radio plays
* The label (is a valid datapoint)

Innovation technique: Nine Windows

consider the matrix {past,present,future}x{supersystem,system,subsystem}. Fill in center(present,system). Complete the grid. Observe for insights.

Innovation Technique: Outcome Expectation

1. Identify Jobs To Be Done 2. Identify 4 quadrants: desired/undesired outcomes to client/provider 3. Create outcome statement: include the direction of action (minimize/maximize), unit (time/cost/etc.) object, and context. e.g.: "Decrease the likelihood of delayed customer orders" Software Industry Relevance: Often there are 3 players: the end user (functionality), the provider as a financial entity (monitezation) and the provider as a technical entity (design integrity). You need to recognize those disparate needs and identify what each role/entity preferences are. Based in part on The Innovator Toolkit

Innovation Technique: JTBD (Jobs To Be Done)

Jobs To Be Done: Instead of focusing on what you are doing, focus on the jobs your customers (internal or external) are trying to accomplish. Instead of improving the lawnmowers you are manufacturing, maybe you should genetically engineer grass? (the job to be done: keep lawn looking tidy). Software industry relevance: similar to User Stories, but much more higher level than most people use User Stories. Based in part on The Innovators Toolkit

Personal website redesigned

My personal website underwent some modernization. Let me know what you'll think!

Twitter - at last.

For short and succinct words of wisdom... use a dictionary. For everything else, there's @yanivpessach

Distributed Storage eBook available

Good News Everyone! My 'Distributed Storage: Concepts, Algorithms, and Implementation' eBook is now available on Amazon. The eBook is a short introduction to the topic and is targeted at the academic level as an introduction to the topic.

Agile, Scrum, And PMI project management

As both a Scrum Master and a PMP-certified project manager, the conflict between these two approaches is something I have to deal with on a daily basis.

I noticed the guys in SprintPlanning.com are offering a free agile and planning online course about it. Worth checking out.

The most important part of Scrum

There is an ongoing debate in the agile/scrum community about 'what aspect of scrum is most important'.
Obviously, the most *recognizable* aspect of scrum is the daily stand-up meeting. But - is this meeting so important? I've seen and ran Scrum teams that skipped the daily standup, had a daily standup meeting twice a week, or otherwise modified the ritual. And they worked well.
In my opinion, the two most important concepts in scrum (which are general Agile concepts), are *timeBoxing* and *adaptive iteration*. This is why I think the Sprint Planning meeting is the most crucial - this is when planning ofr the next iteration, taking into account changes that need to be made, takes place.
It is true that much of the 'lessons learned' are acquired in the *sprint retrospective* meeting, if it is held. But without incorporating this information in the next sprint planning session, the retrospective degrades to nothing but a 'whine session.

The scientific method to Unit Testing

For many, Unit Testing is how we prove to ourselves (and others) that our code works, at least initially. And yet, many unit tests fail to find the very reproducible, localized bugs they were to prevent. One reason this happens is our natural tendency to create unit tests to prove that our code works, rather than to prove that it fails.
The scientific method suggests the opposite direction. A claim is scientific if it is falsifiable .
A good unit test (and a good acceptance test) will try to prove the code wrong, by including as many edge cases as possible, and by challenging the code invariants.
Good testers know this, and spend much time looking for edge cases. But we developers should keep the same mind-frame, and try to prove our own code wrong.
It's OK.
If the code is proven wrong by your unit tests, you just fix your code. You didn't check in code before writing your unit tests, now did you? :)