41–50 of 71 posts
Work on the most important features first but find the middle ground between some spaghetti that just works and an over engineered system.
While I'm all for building minimum viable products, I would argue that a login process that does not have a password reset function is too minimal to be viable. If you're so strapped for time that you can't build a password reset form while you're building your user sign-up form, I would ask why you're bothering with building your own sign-up functionality at all. Why not use OpenID or OAuth based logins that bypass the need for building a sign-up system at all?
As a user, I would be hesitant to sign up for a product that didn't have password-reset functionality, and, if I discovered that the service I just signed up for has no way to reset a password, I would probably stop using it (since I lost my password and have no way of resetting) and disrecommend it to people who ask me about it.
Whilst I'm building signup, I realise that I probably also need reset password functionality. If a user signs up, but then forgets their password, that's a problem. But from my perspective right now, is this a nice problem to have? Actually, yes! I have zero users, but having this problem implies I would have users, which would be great. Reset password functionality is important, and will absolutely be required event…
When those are done, reset password might literally be the next item on your list. You might end up building and shipping it before anyone signs up anyway, but in the meantime you've at least got something out there and had the opportunity of getting any users at all.
This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…
In 2020, with the number of managed solutions out there for simple CRUD functionality, the default should be just using the managed thing until it doesn't suit you, not just ignoring critical yet non-unique pieces of infrastructure all together.
This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…
Wrong. The correct technical decision is to bundle in a library that solves this for you - login with Google, or Facebook, or GitHub, or OIDC, pick one according to the context. Get password reset, MFA, password security, etc. for free.
Why reinvent the wheel, poorly?
Whilst I'm building signup, I realise that I probably also need reset password functionality. If a user signs up, but then forgets their password, that's a problem. But from my perspective right now, is this a nice problem to have? Actually, yes! I have zero users, but having this problem implies I would have users, which would be great. Reset password functionality is important, and will absolutely be required event…
The password thing was just an illustrative example, it's not perfect, but the point isn't that you don't need it or that not having it won't be really bad when you have users, it's that whilst you don't have users perhaps there are other things that are higher priority to build first. When those are done, reset password might literally be the next item on your list. You might end up building and shipping it before a…
To go back to your point, was "lack of export functionality" a "nice problem to have"? Arguably, yes. You don't have to worry about exporting data until you have users entering data, right? But, as Microsoft found out way back when it was building Word, users won't come to your system unless they know they can get their data back out again to share with others. [1] So just like Word's market share only really took off when it was able to write WordPerfect files, I predict that Roam will remain, at best, a curiosity until they implement an export system that allows the user to take his or her notes and use them in a different application.
Instead of thinking about problems in terms of what prevents users from signing up, or what prevents users from using the product, it's better to think about problems in terms of what prevents users from accomplishing the tasks this product is supposed to help them accomplish. In the case of Roam, the lack of export functionality (which at first might seem like a triviality) is actually a big deal, because the utility of a personal knowledgebase is significantly diminished if there isn't an easy way to get all the knowledge back out of it again. As a result, lots products in that space (not just Roam) suffer from marginal adoption because while it's easy for a user to sign up, it's much less obvious that the product is worth investing any significant time or effort into learning and using.
[1] https://www.joelonsoftware.com/2000/06/03/strategy-letter-ii...
Having too many customers trying to buy your stuff is something folks would call a "nice problem to have" It's a TERRIBLE problem to have not addressed in advance because now you're loosing money and people may wander off. almost everything folks call "a nice problem to have" is not really "nice". It's frequently business hurting and sometimes business killing.
This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…
> That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it's prepared for future requirements. They of course would also know that you can't store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the "user" table and never ever expose it throug…
This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…
A decent eng will know that there are managed solutions for this problem that you don't have to build yourself. In 2020, with the number of managed solutions out there for simple CRUD functionality, the default should be just using the managed thing until it doesn't suit you, not just ignoring critical yet non-unique pieces of infrastructure all together.
This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…
> That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it's prepared for future requirements. They of course would also know that you can't store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the "user" table and never ever expose it throug…
Any of these things may or may not be relevant to your decision, and I know that authentication is a specific example within a larger point. What I'm trying to say is that it's never correct to say " is the right approach for all trying to do ". Every decision has consequences, and what really matters is your ability to foresee those consequences and weigh them against the broader strategic picture of what you're trying to accomplish.