5 Rules for Making Money During a Recession

From The Huffington Post - Ann Handley:

• Don't cut the budget.
• Maintain strong launches.
• Get a little silly.
• Beware the slash and burn.
• You might as well dance.

White knights [?!]

From Crooked Timber:

Readers used to the natural order of things might be concerned by the implication that with such a giveaway price, the top brass at [Bear Stearns] might be forced to bear the financial consequences of events that were obviously beyond their control. Never fear. According to this Reuters report in the Guardian, while most employees up to junior executive levels will lose both their jobs and the shares they were encouraged to buy, with no “golden parachutes:

JPMorgan Chief Financial Officer Mike Cavanagh late Sunday said taking over Bear would generate about $6 billion in merger-related costs.

JPMorgan has not broken down those figures, but much of that will be earmarked for severance pay and potential exit packages for top executives like Schwartz.

A person familiar with the transaction told Reuters that roughly $1 billion of those costs would be earmarked for severance and retention.

It's the libraries, stupid!

From Why Apple Will Dominate Next Gen Computing - ReadWriteWeb (by Alex Iskold):

Let's be clear. It is not the language, but the libraries that matter. Every time I hear developers talk about a new language and say it is by far the best one, I just shake my head. A new language is not going to be usable in today's world unless all of the libraries are in place. As the complexity of our software increases, so do demands on libraries. Microsoft learned it the hard way with years of set backs when it rolled out .Net. Had it simply embraced and optimized Java, it could have been years ahead instead.

Apple choose a different path. For the last decade Apple has been wowing the crowds and investors with its flawless and lightening quick execution. Every new Apple announcement, we keep thinking that they won't top it. But every time, Jobs and his crew pulls another trick out of the hat. Clearly, Apple is a well-oiled machine that has perfected the art of execution. But beyond that, Apple's secret sauce has been its software. While others have been inventing new languages and frameworks, Apple kept perfecting and building up its code.

Since the early days, Apple embraced a language called Objective-C - an object-oriented flavor of the popular procedural language. When Jobs returned to Apple, one of the early smart decisions was to ditch the old operating system in favor of Unix. This moved allowed Apple to instantly tap into serious programmers while retaining a beautiful and simple UI. When Java came along, Apple was unmoved, because it was just too slow. In general, over the years Apple has ignored new languages and just stuck with its platform. Smart, disciplined and mature...

Lessons Learned at 37 Signals

From Sean Ammirati's summary on ReadWriteWeb of a talk by Jason Fried of 37signals at SXSW 2008:

37signals is a software company headquartered in Chicago that started as a interactive design company and has since become one of the leading software companies for personal productivity software. Currently over one million people and businesses use their productivity applications... They also are responsible for creating and then open sourcing the popular web developer language [sic] Ruby on Rails. Jason Fried is the company's founder.

Lesson 1: Ignore The Great Unknown

"...often as entrepreneurs, we worry about the impact of our decisions rather than just making the right decision. ...this is crazy, because decisions made today don't have to last forever - we 'must optimize for today.'"

Lesson 2: Watch Out for Red Flags

Red flags are ... words or phrases that end up causing problems in communications. For example: need, can't, easy, only, fast.

Lesson 3: Be Successful and Make Money by Helping Other People be Successful and Make Money

