5 ms·

> Go spend some money on offshore coders and get a prototype built. But please, PLEASE know that that is a prototype and that your technical cofounder will lik

by chowes 10y ago

> Go spend some money on offshore coders and get a prototype built. But please, PLEASE know that that is a prototype and that your technical cofounder will likely want to throw it out the door on day 1. Nothing is a worse conversation than "okay, so I have the v0 built offshore, but it just needs X, Y, and Z". Great start, but let me pick the stack, framework, etc. so I can do my job quickly. I'm here to make decisions WITH you, not be your code monkey.

ones_and_zeros 10y ago
If you are a cofounder and your #1 priority is to rewrite the application then you are their code monkey. If the offshore team works just stick with it so you can focus on technology strategy.
- eric_h 10y ago
  > If the offshore team works just stick with it That is a big "if". A good technical cofounder will identify the latent technical debt that exists in an outsourced prototype and if that number is too high, a rewrite can be justified.
  - jeffasinger 10y ago
    I worked at a company where the founder had started with some local contractors to build an initial version of the product. He hired a CTO, who took a look at the current code, list of bugs, and new features desired, and made the call to do a complete rewrite. In retrospect, this was absolutely the right call. It can definitely be wasteful, but sometimes starting with a completely new design is the right thing to do.
- gremy0 10y ago
  Surely he just means he wants a green field to work with. I mean do you really want to start as a Technical Co-founder at a new startup and have legacy systems already.
- ihsw 10y ago
  It's more than rewriting the application -- it's ensuring the foundation is sound. It would be irresponsible to not be very skeptical of the code as it's usually trash, and trash code will scare away any and all future tech employees. The annual turnover will be >100%, guaranteed. No company can sustain that level of turnover.
- tedmiston 10y ago
  But usually what happens is the offshore prototype is junk, _but_ the (non-technical) founders ship it because it's "good enough". Then they want it to be iterated on even though it was supposed to be a prototype. Every time I have to use an iPhone app with broken non-standard UI components and UX it makes me sad.
  - codingdave 10y ago
    That is what non-technical co-founders hear all the time, though -- throw something together that is "good enough" for an MVP, and iterate later. I find that the real key is working with coders who can refactor one component at a time, without requiring a re-write from scratch. Then you actually can iterate on a junk codebase.
    - joncrocks 10y ago
      This only works if you've built the software to be a MVP vs. a prototype. A prototype is something that you build and then throw away, a MVP is the minimum feature set that can be given to customers, developed with the same quality and values as your eventual product that can be expanded upon. So be clear what your trying to built at the start, and make sure you build the right thing.
      - deleted 10y ago
        [deleted]
    - tedmiston 10y ago
      I think MVP ≠ prototype. To me prototyping is about the quality of the code, and MVP is about trying to find the minimum feature set. I think it's a mistake to not throw away a prototype. You could be starting day 1 with so much tech debt that it would take longer to fix it all vs. design and develop an MVP properly in the first place.
- abstractbeliefs 10y ago
  I think probably a better middle ground would be "have the authority to rewrite it all from scratch". If you're the technical cofounder, you need to drive the technology, and part of the technical side is knowing and being able to throw out junk at the expense of time and money lost if needed, while your cofounder side should be carefully balancing up the value of doing so. If the offshore stuff works, great, build on it. If it doesn't rewrite it. If the architecture is good, but not the implementation, incrementally swap out what you can, as you need.
melvinmt 10y ago
Nothing is a worse conversation than an engineer trying to rewrite all the code for no business critical reason. I definitely understand that working with crappy offshore code is a pain in the ass (doing that now!), but if it works, it works. I've worked on enough crappy code bases for successful companies (as in $100M/yoy revenue on "prototype" code) to realize that these worries we have as an engineer really don't matter. The only thing that ultimately matters for the business is having something that people want to use.

by chowes 10y ago

ones_and_zeros 10y ago

If you are a cofounder and your #1 priority is to rewrite the application then you are their code monkey. If the offshore team works just stick with it so you can focus on technology strategy.

eric_h 10y ago
> If the offshore team works just stick with it That is a big "if". A good technical cofounder will identify the latent technical debt that exists in an outsourced prototype and if that number is too high, a rewrite can be justified.
- jeffasinger 10y ago
  I worked at a company where the founder had started with some local contractors to build an initial version of the product. He hired a CTO, who took a look at the current code, list of bugs, and new features desired, and made the call to do a complete rewrite. In retrospect, this was absolutely the right call. It can definitely be wasteful, but sometimes starting with a completely new design is the right thing to do.
gremy0 10y ago
Surely he just means he wants a green field to work with. I mean do you really want to start as a Technical Co-founder at a new startup and have legacy systems already.
ihsw 10y ago
It's more than rewriting the application -- it's ensuring the foundation is sound. It would be irresponsible to not be very skeptical of the code as it's usually trash, and trash code will scare away any and all future tech employees. The annual turnover will be >100%, guaranteed. No company can sustain that level of turnover.
tedmiston 10y ago
But usually what happens is the offshore prototype is junk, _but_ the (non-technical) founders ship it because it's "good enough". Then they want it to be iterated on even though it was supposed to be a prototype. Every time I have to use an iPhone app with broken non-standard UI components and UX it makes me sad.
- codingdave 10y ago
  That is what non-technical co-founders hear all the time, though -- throw something together that is "good enough" for an MVP, and iterate later. I find that the real key is working with coders who can refactor one component at a time, without requiring a re-write from scratch. Then you actually can iterate on a junk codebase.
  - joncrocks 10y ago
    This only works if you've built the software to be a MVP vs. a prototype. A prototype is something that you build and then throw away, a MVP is the minimum feature set that can be given to customers, developed with the same quality and values as your eventual product that can be expanded upon. So be clear what your trying to built at the start, and make sure you build the right thing.
    - deleted 10y ago
      [deleted]
  - tedmiston 10y ago
    I think MVP ≠ prototype. To me prototyping is about the quality of the code, and MVP is about trying to find the minimum feature set. I think it's a mistake to not throw away a prototype. You could be starting day 1 with so much tech debt that it would take longer to fix it all vs. design and develop an MVP properly in the first place.
abstractbeliefs 10y ago
I think probably a better middle ground would be "have the authority to rewrite it all from scratch". If you're the technical cofounder, you need to drive the technology, and part of the technical side is knowing and being able to throw out junk at the expense of time and money lost if needed, while your cofounder side should be carefully balancing up the value of doing so. If the offshore stuff works, great, build on it. If it doesn't rewrite it. If the architecture is good, but not the implementation, incrementally swap out what you can, as you need.

melvinmt 10y ago

Nothing is a worse conversation than an engineer trying to rewrite all the code for no business critical reason. I definitely understand that working with crappy offshore code is a pain in the ass (doing that now!), but if it works, it works. I've worked on enough crappy code bases for successful companies (as in $100M/yoy revenue on "prototype" code) to realize that these worries we have as an engineer really don't matter. The only thing that ultimately matters for the business is having something that people want to use.