Should startups write good quality code or just worry about delivering the product asap?
Andrei Galkov
53 replies
Replies
Himanshu Sharma@heman_shu
I've been obsessed with launching a perfect product. This meant tweaking the app time and again. But I feel that launching a product with just the right amount of performance would have been better for me. No user will care if the app is 0.5 sec faster or the query is optimized correctly or not. Nevertheless, it is still hard to control the urge to wait just a few days more before launching.
Share
Assuming you are still in the phase of trying to validate your idea and assumptions: I think you will always get a vague, "do something in between" answer to this question because the meaning of an MVP changes drastically from idea to idea and based on the judgement of the founders, etc. At this point if possible try to avoid code that invites bugs but make other sacrifices like building a backed that doesn't scale, etc.
If you have a validated idea and a growing user base, you cannot sacrifice the quality of your code anymore because that will most likely cripple your team in the future.
Virtuelly
Just get the product out there! As long as it does what its suppose to - quality of code does not matter.
@ankit_dhawan1 even if it works badly?
Virtuelly
@ankit_dhawan1 @andrei_gal I think we need to clarify what bad code is. When i refer to bad code i mean code which is not clean, which would need to be reworked and de have issues in scaling but from a customer perspective it would get the job done and solve the problem you are trying to solve. Once you can prove you and have validated your idea you can worry about the code being good and clean. That is the best problem to have but why waste time otherwise? It's obv preferable to write great code from the getgo but it wont happen unless you are writing it yourself/know what you are doing.
Delivering the product asap. After you know that people are willing to pay for your product, you can then write good quality code. Point is: you can always improve later.
Writing good quality code in the beginning takes more time -- you should focus on making sure people want your product first.
@welly_mulia Yep but sometimes you can lose lot of time fixing the code you made at the beginning of the journey. I think to some extend, taking a bit more time to ship "OK" code is totally worth it.
This is dilemma... while you write a good quality code the environment changes or your competitor releases same thing in shit quality and get your users. So I thing the truth between this two statements
Actually it depends on many factors. I think the best way is release version 0 of any feature (product) validate the product (feature) market fit, then you have to make v.0 to v.1 and deliver better quality code
Atlassian
@max_kamyshev on the other hand, if you you work on product market fit and your tool works badly, the result won't be representative
Marshmallow Icon Kit
Ping @tdeneulin you must have an opinion on the question!
Trackabi
I think a lot depends on your idea. If it's absolutely unique like you've created a new type of neural network for object recognition that performs times better than any existing analogs, you shouldn't worry about bugs in your UI at the start. Users will forgive. On the other hand, if you are building a new project management tool it should look very well and complete.
Also, you can make it simple, but it's better to make it right. If your code is terrible you won't be able to use it later. Or, what's worth, you can lose some user data because of a security problem and that may become the end of the story.
Geneva
+1 to that. The more novel the product, the more you should focus on shipping fast to validate your "net new" idea. On the other hand, the more competitive the space, the higher your customers/users' base expectations will be, meaning you'll need to spend more time writing high quality code to avoid bugs in the short term and costly major refactors in the long term.
Creatosaurus AI
definitely product asap but you can balance both by prioritization through impact vs efforts in your strict product asap launch timeline
Approveit - Streamline your workflow
I think it is better to write a small amount of good quality code rather than just rush for the quantity.
To my mind, good-looking code is a must since after you will receive market feedback and decide to change something or having to onboard a new developer - chances are that you have to fix tons of bugs or even build everything from scratch.
That definitely will slow you down. But it is important to ship fast meaning not to spend too much time building features and save time by lowering the number and the complexity of the features
You don't have to write perfect code, you can write quick dirty solutions to validate as soon as possible.
The caveat here is that it should be safe code.
I would lean towards faster shipping, but in certain cases high quality code/perfect product might be more appropriate (Cars, Medicines, Vaccines, Elitist products etc etc)
I think you should be working on improving product quality for the minimal version of the product. Make everything perfect for the first client. Then it makes sense to expand it.
I think startups should write the minimum amount of solid code that delivers a good experience. If the app is too buggy, users will leave
@aorobator 100% - have to balance building out new features with cleaning up existing, both polish on features and fixing bugs too
I'd say a good architecture foundation is a must. Then I'd put focus on core 20% features which is used by 80% of your audience and made code for it rock solid and well tested. Then to trade time for quality and move faster, I'd consider reducing the quality bar for the rest of less used features and get an MVP or proof of concept faster.
Emaildojo by Netcore Cloud
Agree with @johan_duus_terkelsen but the other side of the coin can be ...
For me : code quality > more features
Code quality should be always a priority, even if you are releasing your MVP version because scaling becomes a factor when your idea is really helpful.
More and more people will start using your product if it is really solving some serious problem and saving huge time. so you won't get time to upgrade your code quality because you might become busy with programming new features for your customers.
The only way to improve code quality will be a complete revamp. π
I think it depends on your ambition. The try fast, fail fast doctrine is good if you are testing the market (and in that case shit code is adapted). In case you do have a Product Market Fit, good code means less technical debts that can just kill you at the worst moment...
What do you think?
@hugo_pochet1 yea this is spot on and well said - how ambitious you are and how confident you are that your product is actually something people want
I'd say it's also important to understand your target audience needs - if you code a B2B product got IT companies, then the quality might matter for them.
@aleksandra_vovchenko so for you quality doesn't matter?
@andrei_gal If I will e.g., will order the food form your app, I'm not sure if I'll pay attention to code
keypup.io
I'd say it all depends on where you are at with your journey.
If you are still trying to validate your idea, see if you have a Product/Market fit or create an early prototype, then you may want to go 'quick and dirty'. Caveats on this though: the architecture should be properly done. It can bite you back nastily down the track if there is a critical architectural issue. And also, you have to keep in mind that the 'quick and dirty' will pretty much have to be thrown away and replaced by proper quality code to move forward.
When in a more advanced phase, where you have your grounds and you are starting to grow and eventually scale, then I would say good quality code is absolutely paramount. Not only because as @mcflydev mentioned bugs are a total deterrent to users, but also - and probably more importantly - because if you do not do it right, you create "tech debt" for your company.
As time goes that debt -like any other - can become extremely expensive and crippling.
As a developer with a lot of experience, I can say that it's a total tradeoff and the right answer is balancing.
You want to wrote and process quick so you can wrote test that is very important and get also cover code.
If you wrote bad code your velocity and your productive in the begining will be fast but after a while you will be slower and slower depend on your feature amount