...This has become part of [37signals'] philosophy, looking for opportunities in the marketplace to "spot chain reactions and be the catalyst" around helping others.

Lesson 4: Target Nonconsumers and Nonconsumption

...The idea [from Clayton Christensen of Harvard Business School] is that there exists an entire market of nonconsumers, or people who have a need but existing players aren't targeting these people. The advantage of targeting this segment is that you minimize the chance for competition from entrenched players.

Lesson 5: Question Your Work Regularly

• why are we doing this?
• what problem are we solving?
• is this actually useful?
• are we adding value?
• will this change behavior?
• is there an easier way?
• what's the opportunity cost?
• is it really worth it?

Lesson 6: Read your Product

"The biggest sin on the internet right now is bad copywriting ... paying too much attention to pixels and not enough attention to words."

Lesson 7: Err on the Side of Simple

...always "start with the easy way."

Lesson 8: Invest in What Doesn't Change

Lesson 9: Follow the Chefs

Jason called chefs the smartest business professionals. ...they are aware that you become famous and successful by giving knowledge away. For example, chefs have cooking shows and write cook books. Yet it doesn't stop their restaurants from being successful. In fact, he claimed they are probably more successful because of their sharing.

Lesson 10: Interruption is the Enemy of Productivity

Lesson 11: Road Maps Send You in the Wrong Direction

When talking about business plans, financial projections, or features for products 37signals believes road maps are bad, because "they lock you into the past." The only exception is APIs, because people are counting on it. ..."do the right thing at the right time."

Lesson 12: Be Clear in Crisis

At the beginning of this year, 37signals had some infrastructure problems that resulted in a few hours of unscheduled downtime. This was widely discussed on the internet. They quickly posted about what had happened and during the technical problems they kept their homepage updated with status messages. Through this experience, it reinforced their belief that people love you even more if you are open, honest, public and responsive during a crisis.

Lesson 13: Make Tiny Decisions

Rather than trying to make major decisions, when possible, Jason encouraged entrepreneurs to break problems down to the atomic level. In web properties, this is especially powerful because they've been able to break features down to the atomic level and then launch them one at a time. This is good because the team can gain momentum and celebrate little launches. However, it's also good because "when you make tiny decisions, you can't make big mistakes."

Lesson 14: Make it Matter

Jason ended his presentation by encouraging the audience to make sure their work was significant. He talked about how meaningful he felt the products they were creating were for individuals. ..."everything you do should matter."

Interface "Wow" Factor

From Code Commit:

That’s what it really all comes down to: user perception.  Jeff Atwood harps on about this constantly, but just because it’s oft-repeated doesn’t make it less true.  It doesn’t matter what your application can do, just what your users think it can do.  It’s all an elaborate illusion anyway, we just have to realize how complete that illusion really is.  If a user looks at your application and thinks, “Wow!  I don’t know what it is, but it looks powerful,” then you have succeeded as a developer.  Your application could do nothing more than print “Hello, World!” an infinite number of times; so long as it is impressive looking, it will be a success (think iPhoto 1.0).  Likewise, your application may desalinate water and hold the key to world peace, but if it looks wimpy, users will never give it a chance.

Application Development in the "Cloud"

From an article on GigaOM written by Geva Perry (chief marketing officer at GigaSpace Technologies):

...Although it is difficult to come up with a precise and comprehensive definition of cloud computing, at the heart of it is the idea that applications run somewhere on the “cloud” (whether an internal corporate network or the public Internet) – we don’t know or care where. But as end users, that’s not big news: We’ve been using web applications for years without any concern as to where the applications actually run.

The big news is for application developers and IT operations. Done right, cloud computing allows them to develop, deploy and run applications that can easily grow capacity (scalability), work fast (performance), and never — or at least rarely — fail (reliability), all without any concern as to the nature and location of the underlying infrastructure.

Taken to the next step, this implies that cloud computing infrastructures, and specifically their middleware and application platforms, should ideally have these characteristics:

• Self-healing: In case of failure, there will be a hot backup instance of the application ready to take over without disruption (known as failover)...
• SLA-driven: The system is dynamically managed by service-level agreements that define policies such as how quickly responses to requests need to be delivered...
• Multi-tenancy: The system is built in a way that allows several customers to share infrastructure, without the customers being aware of it and without compromising the privacy and security of each customer’s data.
• Service-oriented: The system allows composing applications out of discrete services that are loosely coupled (independent of each other)...
• Linearly Scalable: Perhaps the biggest challenge. The system will be predictable and efficient in growing the application. If one server can process 1,000 transactions per second, two servers should be able to process 2,000 transactions per second, and so forth.
• Data, Data, Data: The key to many of these aspects is management of the data: its distribution, partitioning, security and synchronization...

What Stanford Learned Building Facebook Apps

Some of this may be specific to Facebook "apps" ... but, then again, many of these points can easily be applied to "traditional" application development as well. (And should be.) From ReadWriteWeb:

Dr. BJ Fogg and Dave McClure taught a class last semester at Stanford on Building Facebook Applications. In 10 weeks, the 80 students had created 50+ applications and in total had over 20 Million installs - with 5 having more than 1 million users.

At today's Graphing Social Patterns conference, BJ and his two teacher assistants shared 10 tips they learned from the experience. Here they are:

1. It's never too late to create a winning app
2. Simplicity & clarity are key to app success
3. Aim for speed & flexibility in launch and iterations
4. Community cooperation leads to success (in other words, the most successful students shared the most)
5. Individual opinion about apps are worthless, you need to get out there and see what happens
6. Copying success is a cheap / fast way to succeed
7. Metrics do matter, but today's tools are too weak
8. You CAN learn to create a winning app
9. Success comes from the CHAOS / CONTROL Cycle
10. Mass Interpersonal Persuasion is finally here

How to Start a Start-up

You need three things to create a successful startup:

• to start with good people,
• to make something customers actually want,
• and to spend as little money as possible.

Most startups that fail do it because they fail at one of these. A startup that does all three will probably succeed.

-- Paul Graham

About 3-2-1 Launch by Hashrocket

Hmm. A lot to think about in this post about the development philosophy and methodology of Obie Fernandez' new company Hashrocket. And to learn from. And, if possible, to apply personally.

...my new startup company named Hashrocket. (We are named after the ubiquitous key/value => operator in Ruby.) One of our two principal offerings is called 3-2-1 Launch...

We ... came to the conclusion that a span of 3 days is just enough time to get a new project off the ground - enough to nail down some distinguishing functionality, without sacrificing quality and good looks. Of course, it's not applicable to all projects -- our team of developers is 4-6 people (mostly working in pairs) which limits the amount of complexity we can tackle in one 3-day iteration (which we've taken to calling "orbits").

