Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It took 12 weeks to ship an MVP I thought would take 3

boxci.dev

Post reply on HN
Print view View original

211–220 of 221 posts

Re: It took 12 weeks to ship an MVP I thought would take 3

#211

Post by davnicwil »

marcosdumay wrote: post #210
davnicwil wrote: post #115

Earlier quoted context omitted.

The blog is just attached to the product site https://boxci.dev , thats the reason for using kube. Should be separately hosted but this was just simpler. The static blog pages though are all cached via nginx so I was surprised I needed to increase the nodes & relicas. Short answer is I don't know, and will need to investigate, but I suspect it's because the kubernetes node instances themselves are fairly low powered,…

> Should be separately hosted but this was just simpler. Probably shouldn't. If you are already managing an automated environment, creating another environment that is easier to manage has nearly no upside. Unless that phrase was meant to use the CDN you talk about later, but again, do you need a CDN to solve the easiest part of your infrastructure? (Or rather, do you have enough traffic so that it isn't the easiest…

Yeah my phrasing wasn't that clear there but I essentially meant hosted as in cached on CDN servers, just to reduce load on the nginx instances. Though my best guess at the moment for what was causing things to be slow was just sending the JS bundle to so many simultaneous users. Putting that on a CDN may be enough.

Re: It took 12 weeks to ship an MVP I thought would take 3

#213

Post by davnicwil »

rkangel wrote: post #157

I agreed with everything right up until the "extra time for design" section. I spent last year building a startup and have thought a lot about MVPs. Coming from a background of building big expensive systems, it took a lot to shake the mindset of "do it right from the ground up". My cofounder did a great job at pushing me towards the absolute minimal solution to learn what we wanted to learn - I don't need to spin up…

> What was the problem with launching, and then deciding that design was the next priority and working on it while your product was running?

Great question, and one I asked myself when I was about 2 weeks into the redesign :-)

On reflection, basically no, you're right, there was no reason I couldn't have shipped and then improved the design in the meantime. The thing about it not being good enough for people to pay for was just my opinion - not tested with real customers.

Re: It took 12 weeks to ship an MVP I thought would take 3

#214

Post by chrisweekly »

mathgladiator wrote: post #90
chrisweekly wrote: post #82

Earlier quoted context omitted.

A 2-year horizon -- even for massive, strategically sound projects -- is a non-starter, simply untenable in virtually every situation I've encountered in my 21-yr career in software dev and mgmt and consulting. Not saying you're wrong to think and advise in those terms, just that the opportunity to do so is exceedingly rare. Big public companies tend to be overly constrained by quarterly myopia, and startups usually…

I think it depends on scale and the inertia involved, and my original point was that accurate estimation is possible. There are many other challenges as you point out. I am currently on year two of a five year project. The key (and part of the essential difficulty) is finding quarterly or six month valuable deliverables that help ease anxiety of everyone involved. It is not easy, but it is possible. While all this is…

Right on. Good luck!

Re: It took 12 weeks to ship an MVP I thought would take 3

#215

Post by mattmanser »

TeMPOraL wrote: post #186
laumars wrote: post #158

Earlier quoted context omitted.

In my experience working in a broad range of fields in IT; web development is quite unlike any other type of development when it comes to code reuse and framework churn.

IME, web frontend might be particularly repeatable once you drop the artistics. But when I was doing desktop development, beyond simple UI issues, almost all work I had was unique and dictated by customer's ever changing and ever weirder requirements. In backend work, similarly, pretty much everything I write is a new and unique flower on a unkempt bush of the overall architecture.

Not really, I've built all sorts of stuff, but ultimately when you're hooking together a client's accountancy SaaS to their order system, it's going to be roughly the same code and take the same time as the other umpteen times you've done it for other clients. But it'll be a little different as they're using Xero instead of Quickbooks which you used last, and they have a different order entity design because of X.

I really feel like anyone arguing otherwise is slightly delusional. I find it particularly funny the guy two up claiming frontend might be reusable code, but backend isn't.

Once you've done one invoicing/emailing/workflow/search system/time tracking/credit control/custom form designer/forecasting module/cash flow/etc./etc./etc. module for a client, you've pretty much done 'em all.

And after a certain point you can then start to estimate the complexity of other systems with a small amount of talking to the client and research that let's you know the scope and the gotchas.

Re: It took 12 weeks to ship an MVP I thought would take 3

#216

Post by AmericanChopper »

tsimionescu wrote: post #180
AmericanChopper wrote: post #145

Earlier quoted context omitted.

What your describing is exactly the problem that decent planning solves. I can only imagine two possible reasons for the type of pivot you’re talking about. Either the problem you’re trying to solve has changed (not very likely), or your understanding of the problem has. You can avoid that, and all of the time you’ll waste, but simply investing the effort required to properly understand the problem up front. This is…

