Hacker News new | ask | show | jobs
by racbart 4595 days ago
This is truly great as proof of concept and also as a reminder that in software development building 80% of perceived* functionality usually takes only tiny fraction of total development time which is required to build final product.

* - this app looks and feels like “almost complete spreadsheet” yet it provides much less than 1% features of even a basic spreadsheet.

3 comments

And 80% of perceived functionality is what most users — even people who rely on spreadsheets for their work — need.

I'm not saying including the other 20% of functionality isn't a good thing to do, but when you're creating a new product or open source project, you can get by (and thrive) building only the 20% of functionality that's used 80% of the time.

Why? Because 1% of functionality is still better than 0% (never shipping).

You're not Microsoft. You don't have to keep your dominance in the spreadsheet software market like Microsoft has to.

You missed his point.

It doesn't actually work well. It doesn't do basic stuff, which makes it entirely unusable. Like you can't move up/down/left/right using the arrow keys. You can't save it. It crashes if you make basic mistakes.

The 80% of perceived functionality is that it looks like a spreadsheet app and actually does some basic calculations.

It actually does about 5% of what you'd expect even the most basic of spreadsheets to do. And all the polish of even the most basic functionality is missing, which is what takes most of the time.

Which is why you should always avoid putting a pretty looking but barely functional mockup in front of the pointy hairs. They then think it's almost done.

Agree with your last point totally.

But 30 lines of code, what do you expect? Now imagine jQuery type library with a community of developers and you get... Google Docs :-p

I'd say this is to Excel as MongoDB is to any real database.
> And 80% of perceived functionality is what most users — even people who rely on spreadsheets for their work — need

This is exactly the insidious myth that the GP is pointing out.

Yes, 80% of the "perceived" functionality might be 1% of the work. But the remaining 20% is a long tail of utterly essential features that are completely fragmented between users. Each user only cares about 80.1% of features, but without the extra 0.1% your spreadsheet is useless.

One user will care that it doesn't print. Another will care that it can't do a sum over columns. Another will care that it doesn't have charts. Another will care that you can't make a bold heading. Another will want statistics functions. Basically your "80% of functionality" has zero value until you do years of work to implement all those 0.1% features.

This myth leads countless people to implement what they think is MVP and then be mystified that their insanely great work still has zero value to anybody they actually show it too.

The problem is that the total economic value (as measured by market price) for the users who only use that 80% of perceived functionality is close to 0 (google docs and OO/LO are free)

The incredibly difficult 20% is what people pay for. It's what the businesses that shell out billions of dollars a year pay for. And it's what a successful product in the space needs to tackle

On the other hand, you are taking what appears to be a general observation and applying it to this specific instance. Sure, there are plenty of free spreadsheets available. But what about other areas? There's plenty of areas still where a well executed easy to use minimal version of a product can compete in the existing for-pay ecosystem, and as we are discussing, minimal can pay off since 20% of functionality may take 5% or less of the time it would take to do 100%.
Y'alls be talking about different things.

You're talking about "feature minimalism is a good design philosophy".

The other dudes are talking about "bridging the gap between a sweet demo and a final product is a tremendous assload of work".

No, I'm specifically just saying that not everyone's "final product" is the same thing, and depending on the target market and audience, a minimal product may be worthwhile, and the economic value isn't always "close to 0", as the parent I replied to stated.

Also, I don't think that "feature minimalism is a good design philosophy" is always true, even though it may guide you well in most cases.

Um no. Google docs is free for the same reason IE was free. The economic value is tremendous, such that the creator is willing to spend billions on it.
This ridiculous false choice suggests a certain lack of understanding of what it is like to build software.
Really? The first thing I did was select a cell, type =, then press the arrow keys. Nothing happened.

The perception of being a "almost complete spreadsheet" might be due to the UI looking similar to older versions of Excel, leading people to assume stuff is there that doesn't.

Also, I wonder how much of this code would survive if you want to get beyond this 1%. Probably nothing, which makes this a road with a dead end. This doesn't mean it is not a useful and brilliant demonstration of cool language features (hacks?), which is how I see it. But there's no relationship between this amount of work/code/lines for this percentage and the amount of work/code/lines for any reasonably higher percentage of spreadsheet functionality.