Here's a quick list of factors that empower us be ultra-productive in 3 days:

• Expertise in Ruby, Rails and BDD (using RSpec)
• Heavy automation of common tasks (pretty much anything repeatable is automated, including our initial application bootstrap which includes basic functionality such as authentication)
• Smart use of web services such as Amazon's EC2 and S3
• Reliance on Rails-based web 2.0 tools such as Basecamp, Highrise, Lighthouse, and Beanstalk

The 3 scheduled days (always Mon-Wed) refers strictly to implementation work, specifically the first iteration, ending with a public release of the software. Prior to the 3 days, our contract specifies a time period of 3 weeks during which we agree on detailed specification ... and high-fidelity mockups. What we're looking to achieve is a high level of confidence that we'll be able to launch in 3 days, and that necessarily involves locking down requirements prior to implementation. We've talked about an abort mechanism if anybody on the team thinks we're not going to achieve a successful launch (unveiling) on Thursday. If an abort were to occur, we'd postpone the launch for the next available date (probably the following week) at no additional charge to the client.

UsWare vs. ThemWare

No comments required. From Coding Horror:

Ted Dennison left this astute comment in response to Do Not Listen to Your Users:

Generally when I go talk to users, it is to educate myself enough to become a user like them. Then I can see what needs doing, what needs streamlining, reorganizing, rearranging, etc.

This brought to mind Eric Sink's claim that there are three categories of software:

1. MeWare
   The developer creates software. The developer uses it. Nobody else does.
2. ThemWare
   The developer creates software. Other people use it. The developer does not.
3. UsWare
   The developer creates software. Other people use it. The developer uses it too.

ThemWare is how most software gets developed, with predictably disastrous results:

If I am building software that I don't use and don't know how to use for people I don't understand or even like, how good is my software going to be?

