
Lead Bullets (2011) - zbravo
http://bhorowitz.com/2011/10/26/lead-bullets/
======
aresant
Reminds me of one of my favorite quotes from Admiral Stockdale:

"You must never confuse faith that you will prevail in the end, which you can
never afford to lose, with the discipline to confront the most brutal facts of
your current reality, whatever they might be."

------
lifeisstillgood

      The customers were buying; 
      they just weren’t buying our product.
      This was not a time to pivot.
    

Carve this into the tabletops in every Starbucks in San Francisco

------
TheBiv
This was a lessons-learned post, but I would LOVE to read a "How we made those
lead bullets" post.

Because his post goes like "guy says lets use lead bullets." -> "We hunker
down and use lead bullets" -> _magic_ -> "Boom. $1.6 billion company"

~~~
marcosdumay
> "How we made those lead bullets"

Optimize something, reduce the running time by a few ms, optimize something
else, reduce by some more ms, repeat 8 hours a day, with several people in
paralel for a few months.

The concept of a "lead bullet" implies that the history won't be interesting
to read, just some repetitive boring hard work.

~~~
TheBiv
> "Optimize something"

I may be the only one, but knowing what the 'something' was is incredibly
valuable bc we all, as people, pick 'something' and not everything in any sort
of bullet is created equal.

~~~
dredmorbius
In performance tuning, this is actually pretty straightforward:

\- Processes which run many times.

\- Processes which run long time (and block other processing).

\- If at all possible: both.

