You made something that people got a lot of value out of. That’s incredible. The actual code and commits are just the journey. They’re not the product. I’m rather delighted every time someone shows a realistic journey full of all the things we all experience, but some of us pretend don’t happen. Thanks for being vulnerable and sharing this.
When I first started coding (some 15 years ago) I wrote the ugliest, buggiest and "owasp-ridden-est" PHP spaghetti code. Turns out that code went viral and was used by millions of users for a few years.
Yet, I came to the conclusion that that's the best code I've ever written, for it's been the most used code I released so far.
Real software development is far different than the ideal one.
Software managers take note… Your MVP isn’t necessarily your perfect code. It’s the messy, “get it out the door”, value it brings to others. This is your product, refine it from there but don’t hold it back for sake of polishing a turd. Myth busters proved you can indeed, polish a turd. Don’t waste the sprints.
No, that's just wrong. It's totally fine to put scrappy code up to get a product going, but that time has long since passed if you're already at a scale to have dedicated managers.
At that point you're likely going to cause more damage to the brand/corp with the half-assed implementation then the value you're providing with said code.
This. A thousand times this. I work on a household-name product with millions of users. It works pretty well most of the time but also has frequent outages, bugs, and usability issues, during which times the 1-star reviews pile up.
By far our biggest problems are:
1. Leadership at the time just wanted an MVP, and they wanted it yesterday.
2. Leadership now believes "You don't need more people, and rewrites are a waste of time. Look what we've built with a skeleton crew and tight timelines!"
Fellow engineers, beware: if you train your leaders to believe your team can deliver with no budget and unrealistic timelines, they will continue to give you no budget and unrealistic timelines.
Those are indeed leadership failings. After-market processes should be put in place to ensure quality. If that means slowing the cadence of releases, fine, so long as the value delivered is there. If you have millions of users, it sounds like it is. In which case my point about just getting it out the door isn’t applicable.
I tend to agree with this. My spouse is currently entrenched in an over-budget, under-funded, mismanaged project that was recently announced by the CEO.
That’s at a Fortune 500. It all started with a “well we can do an MVP and get that out the door first.”
You'll note I said MVP. To get the product going. I agree that once it's going it's best to refine and polish tested features but software managers are still usually hands on at launch phase. Once you have your fit then follow best practice and have a proper process in place (agile, waterfall, whatever). What scale does one have to be to have a manager? Do companies operate without management?