I probably see every feature in terms of how difficult it will be to implement, rather than how valuable it will be for my users. I probably find myself wanting to label or document the features using my jargon instead of theirs. I probably create features that are tedious or unintuitive for my users. I can't imagine why the user interface I designed doesn't make sense to them.

I've found that much of the best software is the best because the programmers are the users, too. It is UsWare.

It behooves software developers to understand users, to walk a mile in their shoes. If we can bridge the gap between users and ourselves-- even if only a little-- we start slowly converting our mediocre ThemWare into vastly superior UsWare. To really care about the software you're writing, you have to become a user, at least in spirit.

Consuming the software you're creating is colloquially known as dogfooding in programming circles. Unless you're (un)lucky enough to be writing software intended for other software developers, dogfooding can be a challenge. But it's worth it. Dogfooding keeps software developers honest. Why work against your users by producing ThemWare when you could work alongside them to build UsWare?

Six Principles for Making New Things

More great stuff from Paul Graham:

Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

When I first laid out these principles explicitly, I noticed something striking: this is practically a recipe for generating a contemptuous initial reaction. Though simple solutions are better, they don't seem as impressive as complex ones. Overlooked problems are by definition problems that most people think don't matter. Delivering solutions in an informal way means that instead of judging something by the way it's presented, people have to actually understand it, which is more work. And starting with a crude version 1 means your initial effort is always small and incomplete.

I'd noticed, of course, that people never seemed to grasp new ideas at first. I thought it was just because most people were stupid. Now I see there's more to it than that. Like a contrarian investment fund, someone following this strategy will almost always be doing things that seem wrong to the average person.

As with contrarian investment strategies, that's exactly the point. This technique is successful (in the long term) because it gives you all the advantages other people forgo by trying to seem legit. If you work on overlooked problems, you're more likely to discover new things, because you have less competition. If you deliver solutions informally, you (a) save all the effort you would have had to expend to make them look impressive, and (b) avoid the danger of fooling yourself as well as your audience. And if you release a crude version 1 then iterate, your solution can benefit from the imagination of nature, which, as Feynman pointed out, is more powerful than your own.

...

Reddit is a classic example of this approach. When Reddit first launched, it seemed like there was nothing to it. To the graphically unsophisticated its deliberately minimal design seemed like no design at all. But Reddit solved the real problem, which was to tell people what was new and otherwise stay out of the way. As a result it became massively successful. Now that conventional ideas have caught up with it, it seems obvious. People look at Reddit and think the founders were lucky. Like all such things, it was harder than it looked. The Reddits pushed so hard against the current that they reversed it; now it looks like they're merely floating downstream.

So when you look at something like Reddit and think "I wish I could think of an idea like that," remember: ideas like that are all around you. But you ignore them because they look wrong.

37signals Featured in Wired (March 2008 issue)

Some [important, I believe] items to consider from 37signals' reaction to an article in Wired entitled The Brash Boys at 37signals Will Tell You: Keep it Simple, Stupid:

Myth: Whoever spends the most wins

What’s more, 37signals’ ideological objections to outside funding could make them less able to withstand competition. Nicholas Carr, author of The Big Switch, says companies like 37signals won’t have the resources to fight should larger firms with huge economies of scale and backend infrastructure decide to take them on. “They’re going to have a very tough challenge,” he says.

We continue to find this argument flawed. First of all, a few rounds of VC millions won’t put us on equal footing with bazillion dollar giants like Google, Microsoft, or other masters of economies of scale.

Second of all, we’re not in the winner-take-all software world of the 90’s anymore. Thanks to the web, there’s plenty of room for lots of companies, ideas, and products to flourish. The behemoth model isn’t the only game in town. There’s plenty of opportunity, success, and profitability to go around.

Lastly, we think our biggest competitor is habit—people using the phone, email, paper, pencils, post-it notes, and fax machines. These are the people we want to win over. We believe the simple software we’re building is the best way to do it.