2 ms·

Except that TM2 is vastly superior in almost every way to the original, it might be 'too late' but it is a great editor. Perhaps TM2 was possible as a series o

Except that TM2 is vastly superior in almost every way to the original, it might be 'too late' but it is a great editor. Perhaps TM2 was possible as a series of small changes, maybe it wasn't. But I think we should be grateful for the time spent on TM2, and that it is now open source so we can learn from it, and maybe even make it even better.

eurleif 14y ago
Maybe the real lesson here is, don't get in technical debt. Do it right from the start.
- zzzmarcus 14y ago
  If only it were that simple. The problem is that you don't know what the 'right way' is until you've done it once and discovered all of your the mistakes and pitfalls. The temptation then becomes to start over and do it right after having learned your lesson. The problem with that is that often, in addition to taking to long too start over, you just end up making a whole new set of mistakes.
  - pydave 14y ago
    I read the Mythical Man Month years ago and for a long time I've thought of this as the "second-system effect": You can create a much better architecture the second time around. (Hence the advantage of quick, throwaway prototypes.) The article (and wikipedia) tell me I'm wrong on Brooks' meaning.
  - UK-AL 14y ago
    Also most companies don't live in happy land, where you are allowed infinite time to do this things. It can be "I have one day, to a 4 day job", better hack it sort of thing.
  - ars 14y ago
    > The problem is that you don't know what the 'right way' is until you've done it once and discovered all of your the mistakes and pitfalls. Isn't that what experience is? (As opposed to talent.)
    - bps4484 14y ago
      But experience can't always prevent mistakes and pitfalls because you can't always predict the future. This is especially prevalent in the land of startups where you can think the most important thing is X, you build a bunch of stuff for it, then 3 months later the most important thing is Y, then a 3 months later the most important thing is Z, and all of the sudden you have a bunch of technical debt. Even if you could build X, Y, and Z "right the first time" those 3 month transitions may become 6 month transitions, and now you're out of business. (to be clear, those numbers are made up as an example) There are obviously best practices to be followed so you don't have big screwups or an unneededly bloated system, but sometimes these problems can't be prevented because you can't always predict the future.
FuzzyDunlop 14y ago
The problem with the approach is that rewriting from scratch means you have a bunch of great features you can't possibly implement until you've re-coded your original feature-set. It worked fine the first time, why chuck it out? Refactor it as you go along, for sure, but to toss out good work for some silly, non-existent ideal is fucking stupid. You should only resort to that if it's quicker and cheaper than trying to maintain the existing codebase.

eurleif 14y ago

Maybe the real lesson here is, don't get in technical debt. Do it right from the start.

zzzmarcus 14y ago
If only it were that simple. The problem is that you don't know what the 'right way' is until you've done it once and discovered all of your the mistakes and pitfalls. The temptation then becomes to start over and do it right after having learned your lesson. The problem with that is that often, in addition to taking to long too start over, you just end up making a whole new set of mistakes.
- pydave 14y ago
  I read the Mythical Man Month years ago and for a long time I've thought of this as the "second-system effect": You can create a much better architecture the second time around. (Hence the advantage of quick, throwaway prototypes.) The article (and wikipedia) tell me I'm wrong on Brooks' meaning.
- UK-AL 14y ago
  Also most companies don't live in happy land, where you are allowed infinite time to do this things. It can be "I have one day, to a 4 day job", better hack it sort of thing.
- ars 14y ago
  > The problem is that you don't know what the 'right way' is until you've done it once and discovered all of your the mistakes and pitfalls. Isn't that what experience is? (As opposed to talent.)
  - bps4484 14y ago
    But experience can't always prevent mistakes and pitfalls because you can't always predict the future. This is especially prevalent in the land of startups where you can think the most important thing is X, you build a bunch of stuff for it, then 3 months later the most important thing is Y, then a 3 months later the most important thing is Z, and all of the sudden you have a bunch of technical debt. Even if you could build X, Y, and Z "right the first time" those 3 month transitions may become 6 month transitions, and now you're out of business. (to be clear, those numbers are made up as an example) There are obviously best practices to be followed so you don't have big screwups or an unneededly bloated system, but sometimes these problems can't be prevented because you can't always predict the future.

FuzzyDunlop 14y ago

The problem with the approach is that rewriting from scratch means you have a bunch of great features you can't possibly implement until you've re-coded your original feature-set. It worked fine the first time, why chuck it out? Refactor it as you go along, for sure, but to toss out good work for some silly, non-existent ideal is fucking stupid. You should only resort to that if it's quicker and cheaper than trying to maintain the existing codebase.