|
I feel it depends on what you mean by "bad code". We went through a very tough journey ourselves. When I started the company, I wanted us to just use out of the box Rails. But some senior devs disagreed - we had huge disagreements about it. We ended up spending months building a complex SOA, only to find 3 years later that it wasn't a great implementation and rewriting it (now it's even more complex). Meanwhile, Shopify and others seem to be happily still using mostly stock Rails. And we're in a tough spot where finding developers who can work and be productive with our NIH-stack is quite challenging. I agree with what the others are saying here. Customers aren't buying our code, they are buying our product/service. Code should not be "bad" (i.e. there should be tests, etc.) but as a startup, I think velocity is more important and we just have to weigh that. We can hack stuff temporarily to ship or do experiments, but we'd have to deal with the debt if we keep that around. If I had the opportunity to start all over again, I would:
- Stick to well-known frameworks. Use "boring" tech.
- Outsource as much as possible first and don't reinvent the wheel e.g. don't write your own subscriptions/billing, just use Stripe/Braintree/Recurly/Chargebee, use Algolia (don't write your own Elastic) for search, etc. Move fast until you've figured out product/market fit, then optimize for costs, etc.
- Stand your ground on rejecting NIH. Devs will complain because they want space to learn, try new tech, do NIH things (I want to hack stuff to!). IMO it's those NIH things that are often said to be "bad code" - they're not "bad", they were just written in a short amount of time to solve immediate problems and they often don't account for all the strange edge cases, etc. |