To give some more context, I'm working in a medium-size, well-established company in its field. The kind of problem we have when launching a new product is that we can have a well-defined list of everything that is required of the new product to be assured of successf - it's going to take 5 years to build that, with at least 20 people. What can we cut and still have a successful product, that we can launch in say 1 y…

Without trying to sound rude, this is just your organisation being bad at business.

> a well-defined list of everything that is required of the new product to be assured of success

Only bad software tries to be everything to everybody (not to shit on bad software, it’s a multi-billion dollar industry). Your customers have a problem that other products weren’t solving, your solution to this problem is the core of your value proposition. It’s the only thing you need to implement to launch your product, everything else can be added iteratively over time. If you don’t know what that problem is, then you’ve failed before you’ve even started. You’re not driving your company forward by writing code as soon as possible, you’re just doing skids in the parking lot.

I’ve seen so many people get sucked into the fiction that their product is by necessity too complex to plan and design properly. In reality I’ve never seen it to be anything other than a cover for not actually knowing how to run a product well. You’re not saving any time by making it up as you go. All of the design decisions you need to make still need to be made, you can choose to make them in a controlled manner, or just do it randomly and hope you pull through. But good design is not an emergent outcome of the resources you devote to implementation.

Re: It took 12 weeks to ship an MVP I thought would take 3

#217

Post by triggercut »

endymi0n wrote: post #135
pgt wrote: post #117

How did you manage to constrain the time overrun to only 4x? As a mercenary engineer, I've had to answer the estimation question many times. Whenever I've given estimates, it has only ever shot me in the foot. Spolsky might have figured it out, but I haven't. So I try to avoid giving estimates as far as possible and instead focus on demonstrating velocity of a working system they can choose to stop funding at any tim…

Having done hundreds of small to mid sized projects I take comfort in the fact estimating is a very distinct task that even the best of developers learn last. I've got three tricks in my pocket that at least help me with this: The first is that I go by the formula mentioned in "The Mythical Man-Month" — which is that the effort in larger projects is distributed as follows: 1/3 planning 1/6 coding 1/4 component test a…

>>If you find something that accelerates complex projects, let me know ;-)

I know this was partly joking but there are two real ways:

Knowing your true critical path and proactively re-plan and manage the risk of those activities that sit on it to clear the way for it to run smoothly... that's of course assuming you planned and estimated it correctly in the first place.

If you have a real schedule that is properly resource and risk loaded, run it through a monte carlo sensitivity analysis and see if you can re-plan those highly sensitive activities or de-risk them.

Re: It took 12 weeks to ship an MVP I thought would take 3

#218

Post by nl »

TeMPOraL wrote: post #189
nl wrote: post #156

Earlier quoted context omitted.

For me, research is something where is is unknown if something is possible. Engineering is where we know it is possible, even if it isn't clear how long it will take.

Under that definition, very little is research. Warp drives is research. Curing cancer is engineering. Obviously, you have implicit constraints in mind. "Is something possible given $constraints?". And the set of those constraints is where the line between research and engineering starts to blur. If you set $constraints to "in time and under budget for the project", which seems like a very reasonable value, then it t…

We don't know if (all) cancer can be cured at all.

And no, "in time and budget" doesn't suddenly make something into a research project.

Speeding up some technical process might be research (eg, the old 1TB sorting benchmarks drove research).

But project constraints, and the fact that the team themself has never used a specific technology or whatever doesn't turn it into research. Yes, I know that's a term people use, but it's a different thing to scientific research.

Re: It took 12 weeks to ship an MVP I thought would take 3

#219

Post by darkerside »

eecc wrote: post #106
darkerside wrote: post #69

Earlier quoted context omitted.

The biggest problem I've found with this approach is that it drives the prioritization process towards smaller and smaller pieces of work, because those can be accurately broken down and estimated. This means larger, but proportionally much more valuable, pieces of work do not get picked up.

Hmm, I disagree. The larger and valuable pieces are broken down into quantifiable parts, but are still being done. Less unpredictability, and that’s the point.

I can only speak to my experience. The friction involved in slicing those pieces of work ends up creating a sizable force. I'd love to hear more about how you've handled it well.

Re: It took 12 weeks to ship an MVP I thought would take 3

#220

Post by eecc »

darkerside wrote: post #219
eecc wrote: post #106

Earlier quoted context omitted.

Hmm, I disagree. The larger and valuable pieces are broken down into quantifiable parts, but are still being done. Less unpredictability, and that’s the point.

I can only speak to my experience. The friction involved in slicing those pieces of work ends up creating a sizable force. I'd love to hear more about how you've handled it well.

Well that force is the design effort. “How do I break this up in parts?” “I need to test this”, “I need to isolate that or it’s not manageable”. Otherwise you’re just cowboy-coding, shaving yaks along the way to implementing the Epic Goal, leaving a trail of legacy
Post reply on HN