2 ms·
I completely agree, and just wanted to reply to touch on this point a little bit. You are correct that the article (rightfully) provides a forumula to create a
by david_shaw 16y ago
I completely agree, and just wanted to reply to touch on this point a little bit.
You are correct that the article (rightfully) provides a forumula to create a popular app. Sure, there are lots of technical details that weren't touched upon in this article, and certainly we are not going to enumerate each of them and criticize the author for not creating an end-all be-all make-the-best-app-ever article.
However, I do believe that security should be a primary concern from the very start. Think about security early, think about security often. Once your app is already popular with 500k active users is not a good time to realize your oversight in security, leading to a possibly fatal breach.
- alain94040 16y agoWhile my brain agrees with your position, my heart tells me that it's more likely that you never make it to 500K users if you focus on security. I'd welcome a counter-example: can you name a succesful startup that died because of lack of early security? The way it seems to work today on the Web is succeed first, get the money, then fix whatever needs to be fixed.
- david_shaw 16y agoI don't mean to criticize the article posted, and welcome many of the points myself. I am coming more from a software development perspective, although I understand that the article is geared primarily from a marketing point of view. I agree with you that being paranoid about security instead of working on a human-friendly interface, or worse--a functioning product--will absolutely hinder developments to grow, but that is not what I'm suggesting. In my experience, the vast majority of crippling bugs are simple things, that can easily be prevented using methods such as the four I listed. These should be part of everyday secure coding practices. I would never tell a developer that they should stop working on their product to tinker with obscure security fantasies, but I'd also say that they're crazy if they don't include basic checks (such as ensuring on a basic level that user input is clean) as mentioned above. Development methodologies like TDD include this inherently in the software life cycle: tests reaching outer bounds and unexpected input are regularly created to make sure that errors are handled correctly.