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

3 pointsJulianMiller52014y ago3 comments

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?

3 comments

lucisferre14y ago

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.

JulianMiller520OP14y ago

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

lucisferre14y ago

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.

j / k navigate · click thread line to collapse

3 comments

lucisferre14y ago

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.

JulianMiller520OP14y ago

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

lucisferre14y ago

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

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

j / k navigate · click thread line to collapse