Fully agree. There are so many people who can't do the basic Excel work even to generate the information on the chart who are capable of starting a business. (I include in this every restaurant ever opened, modulo statistical outliers.)
That's not a problem with the chart. That's a problem with starting a business.
You don't have to grow along a fixed axis, whether that be # of users, # of widgets, etc. You just have to average the growth in income.
I had a similar initial reaction to the chart because I stick to R&D-driven startups that will run at $0/week for as long as it takes. However, pushing the stop-energy out of my head and running with it is a good gut check for viability on breaking even given assumptions about expenses vs income over time.
The output isn't "we will grow at an annualized 360% forever, yielding foo," it's "we only need to kick in $x to have a good shot at getting to B/E."
Yeah, I think many startups have a fairly long customer/product development period where their revenue will be $0, and then quickly pour on the gas once they have users and want to monetize.
I wish the tool had an additional degree of freedom, which is "time until first revenue". That would let you model how much time-to-market is costing you until breakeven, and trade off a business idea that generates revenue immediately vs. another business idea that takes a long time to incubate but may have a higher growth rate. I guess you can figure it out with some quick mental math (just multiply monthly expenses by time-to-market and add that on to capital required, and add the time-to-market on to the breakeven time), but if it were in the tool it'd be easier to visually see the effects of different choices there.
The fact that we're still typing crap into windows and calling advances along this one-dimensional path 'innovation' is pain.
Intentional[1] had a lot of promise but was too slow off the mark and now feels more like BPML, which has too much XML hiding under the covers to be good. As it stands, making solution development easier for business users has not had a broad impact on the overall productivity of developers.
'Blub' assumes existence on a continuum of language. It's a limiting concept in itself, as many of us have a different internal representation of thought.
It's sad to read about "python stuff for swift" or "haskell stuff for scala" when the only advantage of those exercises is as homework to understand the concepts.
It's that race to the bottom they mention. As they mention, they're in a relatively expensive labor market (although, as I sit here in the Bay Area, they have me thinking about a recruiting run to the UK).
They're paying for the market validation that can be eaten up by a company in a less expensive market to produce a knock-off version (or, more likely, ten knockoff versions) for that USD9.99 and enjoy boatloads of sales.
This pattern sets an expectation that, because it can run on your phone, it should cost significantly less than desktop software, even if it is more useful than a desktop version.
I'm a big fan of leverage and my father taught me the ROI model of tool selection from an early age, for everything from shoes to calculators. Unless it's completely unaffordable, the cost of a tool is irrelevant outside the context of its ability to amplify your thought and your output.
This works out when discussed in the context of "competitive compensation" in your market. While your manager may not care that you want to live in a USD5,000/mo apartment, she may care that companies x, y, and z are paying programmer analyst IIIs USD5k/mo more than she's paying you.
I almost never give COLA raises, but I will raise based on performance and desire to remove money as a reason to look for another job. It's the easiest way to overcome inside recruiting and it doesn't take much thought, so I can spend my time with other retention techniques.
The concepts are the important part. You can get a long way with a nasty interpreter to see if your concepts play out. :-)
If it's a "deep" concept, I'd pick a simple representation that I can implement without much cognitive overhead (a basic Lispish or Forthish stacks-and-registers syntax is usually something I can spin up in a few minutes) and then start layering my concepts in.
Some of the things you think will be awesome will end up just being wrong or inefficient, but you'll cut the loop down really quickly.
It makes it really easy to compare your hypotheses. If you want to factor them into a more conventional syntax model (c, python, haskell, etc.) you can always learn that along the way.
In fact, if you want to get really simple about it, write the code you would want to write and hand interpret it. You can get really far with simple pre-processors written in whatever text or AST manipulation environment with which you feel comfortable. (I'm notorious for being lazy and writing 50-pass compilers, just writing 10 to 200 line features and chaining them, all in a ghetto RPN.)
For music, I agree. But there is other content - TV shows, Movies, books, etc. My iTunes purchased video aren't going to play on an Amazon Fire unless I remove all the DRM from it.
To make a comparison for anyone who hasn't programmed FPGAs (especially on the path to etching silicon), placement is extraordinarily important. Not only can (will) you make a highly non-optimal layout, FPGAs are not orthogonal. You'll spend a lot of time trying to route the bits that need to talk to each other via direct connection as much as possible instead of going through a gp line or worse.
Depending on the make and model of FPGA, you will have "large" areas that you either can't or don't want to plop logic.
You can have a pretty netlist that validates and simulates correctly (although you'll eventually end up dealing with Cadence, who seem to have the right hand side of the bugs per line of code curve locked up) but still takes weeks or months of that inline ASM work to make it competitive with a rack of Xeons. The edit/compile/debug cycle is not quick by any means past a trivial number of gates.
Dealing with that junk is why IP blocks are so attractive, but you end up on the road to structured ASICs and that just leads to misery.
The Chinese luxury market is insane and has been popping for the past ~10 years. It's not just LV (and child companies) but across the board, with Richemont and others doing quite well. LV just happens to be very good at a) encouraging mobility in its staff so that the "experience" is consistent b) grabbing a great spot of real estate and building monstrous stores in which you could fit an Apple store or ten and c) selling product that advertises the financial status of its owner.
I'm sure you could run a similar metric with Rolex or other "conspicuous consumption" brands.
And no, it's not the poor kids sewing Nikes who are buying the top kit. The average purchasing power is very low.
Another market that's exploded in the Far East is scotch whisky. Scottish producers are struggling to keep up with demand in markets like China, Japan and Taiwan.
A fun one is finding loans from friends and family that involved any sort of strings, whether convertible or interest that has accrued because Aunt Bertha forgot about the $50k she gave you.
It's easy to forget these loans from the early days, especially if there were 20 people who gave the founder little bits of money, especially if it was before he or she set up the corp accounts, etc.
Other than that, one of the worst I've knocked down uncovered a lack of assignment of IP (an early rich-media MUA) from a contractor that effectively meant the candidate company had zero value. "Who's Bob Smith of Bob Smith, Inc.? Can I talk to him about this shitty code? Oh, he owns it..."
Some commonly involve artificially boosting turnover by trying to be clever and using in-house developers as a separate concern, billing or paying through companies owned by family members. Sometimes this sort of setup is kosher (you want to smooth out and isolate capex and a friend has office space and a couple devs, or there's an overseas component, or whatever) but if money is moving between them in a semi-closed ecosystem, it's often a bad sign.
Usually, as stated, it's sloppy stuff, but sometimes you get a real weasel.
As for being a founder, having an accountant/CFO makes a huge difference. The first contract CFO I hired was a revelation. The commitment was low and the upside was huge. We were too small for a FT CFO and I was a babe in the woods and didn't even realize these people existed.
Other than that, one of the worst I've knocked down uncovered a lack of assignment of IP (an early rich-media MUA) from a contractor that effectively meant the candidate company had zero value. "Who's Bob Smith of Bob Smith, Inc.? Can I talk to him about this shitty code? Oh, he owns it..."
What happens in that case? Does the acquisition stop in its tracks, or does the company try to contact Bob Smith and buy the rights?
In the case I mentioned above, we left the candidate site immediately, arranged earlier flights, and flew back to Seattle. There may have been exec communication but I was just the technical DD guy at the time. But I never heard from them again.
Had the code been stellar, we may have given them time to sort it out so that the package was clean.
