Midwest Dev Chat

MidwestDevChat.com

  • The newest 15 messages in the super-cool #javascript channel.

  • 05/21 12:01:37 Keith: Yes, and the "shutdown" deadline has already slipped by 3 months. I do think it will go away sometime next year though.
  • 05/21 12:02:16 Keith: But yes. A couple jobs ago I was constantly railing against "temp-ermanent" fixes.
  • 05/21 12:06:13 Bobbi: 80% of the people who implemented the temp stuff left the company #winning
  • 05/21 12:07:29 Jenae: I’m working on a mvp right now. that’s all temporary, right?
  • 05/21 12:07:51 Mickie: a favorite: http://www.thecodelesscode.com/case/234
  • 05/21 12:08:15 Keith: Heh, yep.
  • 05/21 12:08:51 Keith: The whole concept of "MVP" drives me nuts. Personally I don't consider code viable if it's not supportable. :-/
  • 05/21 12:09:20 Keith: also secure.
  • 05/21 12:10:24 Kandace: nothing wrong with the concept, just the way many people implement it
  • 05/21 12:11:06 Keith: Yeah, I just feel like it's one of those things that too many people use as an excuse to write terrible code.
  • 05/21 12:26:59 Rhoda: It's fine to start by building something low-complexity, the trick is to scale your code organically as the complexity grows
  • 05/22 11:39:22 Sharilyn: I don't think building an MVP gives you the excuse of writing bad code. A prototype, sure, but not an MVP. Code should be production-grade for an MVP, there just won't be as much of it because you're not building #allthethings yet.
  • 05/22 14:32:09 Jesse: I’m living the entire MVP thing, my 2¢... Point of an MVP is fast iteration. Can’t iterate fast (and reliably) without decent code. If you’re actively planning to re-write your MVP, I think your approaching it wrong, however it will likely be rewritten in tiny pieces many times over its lifetime, if it gains traction. Your definition of production grade will also evolve overtime. At MVP time, production grade code could mean something significantly different than even a month down the line. An MVP comes with the assumption that users will do X or have problem Y, until you’ve proven those things and that your product fits, anything else you do has an incredibly high chance of being waste. It doesn’t matter if you have 100% unit test coverage for a product no one uses. As you get further and further from MVP you should start solving problems with longer and longer time horizons in mind with increasing engineering rigor and standards.
  • 05/22 16:23:33 Sharilyn: > Your definition of production grade will also evolve overtime. At MVP time, production grade code could mean something significantly different than even a month down the line. I think I agree with the goals of this. If I am working on an MVP, I need to be careful how much thought I put into the design, etc. because, as you said, it might get thrown out tomorrow. I might implement one of the first things that comes to mind (but implement it well) instead of building three different prototypes to find which one is flexible, etc. Finding the right balance there can be really tricky. Does that come with anything other than experience?
  • 05/22 17:18:35 Jesse: Eh. If you focus on optimizing for change and the ability to throw small pieces of code away and replace it quickly, work in small batches with a live product from, maybe not day 1, but maybe day 30, it certainly helps. It’s not like all design is bad, getting the architecture (all the things that are difficult to change) right early definitely helps, but if you can defer to a time when you know more, do that. Getting the boundaries of things right is incredibly important too. fwiw, TypeScript, React, Apollo, GraphQL, and Lambda/Serverless, SNS and SQS have been incredibly effective this go around for me. I have built more MVPs than I’d care to admit, but I have gotten much better at it.
  • *Usernames have been changed to protect the innocent.
We're currently 1164 members strong. Join us!
Request Invite

Check out all the cool channels!

Join the conversation!