

Ask HN: Should you ship an MVP if your team isn't agile - JulianMiller520

I've been working with a vendor who is clearly on to something product-wise but the version they shipped is buggy and simple things like modal window controls aren't working. They impressed in the beginning but now the bosses are talking about ditching them because they aren't able to fix the features they shipped in a timely manner. It really made me wonder if they've done damage by shipping too early. Thoughts?
======
lucisferre
What I'm guessing you are looking at is a prototype, whether they know it or
not, and it is rarely a good idea to simply try to fix the bugs in a
prototype. They are great for validating early assumptions but typically
should be thrown away once that cycle is completed and rewritten.

Trying to improve and fix prototype code is typically very challenging. It
often has no architecture or structure, so changes and new features are slow
to implement.

If this vendor doesn't understand this, or it seems likely that having them
rewrite it would just result in another prototype quality result then your
bosses are right to walk away.

~~~
JulianMiller520
Great take! Any ideas for evaluating if they are stuck at the prototype phase?
Perhaps tell-tale signs you've seen in the past?

~~~
lucisferre
It's hard to say without knowing the situation and the team involved better.

Almost any really new software or even feature generally needs some amount of
prototyping initially and usually this will happen whether the team planned it
that way or not. However, if this step of the development process wasn't
communicated to you from the beginning then I would suspect that they are
either ignorant of this, or at least their organization is (I assume this is a
contract or agency situation?). Either situation will be a potential problem
for your company since it means they will continue to accrue technical debt
rather than iterating on the prototype.

Done properly the prototype is either all or mostly thrown out and re-built
from the ground up to improve and solidify the architectural and software
design aspects. This paves the way for future feature development to continue
unfettered by technical debt and early defects. Trying to simple cover the
defects with "duct tape" or "cowboy" code is likely to cause the rest of the
work to slog on and future iterations an feature development will become very
slow.

However, without knowing more about your situation I'm not sure how useful or
correct my advice is here.