The more subtle approach is to identify things you don't need to do (needless
initializations, "settle" delays, doing (or allowing to be done) the _wrong_
thing requiring both unwinding that operation _and_ doing the right one, and
anything you don't have to wait for (if it's an ancillary process, spin it off
and handle it out-of-sequence). Redesigning a process to avoid sorting data.
Eliminating global locks. Spinning off tasks to parallelized processing
(especially if you have multiple cores/systems available. Pipelining data to
avoid writing/reading from disk multiple times. Handling data in memory rather
than on disk. Realizing you _can_ handle data in-memory, and that disk-seeks
will kill you, so sorting or bucketing output. Swapping spinning rust for SSD.
Specific tools such as COW, snapshots, or the like can be very useful in such
cases.

Algorithms (or methods invoking algorithms) can be another big win.

I've seen processes fall in time requirements by 90% following such an
optimization process.

------
aaronbrethorst
Semi-related: <http://www.paulgraham.com/schlep.html>

Too many people are unwilling to do the hard thing. Probably because their
"goal [is] business for the sake of business
(<http://al3x.net/2013/05/23/letter-to-a-young-programmer.html>)

------
obviouslygreen
This seems like a couple of nice anecdotes thrown together due to an
unfortunate preoccupation with a barely-related cliche.

The way I'm reading it, the point is to concentrate on your product and making
it, in reality, better than the product(s) of your competitor(s) rather
than... pivoting? Building a different product? Making your product into
something else? Changing your target audience? I guess the only real lesson
I'm taking away here is that "if you have product, sell it; if it sucks, make
it better." Not exactly groundbreaking, though certainly true.

If the desire was to communicate something more general, taking it out of the
context of existing product-based businesses with market share _and_
competitors would probably be necessary (but would have probably killed the
anecdotes... which is why I'm guessing the article didn't really get off the
ground in this regard).

So yeah, it's mostly true... but where it is, it's sort of trivially so.

~~~
tomblomfield
As you suggest, I think the point was that there's often no brilliant idea
that will provide a magical solution to a hard business problem - be that a
product pivot or a new sales/marketing gimic.

Instead, you often know what you need to do - it's a long, hard slog, and it's
about sticking at it longer than your competitors.

It's a recurring theme in Ben's blog:

>> Mediocre CEOs point to their brilliant strategic moves or their intuitive
business sense or a variety of other self-congratulatory explanations. The
great CEOs tend to be remarkably consistent in their answers. They all say: “I
didn’t quit.”

[http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-
diff...](http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-difficult-
ceo-skill-managing-your-own-psychology/)

------
coffeemug
That's a great post.

There is also the opposite problem (one much more common in newbie founders
IMO) -- seing lead bullets everywhere when a silver bullet would do. I used to
believe I can just outthink and outwork other people by sheer force of will. I
_still_ believe I can, but I would have saved myself (and my team) a lot of
effort if I learned to look for silver bullets when they fit the problem.

Telling lead from silver requires some learnin'.

------
6d0debc071
Let's be realistic here - worst case that you can do anything about: it's
possible the other side just hopelessly outmatches you in some area, and
likely always will (they've better programmers, they're allowed to use more
powerful software, they've better connections, they have enough money to put
you out of business by undercutting) - and 'maybe you don't deserve to exist'
is not a good answer to 'perhaps we should focus somewhere where we've a
competitive advantage.' Maybe you'd be really good at something else, or maybe
not - but you've the resources there and you may as well make a go of it if
you look to be totally screwed otherwise.

You need to have some realistic assessment of how badly you're losing. Gungho
"Yay effort!" is not a worthwhile risk analysis.

------
rubinelli
Here is another lesson buried in the post: in most cases, _faster is better
than better._ It doesn't matter if you have a much more stable product, with
hot swaps, integrated monitoring, auto-balancing, the whole works. If your
competitor is five times faster, you are toast.

If you look at the past decade and compare the technologies that "won", you
will see that in almost every case, they were faster than the alternatives,
and had performance as a major selling point. The notable exception is Ruby on
Rails, but it was sold so well (the original Rails screencast was ground-
breaking) and it solved such a huge pain point (XML hell) that, in this case,
it didn't matter (though even they had to answer the question "but does it
scale?" at some point).

------
mikescoffield
This reminds me of a product features framework I saw once. It mapped features
to a 2x2, which categorized features into 4 buckets. The lead bullets were
considered "table stakes" (core features that were necessary and everyone had)
and silver bullets are probably "fool's gold" (features that are distinctive,
but don't necessarily drive adoption).

------
cl8ton
Netscape towards the end was pitching to business and not consumer. Consumers
like touchy-feely-hip things (Silver Bullets), business wants things that
work. Price, Performance and Support are all that counts at the end of the
day. (Lead Bullets)

~~~
artsrc
Our business spent a fortune on a very poor performing, piece of junk,
software. Maybe the support is OK, but the real world stability sucks too.

Sometimes hookers, expensive lunches, tickets to sporting events and being
golf buddies with managers are what counts. And if those are what counts, then
those are the lead bullets.

------
saurik
related: <https://news.ycombinator.com/item?id=3155358>

------
norswap
Perhaps I am not getting the point, but it seemed that the silver bullet was
to fix the performance issue.

~~~
kcorbitt
I think the connotation of "silver bullet" in this post is an extraordinary
idea that solves the problem definitively by changing the rules. A lead
bullet, by contrast, acknowledges the current field of play and just plays it
better. Less glamorous, but still plenty deadly.

~~~
mturmon
These elemental analogies are reminding me of the Manhattan project.

One silver bullet ( _E_ = _m_ _c_ ^2 and Einstein's letter to Roosevelt) and
some lead bullets (the long slog of building huge industrial plants to purify
the uranium). Maybe sometimes you need both.

------
CurtMonash
I think I can summarize that post in three words:

"Thou shalt execute".

------
graycat
I see some lessons in the OP, but not the ones Ben intended.

Ben is saying that at times need to work very hard? Okay.

Ben is saying that if a competitor has a much better product that is selling
well and threatening own business, then likely just must do the work needed
for a competitive product. Okay.

But after that I lose it with Ben: His "lead bullets" are defeatist, close to
luddite, look like he is trying to degrade himself and his company, to fight
by getting down, dirty, simplistic, nose to the grindstone, shoulder to the
wheel, and ear to the ground and trying to be successful in that position, to
suffer first and count on that being the path to success. Not good. Indeed,
one of the things we're supposed to be doing is innovating, which likely also
means being creative, original, maybe even mathematical or scientific.

Ben reminds me of Edison sending yet another team to the Amazon jungle to look
for more plants that he could bake into carbon and try for a light bulb
filament that wouldn't burn out so soon. The real solution was to borrow the
idea of a tungsten filament from the chemist Swan in England and to use a
really good vacuum pump from a guy in Germany. Edison could have had his teams
slogging through jungles for 1000 years without finding anything. But,
eventually Edison did go with tungsten and the German vacuum pump.

For Windows' first version of IIS being as much as five times faster, tough to
believe that just a 'lead bullet' approach would yield what was missing from
what Ben had. Instead, look at the architecture and think a little about what
the heck the poor computer is being asked to do. Then look at where the
computer resources are going. Likely then, tweak the architecture: So, if are
spending time walking down arrays or linked lists in O(n), then consider using
an AVL tree in O( ln(n) ). If executing the code for a page when know that the
output will be the same as the last 10 times, then cache the output and don't
run the code again. If caching the output in main memory, i.e., virtual memory
with page faults, then consider just using disk file for each page to be
cached and save on page faults. If are connecting to a database, then have a
pool of connections. Etc.

I.e., think a little. Looks like Ben doesn't like thinking, more likely has,
really, a low regard for his people and doesn't trust them to be productive if
asked to think. Ben wants to measure hard work by sweat, long hours, and
suffering and not good work with good results.

Here's a lesson I draw: I agree with Ben that a business that has been going
along well might suddenly encounter some problems, e.g., a five times faster
competitive product given away for free.

First, such problems should have been expected. If Ben had inefficient
software, then he should have known that and not had to learn it from a
Microsoft product. Or, how and why did the Microsoft people do a much better
job? Sure: They wanted something fast, at least not wildly inefficient,
thought some about the architecture, and did a decently efficient
implementation. Why? Because they cared enough. Then before Microsoft's work,
Ben hadn't cared enough.

Second, Ben should have done much better trying for, expecting, counting on,
working toward silver bullets. I sense that Ben doesn't much believe in silver
bullets, suspects that any efforts toward silver bullets will be just time and
effort wasted. Bluntly, I seriously doubt if Ben knows how to direct a
productive, creative, effective little applied research project. Ben reminds
me of the remark in the movie about the auto guy Tucker "A well run company
doesn't waste time on research". Yes, some research is close to intellectual
self-abuse, but it's the job of a good CEO and a good Board to know that this
is not always true (e.g., SR-71, 22 nm line widths) and how to make applied
research productive, not just throw out the baby and drink the bathwater.

Third, any entrepreneur with a good chance of doing well has to ask himself at
least 10^10th times if he wants anyone like Ben on his Board of Directors.
Why? Sure: The CEO and his team have seen an area where they might do better.
With the CTO, the CEO outlines an applied research project to get the coveted
better results. So, for the next Board meeting the CEO includes some foils on
the applied research project. Then in the Board meeting Ben wakes up and
starts asking questions: How long will the project take? How much will it
cost? How good will the results be? What will be the milestones during the
project? What is the project schedule, step by step? Or if an experienced auto
mechanic can do a brake job on a Ford F150 truck in the time in the book, why
not this 'research' project?

So, the CEO has to tell Ben and the Board that for all of the questions, at
present he is comfortable with the situation, will continue to review the
situation during the work, but otherwise really has no answers at all for the
more specific questions. Presto: Ben gets torqued, brings out his fiduciary
powers, fires the CEO, before his stock is vested, and 'gets the company back
on a business like, bottom line basis' and just blows it.

Even worse, maybe the applied research has already been successful, and at the
Board meeting the CEO introduces the CTO who explains the work and, then, the
next step, converting the applied research to production software. Again, just
over the software work, Ben does an upchuck.

I just don't see Ben being able to work effectively with things that are new,
powerful, valuable, innovative, etc. NSF, NIH, and DARPA problem sponsors can.
Ph.D. supervisors can. Successful Ph.D. students can. Research professors can.
But I don't see Ben as able.

~~~
Sharlin
_Instead, look at the architecture and think a little about what the heck the
poor computer is being asked to do. Then look at where the computer resources
are going. Likely then, tweak the architecture: So, if are spending time
walking down arrays or linked lists in O(n), then consider using an AVL tree
in O( ln(n) ). If executing the code for a page when know that the output will
be the same as the last 10 times, then cache the output and don't run the code
again. If caching the output in main memory, i.e., virtual memory with page
faults, then consider just using disk file for each page to be cached and save
on page faults. If are connecting to a database, then have a pool of
connections. Etc._

I read the original article pretty differently. As far as I can see, these all
are exactly the kind of lead bullets the article meant. No miracles, nothing
that doesn't directly involve _making your product better_ , just some good
old-fashioned programming work. The author's point was that if you have an
inferior product, you roll up your sleeves and make the product better.

~~~
graycat
Yes, the AVL trees are like you describe, but the caching may not be because
it's not clear to me (and I'm writing for ASP.NET and IIS although have yet to
look into caching) if knowing when could cache needs just a lead bullet or a
silver one. For more, I'm not deep enough into the internals of ASP.NET, the
Windows 'global assembly cache', just how SQL Server connection pools work,
etc. to know where the silver bullets would be in such work. So, my examples
of bullets are too close to lead bullets unless the price of silver has
declined a lot!

------
malkia
silver bullets are actually much less efficient than lead (vampires or not)

~~~
RandallBrown
but if it's a werewolf, it's the only way to kill them.

------
wilfra
Sounds like the Microsoft strategy (Bing, Windows Phone etc) - and now what G+
is trying to do to Facebook.

What are some examples of startups doing it (or not doing it)?

~~~
SatvikBeri
Perhaps duckduckgo?

~~~
orangethirty
Not to take a cheap shot at ddg ( user), but they are a more consumer focused
company. Google on the other hand is more b2b.

~~~
dredmorbius
Google started with a consumer focus. And a large portion of their traffic
remains consumer.

~~~
orangethirty
It started consumer, but it is now B2B. The consumer traffic is what they
sell.

~~~
dredmorbius
My point is that if you want to start to get traction, B2C isn't a bad place
to start. That assumes you can either translate that to revenues, make a B2B
pivot, or shim a B2B service in place at a later date.

~~~
orangethirty
Why would you even target a market you wont profit in? Makes no sense. What
Google did is simple: They saw that there is no money in search (ask around),
and saw that there was a lot of money in lead generation (advertising). They
copied overture, and it grew.

~~~
dredmorbius
Google's advertising business would be nowhere without its dominance in the
search market. Google _earned the right_ to dominate in advertising by
becoming a compelling search engine. It's a lean-to, with both sides
supporting the other. Pull either out, and it falls.

For a lean start-up, building the consumer side makes the case for the
business side.

