

Spolsky - Where there's muck there's brass - wmorein
http://www.joelonsoftware.com/items/2007/12/06.html

======
fauigerzigerk
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!

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

------
staunch
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.

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

~~~
staunch
Hence the additional "for startups" qualifier...

------
iamelgringo
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.

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

------
fleaflicker
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.

------
brlewis
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.

~~~
run4yourlives
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.

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

~~~
iamelgringo
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.

~~~
marcus
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 :)

~~~
iamelgringo
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.

------
andreyf
insubstantial and fluffy? three kids and an iguana?

Is this a thinly veiled diss at YC?

