Yeah that's great if you're not planning to work on the app ever again or be gone from the company in a year.

The general point of the MVP is that you don't think about these things at all and do whatever is expedient to get to the minimum presentable thing. I guess your question is really about in practice, how strictly should people adhere to the idea of MVP? That's totally context-dependent. In some cases, your MVP may be designed to see if there's a market or a potential internal support for some speculative idea you had. Worrying about the future can then be a waste of time - just get to the point where you can get answers to the questions you need answered to make decisions. In other cases, future development phases may have already been planned and the MVP is just the first phase of a long-term, iterative development effort. Then you need to make sure not to sabotage your future efforts.

Like candybar said, it just depends on how V your MVP is supposed to be. If it is something you are just going at quick and dirty to figure out a larger question "is there even a market fit for this?" "is this idea terrible?" then you shouldn't be making any type of future decisions, you just get from point A to point B asap.

This.

A tracking database that doesn't track anything doesn't sound very viable. I think being able to recognize different users and some of their activity, like logging and logging out in a log file is viable. It's demoable and if you're ahead in the sprint you can add more activities. An MVP is the first step to a useful product that your customers can get use out of. It is the base for the rest of the features in your product, I'm not sure where you get the idea it's throw away code, but it's wrong.

A good example of this is we have a policy in this company that JSP changes can be pushed a few times a week relatively easily, whereas Java code changes require an "emergency" release and a ton more bureaucratic hoops to jump through. So in the past developers have been pressured into putting nasty deep business logic Java code into a JSP, which everyone knows belongs in the Java back end structure, to get it out the door quicker.

Eventually senior devs got enough clout to put a stop to this. The manager who wants their thing and they want it now doesn't have to maintain the mess they leave behind. We do. We're the ones who have to work nights and weekends fixing endless bugs on an increasingly unmaintaianble code base. And we're the ones who have to answer when 6 months down the line some code in the JSP that goes straight to the DB causes the site to crash under heavy load. That impatient manager is not responsible. But of course he's back now wondering why it's going to take 3 months to add a few tabs to the website.

Suzzer, there's so much broken in what you wrote that I don't think it's really about getting from point A to point B asap.

Well I mean in small/medium app world there's "push it out the door". But in monster website world everything is integrated with everything else. You have to do things right or you create a giant cluster****.

CSS humor: http://digitalsynopsis.com/design/34...n-funny-jokes/

suzzer,

I'm sure at your company with 30b+ revenues you do a ton of work on MVPs that are totally relevant to this discussion! Thanks for the contribution!

I don't see how analytics are ever a feature attached to something that constitutes the MVP. The analytics are used to iterate the product.


So... no.

We have things we call MVPs. What are the things you're talking about? I just assumed MVP meant, "drop what you're doing and implement this as fast as possible".

Hey guys, anyone with some good Clojure material?

Very cool discussion and it definitely sounds like my initial hunch was correct, which is to just not worry about it for now. I share suzzers feelings however after working on an enterprise code base for years and that's probably where my hesitation comes from.

However, I think people are taking the concrete example I had a little too head on. It was more of a "we can do this quickly now and ship the mvp sooner but it's not maintainable or scale able code" internal debate. Sounds like shipping the core features is all that matters.

Also suzzer that jsp thing makes my heart hurt

No. That is completely and totally wrong. I don't even know why you'd chime in with such an absurd guess.

Part of moving to node, away from ATG, is to make our code a lot more modular so that everything doesn't affect everything else - "micro sites". It's definitely paid dividends on the parts of the site we've being able to move so far.

WTF is wrong with you? In case you haven't noticed we're all generally pretty civil to each other around here. Go to SE if you want to get into trash-talking throwdowns.

Why are you personally attacking me? You posted a bunch of stuff that was totally inane and incorrect because you couldn't bother to google the term and didn't understand what it meant.

Can you comprehend that different companies might have things they call MVPs? Are you on your first programming job?

Tell me what I need to learn from this search: https://www.google.com/webhp?sourcei...amming%20world

A different search turned it up: https://www.techopedia.com/definitio...le-product-mvp - learn something new every day

LOL

I should think he'll reply soon, but if not DaveT is likely our foremost expert on Clojure here I think.


And yeah, MVP people keep calm and polite please info is good but no need to be aggro. FWIW I'm with candybar / Larry / Mihkel on this - features that "would likely be added later" are not the focus of creating / deploying an MVP imo. The general idea is to do as little as possible as fast as possible, in order to test the waters - see if it's worth the bother to even consider things that may be required later let alone implement them. Tbh doesn't really matter if you have to rewrite from scratch to implement these things - so long as your MVP was actually fast and minimal - at least you've proven there is a market for the product and the more detailed planning and implementation are less likely pointless. I mean, no harm in slapping a google-analytics bug on each page of a MVP website - you do want to know if anyone is using it after all! - but developing some in depth custom solution or even just the groundwork for one? no.

Doing things right doesn't mean bureaucratic hoops or back end releases that can only be done infrequently - that's all I meant. Hell, a monster website with everything integrated with everything else isn't doing things right either, imo.

It's really far from an environment where the MVP + iterate is even possible.

Also, Mihkel is a troll. Not having him on ignore is more wrong than monolithic rarely-released software.

Writing 'scalable' code from the start isn't even possible really. You have to make a bunch of assumptions and at least a few of them are going to be wrong.

Well yes now that I know what MVP means that makes a lot more sense. Which has me wondering if when our creative team talks about MVP's I've been misinterpreting them all this team. Ha.

And no, clearly everything affecting everything else is suboptimal on a monster website. ATG was state of the art technology in 2004. It supports e-commerce, content management, and has hooks that run from the HTML to the DB. It's a monolithic nightmare.

Mihkel also sent me a nasty PM. Trolls don't usually do that. I think I hurt his feelings. I'm not sure if he's a troll or just has the social skills of a feral pig.