Pivots are a Trap
blog.thirdyearmba.com
blog.thirdyearmba.com
One thing I learned is that while your vision should never change, you should keep trying different strategies until one works
And yet, the definition of a pivot, as given by the person that made the term widespread is very similar[1]:
A pivot is a change in strategy without a change in vision
And the author, at the end seems to actually agree with it:
But it's important to realize that taking different bites of the same apple is very different from biting into an entirely new pear or banana, and it seems like a lot of people are actually doing that
So I guess he is actually warning against one interpretation of a pivot, that is change in vision.
[1] http://www.marywisemandesign.com/pivot-change-the-strategy-n...
To me, it's about cleaning up code in order to make it better-architected and (often) smaller, so there are less opportunities for bugs, and it is more extensible. Are there other uses I'm unaware of?
Nowadays people seem to use "refactoring" to mean "changing code without adding new front-facing features." This is bad as it causes large, scary changes to fall into the realm of "refactoring." Refactoring, if you want to live by its original definition, should be a relatively mindless, safe series of small well understood steps.
If that's not called refactoring, what is it supposed to be called? I would hate to use terms like "cleaning up code" or "improving code" because they're so horribly vague (they could be about merely changing tabs to spaces, or include adding whole new features).
Suggestions?
Here's an example of someone using it wrong: "We are going to refactor the API call to have 5 parameters instead of 4." The word they are looking for here is "change" or "extend", and they're falling back on "refactor" since they think it makes them sound smarter.
That is not incorrect but for it to be true refactoring you would have to add this:
You extract (or refactor) all the duplicate pieces of code that are performing the same functionality and merge them into (or replace them by) a single module.
That is what refactoring truly is.
Refactoring all really started with Martin Fowler's book way, way, way before the IDE driven refactors were available and there are plenty of things that he describes in there that have no chance of being automated.
Where on earth you picked up your 'traditional definition' I do not know. I recommend reading Martin Fowler's book.
The vision, or core motivation, never did change though. There's a common thread through all four pivots. In fact the current product looks most similar to the very first. But it's different in important ways that weren't known during pivot 1.
Here's the full story http://jmtame.posterous.com/this-is-how-you-actually-teach-p...
SocialCam as well. Definitely a pivot for us.
The most obvious difference? We have a partner program to help encourage an ecosystem of professional casters and players to form. We never would have built that for Justin.tv.
I believe that a common reason for changing direction early is that founders learn a lot about their problem in the first three months. Sometimes they learn that it's the wrong problem for them to tackle. It could still be a great business, but not a good fit for the founders. Prior research can reduce the chance of a "gotcha," but often you must interact with customers to really understand the problem. Yeah, customer dev techniques can speed this up, but it's a process that takes time regardless.