I'm afraid I have to disagree with the basic premise of this article and say that app performance matters more than developer performance.
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.
The actual answer, like always is: it depends.
If you are working for a startup looking desperately for product market fit, by all means optimize for developer performance! That 11% percent gain is noise if you are in the right product-market and growing accordingly.
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.
A little sidetrack here: As a user, I absolutely hate apps that require me to sign-up, especially if it requires email verification. It's an instant uninstall from me, no matter how compelling the app may otherwise be.
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.
Absolutely this. I've become completely unforgiving on this, especially with mobile apps. I am far too frequently left wondering if the devs—or, more likely, their managers—missed the part of the documentation that allows them to easily store data on my device for their app to use.
> I'm afraid I have to disagree with the basic premise of this article and say that app performance matters more than developer performance.
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.
The point of the article was that you can easily get that performance boost in any language - especially when network latency is involved; it will be there no matter the language used.
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.
I don't think you're catching the basic premise here. Brent is suggesting that when you're writing code targeting iOS or the Mac, the majority of time spent is within the system libraries (in most situations). So the language of the driver code (i.e., your stuff) doesn't have much impact on app performance.
You're correct, and that's the same excuse Ruby and Python advocates use when developers complain about performance. Frankly, it's bullshit.
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
I'm Django developer and I agree with you. We've ditched Django templates entirely. We use it as our API platform only - most of the computation time is spent in json and in Postgres.
>, the majority of time spent is within the system libraries (in most situations). So the language of the driver code (i.e., your stuff) doesn't have much impact on app performance.
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.
... 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.
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.