But. Give that startup some time and it's not a startup any more. That 11% sure looks tasty now!
I hope we can all agree on that.
Now, here's the actually interesting bit: Almost all the posts on the internet people write and/or pay attention to, revolve around startups. Startups are hip and cool! And then all the poor enterprise developers like me read that stuff and get the wrong ideas. We have entirely different problems, mostly related to moving data into other people's heads, not so much about the machine.
And yet, here I am, reading HN...
Developers, what is it that you absolutely cannot offer the user without forcing them to register? If it's personalization, then store it on the user's device or iCloud or something similar, or say, generate a random ID number on first-run and inform the user to save it if they want to transfer/restore their preferences in the future.
ANYthing other than this deliberate speedbump which only decreases the total amount of users you would have.
Developer performance directly translates to app performance when the developer is tasked with improving performance. Fetishizing app performance for every little microbenchmark is counterproductive if it results in you sacrificing developer performance sufficiently.
The basic premise of the article might be stated as "developer performance matters more than app performance, when app performance doesn't matter" - which is bordering on a truism. Do you disagree with this premise?
> The point isn't to get apps or new features out as quickly as possible, it's to make a quality product and the speed of your app is critical to that.
So the point is to make a quality product as efficiently as possible? This requires a balance of features, stability, performance, maintainability, etc. - all things directly impacted by developer performance. The more effective I am, the faster I can implement features, find and fix bugs, profile and rewrite hot loops, refactor and review, etc.
You can make fast things in C++, but your competitors using Clojure will crush you. Developer performance isn't about sacrificing app performance, but rather getting there faster and making sure the competition doesn't catch up.
Take Rails as an example. In 2006 we were told that Ruby's slowness didn't matter since web apps spend most of the time waiting for IO, processors were getting faster, yada yada yada.
Guess what? 10 years later and Rails is still slow. Django is also slow. Template rendering is slow. I've written enough Erlang, Clojure and OCaml apps to know that no, I don't need "russian doll caching" in a fast language. Hell, I rarely need caching at all. My database layer is fast enough. /rant
There are tricks and things that help (if you want to shoot your DB performance in the foot use multi-table Model inheritance)
Try Jinja2 for templates
Is this really true or is it a perception based on being in whatever respective bubble filter we're in? E.g. if one is an Apple developer for a corporate backoffice, one does CRUD stuff on iOS. But if one is not in that situation, one thinks performance matters.
If we take a look at top paid apps at: http://www.apple.com/itunes/charts/paid-apps/
... one sees a lot of games and some image manipulation apps (facetune, faceswap, video editor, etc). These types of apps require tight loops outside of system libs and performance tuning. I see a few CRUD apps on that list such as HotSchedules and maybe the fitness apps which probably don't need ultratight performance loops.
I have hard time believing this is the sole reason that caused the increase.
Improving the sign-up funnel speed on our app by one second resulted in a 11% increase in signups. People are impatient and lazy, and everything you do to improve app performance will improve sign ups, retention, app store reviews and the perceived quality of your app.
The point isn't to get apps or new features out as quickly as possible, it's to make a quality product and the speed of your app is critical to that.