3 ms·

I definitely disagree with you on the first point. Setting aside the part that's just fussbudgetry, I think "proper" coding is about doing things that pay off

I definitely disagree with you on the first point. Setting aside the part that's just fussbudgetry, I think "proper" coding is about doing things that pay off in the long term even if they feel burdensome now. As an example, I'm a huge fan of good automated tests for long-lived code bases. But if I'm just writing a quick, throwaway script, then building a bunch of automated tests are going to slow me down. Throwaway prototypes are another area where you can save a lot of effort if you have really committed to throwing the code away once you've learned what you set out to learn. As a physical analogy, before the Long Now built out their bar/cafe space in San Francisco [1], we spent a day in the raw space building furniture and walls out of cardboard and tape [2]. It let us get a real sense of how the designs would work in practice for actual use of the space. In the past for a number of projects I've done throwaway prototypes and then started fresh with "proper" engineering, which for me usually includes pairing, test-driven development, and continuous deployment. I've also done ones where we think we understand it enough and just start building. And either way, we usually end up evolving ways to prototype on top of the existing platform via feature flags, etc, so we can learn something from the real world and then decide whether or not we want to refactor to accommodate a major change. [1] https://theinterval.org/ https://theinterval.org/ [2] https://vimeo.com/73959127 https://vimeo.com/73959127

neverthe_less 3y ago
Using boxes is great! The beauty of coding is that those boxes don't need to be discarded, we have the virtual power to transmute them into real chairs and tables via the power of refactoring. It's like Photoshop vs. watercolor. I'm going to sketch either way, it's just a matter of what the bar is for throwing it all out, and I think it's very often sufficient to decide in the moment in a virtual environment. That's all to say, going back to my first point, I don't need to decide ahead of time whether the code will be kept, I'm going to keep it loose either way. And there are situations I'd go in assuming I'll probably rewrite the work, but I wouldn't set the criteria so broadly as to cover literally whatever the next large project I embark on will be, as the article suggests.
- wpietri 3y ago
  If that works for you, great. But generally when I see people "keep it loose" on a prototype that then gets kept when some decision point is hit, they don't actually take the time to clean it up to production grade. And personally, although I'm very good at refactoring, I will still go the path of a disposable prototype in the future when I think it's more effective in terms of total effort. Which for me is any time I expect the prototype to yield significant information about both the surface and the substance of what we're doing.

neverthe_less 3y ago

Using boxes is great! The beauty of coding is that those boxes don't need to be discarded, we have the virtual power to transmute them into real chairs and tables via the power of refactoring. It's like Photoshop vs. watercolor. I'm going to sketch either way, it's just a matter of what the bar is for throwing it all out, and I think it's very often sufficient to decide in the moment in a virtual environment. That's all to say, going back to my first point, I don't need to decide ahead of time whether the code will be kept, I'm going to keep it loose either way. And there are situations I'd go in assuming I'll probably rewrite the work, but I wouldn't set the criteria so broadly as to cover literally whatever the next large project I embark on will be, as the article suggests.

wpietri 3y ago
If that works for you, great. But generally when I see people "keep it loose" on a prototype that then gets kept when some decision point is hit, they don't actually take the time to clean it up to production grade. And personally, although I'm very good at refactoring, I will still go the path of a disposable prototype in the future when I think it's more effective in terms of total effort. Which for me is any time I expect the prototype to yield significant information about both the surface and the substance of what we're doing.