Spolsky - Where there's muck there's brass | Hacker News Reader

Spolsky - Where there's muck there's brass

joelonsoftware.com

36 pointswmorein19 comments

There are two types of muck though: Muck that cannot be avoided and becomes a hard problem that must be solved => brass. Muck for which there is a known way to avoid it, and solving it is just a short term fix with shrinking demand => legacy.

Data cleansing/integration is an example for the first kind of muck. I believe on-premises server-side software belongs in the second muck category. As a startup, think hard before you do it!

Some pains need to be solved and some need to be managed. Startups tackle the first type better.

PG already claimed the yorkshire-muck-brass analogy for startups: http://www.paulgraham.com/bronze.html#f4

But damn does it bare repeating. A recent experience for me has been creating some plugins for blog software. It's insanely painful making them work reliably with thousands of subtly different sets of platforms/versions/themes/plugin combinations. I've learned first hand from users how much they value it, and I'm not going to give up, but wow is it ever agonizing. I almost pity my competitors for following.

There's tons of money to be made in creating Wasabi-like abstraction layers for all sorts of similarly hairy systems. I know I'd gladly pay for ones that would spare me.

I think the old Yorkshire men already claimed the muck-brass analogy long before Paul Graham or Joel Spolsky ;-)

Hence the additional "for startups" qualifier...

Yeah, but creating a web app that gets 1 million+ users isn't an easy feat, either, Joel. You say it can be done with 3 guys and an iguana. Well, that's only if the 3 guys +/- iguana have spent the better part of the last few years learning Python + Django/RoR, MySQL or PostGres setup installation and administration, Unix administration, SSH, Apache/Lighttpd/Nginx configuration and administration, Memcached, Perlbal or Pound, Mongrel, and perhaps Amazon web services like EC2 and S3.

Really, if you're not proficient or able to quickly learn these technologies, good luck with your iguana.

And, after spending the majority of the semester dealing with nightmares associated with the "Enterprise" web stack--ASP.NET, J2EE and Oracle--creating a web application is muck. Why else is Big Co. willing to shell out millions of dollars for a startup that has created these web apps and succeeded in attracting customers? Because Big Co's aren't doing it well at all. They're mired in muck.

Hackers willing to learn and use a non-Enterprisey web stack will find that they can walk on top of that muck and find brass. Selling shrink-wrapped software isn't the only way to make money.

The key is that if you're going to stick with server-side apps you need to solve other hard problems.

Apparently YCombinator companies are about 1-4 people minus iguana. And most of them are just fresh-grad or 1-2 years away from college. So Joel statement stands.

You're missing his point completely.

he must be desperate to hire new people--he's been posting essays at a blistering rate.

i can't blame him though--joelonsoftware is a great recruiting tool.

I bet diversity of PHP installations is the source of his support issues, not the diversity of Unix installations. There's plenty of software that runs fine on diverse POSIX-compliant operating systems.

Except when you're missing package X or dependency y.

UNIX is designed to be a configurable, custom system. There's nothing wrong with that, but I believe him when he blames UNIX/Linux and the multitude of varying installs cause him the most grief. You can't pin it all on PHP.

I wonder if they could reduce the support costs for the installable version by selling complete servers with the software pre-installed?

They could sell a virtual appliance that comes pre-configured. Something that they could run on top of VMware or Xen.

Or, perhaps a they could sell a pre-configured server. But, then they're supporting the OS that they're selling, and they might not have the flavor of *nix that the company wants.

An awesome idea, haven't encountered any businesses that use this approach but it would definitely have quite a few advantages. Most projects should probably avoid VMware as otherwise the cost of at least the most basic VMware license gets piled on top of each sale and at ~200USD that can be a significant increase.

But in any case it can be a great compromise between the clients issues of data privacy and response time versus the supplier tech support expenditures.

Would have upmodded twice if I could :)

Thanks, I'd love to take credit for it, but there are at least a dozen companies that are already doing this:

http://www.vmware.com/vmtn/appliances/directory/cat/131

Tell you what, if you go with the idea and make a buhzillion, you can buy me a beer sometime. ;)

As to the cost issue, adding $200 onto the purchase price of an enterprise appliance is peanuts. Most enterprise software sells in the $1000 - $100,000 range depending on what you're selling. In fact, you can charge even more for bundling it with VMware. "It's a feature!"

Another plus for doing it this way, the very fact that you're using a virtual appliance makes your product buzzword compliant. "Virutualization" makes your product tre' cutting edge--very sexy for CIO types to talk about how they just spent $50,000 on the latest tech.

VMware Server is free, so there's almost no tax on virtual appliances now.

I would hazard a guess that the same businesses that would prefer to host their own solution are not looking for an "appliance".

insubstantial and fluffy? three kids and an iguana?

Is this a thinly veiled diss at YC?

Reply on news.ycombinator.com