4 ms·

You know, these conversations always seemed to come down to discussions of "good code" vs. "ship quickly". I don't think that the point. Getting an MVP to marke

You know, these conversations always seemed to come down to discussions of "good code" vs. "ship quickly". I don't think that the point. Getting an MVP to market takes more than one iteration on the code, and even as early as refactor/debugging number 3, you can (and will!) be bit by bugs written in iteration 1 if you're writing bad code. The best stories are always about bad decisions from 6 months ago or more, but this can happen in the course of a single weekend. Writing good, clear interfaces and using them appropriately does not slow you down. It lets you move faster, think clearly, solve harder problems, and build more.

dustingetz 15y ago
a lot of projects are taking a soft process, like legal compliance, and trying to automate it. when you have requirements like < http://c2.com/cgi/wiki?WhyIsPayrollHard http://c2.com/cgi/wiki?WhyIsPayrollHard > perhaps the best factoring of interfaces, the best set of metaphors, aren't obvious, or are shifting. It certainly isn't something you can get right on the first try - if it was, we'd just Waterfall it and call it a day. So, yes, it is precisely a balance between future agility and shipping now - except if you don't ship now, you might not need the future agility ;) me saying this is particularly ironic because i'm the guy pushing scala adoption, clean code, fixing our abstractions, etc. i'm also less valueable to the business over the one-year timeframe that dictates my comp because of it. The only people incented to relenentlessly care about things like technical debt are those with equity.
- trjordan 15y ago
  Oh, for sure. I'm not advocating getting it right on the first try -- that's crazy talk. I'm mostly thinking about programming in the small: methods, classes, parameter lists, that sort of thing. Essentially complex problems can't (and shouldn't) be solved up front, but that doesn't imply the internals of that partially-solved problem should be disorganized, or that the API is inconsistent. I find that if I explicitly scope my work as I'm doing it, I can write good code to fuzzy specs, without over-generalizing, relatively quickly. Plus, coming back to it a couple months later (well within the typical employee-raise timeframe), I can fix or modify it much faster. It's a balance, to be sure, but I think it's sometimes possible to work both faster and better.
medius 15y ago
In the past, I too would have thought that good code needs to take a backseat when shipping is a priority. But now I have realizes that if I just think for about 5-10 minutes, I am able to avoid a lot of mess for almost no penalty in shipping time. Good design keeps things clear in code and in your mind. It can handle changes a whole lot better as well.

dustingetz 15y ago

a lot of projects are taking a soft process, like legal compliance, and trying to automate it. when you have requirements like < http://c2.com/cgi/wiki?WhyIsPayrollHard http://c2.com/cgi/wiki?WhyIsPayrollHard > perhaps the best factoring of interfaces, the best set of metaphors, aren't obvious, or are shifting. It certainly isn't something you can get right on the first try - if it was, we'd just Waterfall it and call it a day. So, yes, it is precisely a balance between future agility and shipping now - except if you don't ship now, you might not need the future agility ;) me saying this is particularly ironic because i'm the guy pushing scala adoption, clean code, fixing our abstractions, etc. i'm also less valueable to the business over the one-year timeframe that dictates my comp because of it. The only people incented to relenentlessly care about things like technical debt are those with equity.

trjordan 15y ago
Oh, for sure. I'm not advocating getting it right on the first try -- that's crazy talk. I'm mostly thinking about programming in the small: methods, classes, parameter lists, that sort of thing. Essentially complex problems can't (and shouldn't) be solved up front, but that doesn't imply the internals of that partially-solved problem should be disorganized, or that the API is inconsistent. I find that if I explicitly scope my work as I'm doing it, I can write good code to fuzzy specs, without over-generalizing, relatively quickly. Plus, coming back to it a couple months later (well within the typical employee-raise timeframe), I can fix or modify it much faster. It's a balance, to be sure, but I think it's sometimes possible to work both faster and better.

medius 15y ago

In the past, I too would have thought that good code needs to take a backseat when shipping is a priority. But now I have realizes that if I just think for about 5-10 minutes, I am able to avoid a lot of mess for almost no penalty in shipping time. Good design keeps things clear in code and in your mind. It can handle changes a whole lot better as well.