Quick and dirty development is fine. However, you need to be prepared to also retire software with extreme prejudice when it has served its purpose. Developers chronically underestimate the lost time and money associated with shipping late or not at all. For an MVP, getting it out asap allows you to validate assumptions earlier. Building the perfect solution before you do that is hard because you don't have all the facts. The whole point of an MVP is to ship it fast so you can validate your assumptions. Of course building a future proof MVP is even harder because you have very imperfect knowledge of the future. Lots of teams get sucked into building stuff perfectly that will never be used; often at great cost. Most features that sound like a good idea may never be used or simply be ignored by users.
Greenfield development without an MVP is highly risky and expensive. So limit the scope of your MVPs and plan for their replacement early on. Micro services are great for this since they have limited scope and relatively clean interfaces which means you can just rip them out and replace them when they become a problem.
Indeed, MVP has nothing to do with perfection... I would even ask if perfection is possible. I agree devs should have business concerns in mind. However, I think we have a different understanding about MVP.
Minimal Viable Product, aka MVP, is about finding the minimal necessary to launch a product.. it has nothing to do low software quality. Finding the minimal necessary to get a product running and starting getting feedback soon is about understanding what your product is going to ship. In that way, the idea behind MVP is to minimalize features. At the same time, quality should still be a concern..
As you said: who has never implemented a feature that was never used? That should be solved by identifing exaclty what is the minimal necessary.
But: who has ever thrown an MVP away after having validated it? Starting with a mess sounds not to be a good deal.
Of course, it is important not to waste time to have a top tech environment right from the first release iteration.. it would be just over-engineering. It should be achieved time by time, iteration by iteration while the application is getting mature.
I don't if I could make myself clear. This is also an extensive topic .. I think the keyword is simplification :)
The word MVP gets abused a lot in our industry. Early validation of assumptions (e.g. users will use this, this actually works, customers actually will pay for this, etc.) is a valid thing though.
In my experience, most software developed does not get to celebrate a second anniversary. And if it does, extensive refactoring is likely to happen several times in any case. There is a notion of throwaway software. With that in mind, quality is important only in so far as it does not slow you down. Getting stuck doing extensive changes on a shitty code base is bad, of course. However, a cheap, low quality but functional MVP that you ship fast can be replaced easily and give you early feedback on assumptions that you have made about the viability of your product. Engineer for replaceability rather than maintainability. Shipping months earlier ultimately buys you a lot of runway and early revenue that you can use to ship something better later. The longer it takes you to ship the less likely it is to be the right thing.
I've been on more than a few projects where more than half of the features that PMs insisted were absolutely critical eventually were scrapped because they were not needed, redundant, or because users simply don't use them. Engineers like to over-engineer. PMs always want everything and the kitchen sink. And customers always ask for more than is good for them. However, building the wrong thing for the wrong reasons in an MVP means you are shipping the wrong things way too late thus delaying the moment you know the thing is actually viable.
A feature MVP can simply be having a mock button in a UI and measuring if users actually bother to click that with some analytics. Compare that to implementing backend services, investing in devops to deploy, and finally doing the frontend work to hook up the stuff and gradually phasing in the button via AB testing in the hope that users will actually click the button. This stuff is really expensive and there is an enormous amount of waste effort in our industry.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Quick and dirty development is fine. However, you need to be prepared to also retire software with extreme prejudice when it has served its purpose. Developers chronically underestimate the lost time and money associated with shipping late or not at all. For an MVP, getting it out asap allows you to validate assumptions earlier. Building the perfect solution before you do that is hard because you don't have all the facts. The whole point of an MVP is to ship it fast so you can validate your assumptions. Of course building a future proof MVP is even harder because you have very imperfect knowledge of the future. Lots of teams get sucked into building stuff perfectly that will never be used; often at great cost. Most features that sound like a good idea may never be used or simply be ignored by users.
Greenfield development without an MVP is highly risky and expensive. So limit the scope of your MVPs and plan for their replacement early on. Micro services are great for this since they have limited scope and relatively clean interfaces which means you can just rip them out and replace them when they become a problem.
Hello Jilles! Thank you for your comment!
Indeed, MVP has nothing to do with perfection... I would even ask if perfection is possible. I agree devs should have business concerns in mind. However, I think we have a different understanding about MVP.
Minimal Viable Product, aka MVP, is about finding the minimal necessary to launch a product.. it has nothing to do low software quality. Finding the minimal necessary to get a product running and starting getting feedback soon is about understanding what your product is going to ship. In that way, the idea behind MVP is to minimalize features. At the same time, quality should still be a concern..
There is this interesting interview with Eric Ries (creator of the term MVP).
Of course, it is important not to waste time to have a top tech environment right from the first release iteration.. it would be just over-engineering. It should be achieved time by time, iteration by iteration while the application is getting mature.
I don't if I could make myself clear. This is also an extensive topic .. I think the keyword is simplification :)
The word MVP gets abused a lot in our industry. Early validation of assumptions (e.g. users will use this, this actually works, customers actually will pay for this, etc.) is a valid thing though.
In my experience, most software developed does not get to celebrate a second anniversary. And if it does, extensive refactoring is likely to happen several times in any case. There is a notion of throwaway software. With that in mind, quality is important only in so far as it does not slow you down. Getting stuck doing extensive changes on a shitty code base is bad, of course. However, a cheap, low quality but functional MVP that you ship fast can be replaced easily and give you early feedback on assumptions that you have made about the viability of your product. Engineer for replaceability rather than maintainability. Shipping months earlier ultimately buys you a lot of runway and early revenue that you can use to ship something better later. The longer it takes you to ship the less likely it is to be the right thing.
I've been on more than a few projects where more than half of the features that PMs insisted were absolutely critical eventually were scrapped because they were not needed, redundant, or because users simply don't use them. Engineers like to over-engineer. PMs always want everything and the kitchen sink. And customers always ask for more than is good for them. However, building the wrong thing for the wrong reasons in an MVP means you are shipping the wrong things way too late thus delaying the moment you know the thing is actually viable.
A feature MVP can simply be having a mock button in a UI and measuring if users actually bother to click that with some analytics. Compare that to implementing backend services, investing in devops to deploy, and finally doing the frontend work to hook up the stuff and gradually phasing in the button via AB testing in the hope that users will actually click the button. This stuff is really expensive and there is an enormous amount of waste effort in our industry.