Craig Pardey Coder | Runner | Cyclist | Parent
I recently weaned myself off coffee. My daily intake levels were well above normal levels, as was my tolerance. The only thing it was doing for me was preventing me from getting a good night’s sleep. So I decided to quit. I spent two weeks cutting back, and then went cold turkey over the Labour Day weekend.
This is a quick cheat sheet taken from a great little book called “The 22 Immutable Laws of Marketing” by Al Ries & Jack Trout. I highly recommend this book for anyone interested in marketing … even developers!
The Law of Leadership
It’s better to be first than it is to be better.
The Law of the Category
If you can’t be first in a category, set up a new category you can be first in.
The Law of the Mind
It’s better to be first in the mind than to be first in the marketplace.
The Law of Perception
Marketing is not a battle of products, it’s a battle of perceptions.
The Law of Focus
The most powerful concept in marketing is owning a word in the prospect’s mind.
The Law of Exclusivity
Two companies cannot own the same word in the prospect’s mind.
The Law of the Ladder
The strategy to use depends on which run you occupy on the ladder. If you’re 2nd, then acknowledge it and market as an alternateive.
The Law of Duality
In the long run, every market becomes a two-horse race.
The Law of the Opposite
If you’re shooting for second place, your strategy is determined by the leader. Discover the essence of the leader and then present the prospect with the opposite.
The Law of Division
Over time, a category will divide and become two or more categories. Corollory: Categories don’t combine, only divide.
The Law of Perspective
Marketing effects take place over an extended period of time.
The Law of Line Extension
There’s an irresitible pressure to extend the equity of the brand. In the long run and in the presence of serious competition, line extensions almost never work.
The Law of Sacrifice
You have to give up something in order to get something. There are three things to sacrifice: product line, target market, or constant change.
The Law of Attributes
For every attribute, there is an opposite, effective attribute.
The Law of Candor
When you admit a negative, the prospect will give you a positive.
The Law of Singularity
In each situation, only one move will produce substantial results. History teaches that the only thing that works in marketing is the single, bold stroke.
The Law of Unpredictability
Unless you write your competitors’ plans, you can’t predict the future. Marketing plans based on what will happen in the future are usually wrong.
The Law of Success
Success often leads to arrogance, and arrogance leads to failure
The Law of Failure
Failure is to be expected and accepted. Recognize failure early and cut your losses.
The Law of Hype
The situation is often the opposite of the way it appears in the press.
The Law of Acceleration
Successful programs are not build on fads, they’re built on trends.
The Law of Resources
Without adequate funding an idea won’t get off the ground.
Me: Why is this report different to the one in production? SysAdmin: Dunno. I guess they must have fixed it production and forgot to check it back into source control.
If I had a dollar for every time I’ve had that conversation I’d be a rich man. It is usually the result of some late-night troubleshooting and finally the system is working as expected and everyone goes to bed. But the next day, nobody remembers what exactly they changed that fixed the problem, nor do they spend the time to figure it out and get it back into source control. Worse yet, they were making untested changes in a live environment - that shouldn’t be possible!.
Gone are the days when source control was just for source code. Everything required to build, package, deploy, migrate and run your application should be kept in source control. That includes source code, app configs, build scripts, deployment jobs, SQL scripts (DDL and data), server settings, smoke tests … everything.
The fact that this team was troubleshooting a release in production tells me that their deployment process is probably abysmal, so it’s easier to just change things in-situ than to go through the whole commit-push-deploy cycle again. It’s tempting to blame the people involved but more often than not this is an organisational problem. If it was easy to push new builds through the test environments and to production then then tech team would do that.
Deep down, people want to Do The Right Thing but in a low-trust organisation that means days or weeks of paperwork, sign-offs, release approval meetings and other forms of Release Management Theatre. A heavy, approval-based release process like that actively discourages the tech team from locking down production because if the only way to get code to production is through source control then they’re screwed if something goes wrong. The system will be offline for days or weeks while they wait for the sign-offs.
And then bugs that were fixed through the heroic efforts on the live servers get re-introduced on the next release because they never made it into source control. Or worse yet, the team does patches instead of full releases so that a few cycles later nobody has any idea if they can re-create the production instance from source control. Spinning up new instances involves copying the whole filesystem.
If this sounds like your environment then take a long, hard look at your release governance process. Does it encourage and facilitate rapid deployments? If not, you should start automating the release process for all environments so that production releases become boring and predictable. Start by measuring how long it currently takes from a “go live” decision to the code running in production (including QA testing and sign-offs). Now automate the longest step. Repeat.
Do this with diligence and you’ll have a reliable, reproducible system that can push fixes on short notice without relying on Brent(s).