6 ms·

Technical debt and tacking into the wind

118 points by GarethX 11y ago

lifeisstillgood 11y ago
well worth reading for the insight into behind the scenes at FogBugz - some depressingly clear headed and awkward discussions undoubtedly had. and one suspects another lesson - don't have your whole company dependant on one product. I still adhere to the idea that LOC is debt and LOTests is capital.
sopooneo 11y ago
FogCreek seems to be winning the game. So I agree with the sentiment that it was productive debt.
- mkozlows 11y ago
  Winning what game? I can't find solid numbers about bug-tracker marketshare, but if I type "FogBugz vs" into Google, it throws up Jira as the first result. If I type "Jira vs", FogBuz doesn't show up -- I get Rally, Trello, TFS, Redmine, and Asana first. FogBugz definitely used to have a lot of mindshare, but...
  - sopooneo 11y ago
    You have a valid point. But just as an aside, you know who makes Trello, right?
    - timv 11y ago
      Yes, that would be Trello, Inc https://trello.com/about https://trello.com/about The fact that FC managed to come up with a successful (but not necessarily profitable) product idea and spin it off into its own company doesn't really say much about the validity of their decisions on a completely different product. Nor is it evidence of Fog Creek "winning the game" (whatever that might mean)
      - deleted 11y ago
        [deleted]
    - serve_yay 11y ago
      Yeah - Trello Inc. :)
    - snowwrestler 11y ago
      Was Trello written in Wasabi, though?
  - rjbwork 11y ago
    Is there anything else like Kiln Harmony on the market? The ability for our developers to use Git or Hg (with a couple of caveats...) on any of our repositories is a great recruiting point.
    - chii 11y ago
      i really dont think anyone would base their choice on whether they used hg or git (or both, or either for that matter). It's a very small, and rather unimportant in the grand scheme of things.
  - hesselink 11y ago
    Yes, this doesn't look like winning: https://www.google.com/trends/explore#q=fogbugz%2C%20atlassian%20jira&cmpt=q&tz=Etc%2FGMT-2 https://www.google.com/trends/explore#q=fogbugz%2C%20atlassi...
  - snowwrestler 11y ago
    So maybe Fog Creek was correct to take whichever path cost the fewest resources. If it took fewer hours to write and maintain a small transpiler than to re-write the entire application, then that would help profit margins on a product that is not taking over the world anyway.
quanticle 11y ago
Looking back, maybe Fog Creek should have built itself a boat instead of walking up the beach. Except rule number one was never, ever rewrite code. That is the crux of the problem. Sometime requirements change enough that a total rewrite is the better and cheaper option. Having to support an entirely different operating system is certainly a change of that magnitude. Obviously, second guessing is easy and shipping is hard, but can anyone tell me coherently why Joel didn't push for a rewrite when he received the requirement to support Unix servers? My perceptions may be inaccurate here, but it seems like the reasonable thing to do when confronted with having to support Unix servers in addition to Windows is to rewrite the code in a cross platform way, and perhaps add shims to support the differences between platforms. I don't think I know anybody personally, whose response would be, "I know, let's write a compiler to translate our VBScript into something that runs on Unix." And in fact, lots of other successful companies (Twitter, Reddit to name two offhand) have successfully embarked on full rewrites, with much less justification than having to support a brand new OS. It seems to me that Joel was so committed to his "don't rewrite" principle that he was willing to take on a massive amount of technical debt to avoid comprimising on it. Which... well, it worked out well in this case, but I have a hard time seeing it as good general advice to follow when building software.
- reymus 11y ago
  Well, the task of writing the compiler was given to an intern, so I would guess it was an experiment that ended up working well enough that became their strategy for supporting Unix.
- mwcampbell 11y ago
  It seems to me, as an outsider, that Joel's reason for avoiding a rewrite at any cost is because so many rewrites have failed. Perhaps it's better to prefer steady, step-by-step progress over a giant leap that might be a leap backward in the end. What is often forgotten in these discussions is that, because Fog Creek had talented programmers, writing Thistle and eventually Wasabi was just another series of steps on the road, not a giant leap as a rewrite would be.
- ams6110 11y ago
  I don't think I know anybody personally, whose response would be, "I know, let's write a compiler to translate our VBScript into something that runs on Unix." Yeah it was an odd strategy, I agree. But on the other hand, translating one scripting language to another doesn't sound sound that unreasonable either. From the article: The super obvious answer is to tell unix customers to install Chilisoft ASP. Boom. Done. Except it costs more than FogBugz does. I remember hearing of Chilisoft ASP. Never used it, and I have no idea what it cost. I'd be curious if they attempted to negotiate any kind of discount for Chilisoft ASP, maybe locked to FogBugz somehow. Compared to running FogBugz on ASP, which I'm guessing would have required at minimum a Windows Server and a SQL Server license, you'd think some kind of deal could have been arranged. The other thing I'm curious about is how many Unix installations of FogBugz were sold? From what I've seen, customers who are willing to actually pay for a bug tracker would not blink about buying a Windows server to run it, if that's what it required.
ChuckMcM 11y ago
I really like the metaphor of walking up the coast because you're getting closer to London. So many projects are like that, some sort of fitness function that tells you that you are getting incrementally closer to your goal, but nothing to tell you that you are fundamentally ill equipped to actually make it to your goal, or even that your entire strategy which is "working" is fundamentally wrong.
- cwyers 11y ago
  They made it to London, though.
peteretep 11y ago
> A much hipper programmer might say something like “you > ain’t gonna need it.” This is a little bit like saying "a much hipper programmer might describe this approach as being 'AJAX'", a term that is at least 4 years older than YAGNI :-)
mmphosis 11y ago
Those who don’t learn from history are doomed to repeat it. Any day now, I suspect some fools are going to want to write web apps, but they won’t want to use raw javascript and they’ll create some ridiculous custom language to javascript compiler. I can only hope they have the good sense not to tell anybody about it.
- hesselink 11y ago
  We wrote a custom language, only it's javascript. We built a very simple module/class system that compiles to javascript, in javascript. It consists of functions called 'Module', 'Class', 'Static' and such, that generate javascript code. This has had so much value for us. It allowed us to abstract some patterns into 'compiler extensions' for things like scoping, timeouts and cancellation, etc. And more recently, it allowed us to add typechecking by outputting typescript instead of javascript. I think it was a great idea and would do it again, but it's only been 6 years, so perhaps ask me again in 4 years :)
derefr 11y ago
So, what about the path between "complete rewrite" and "invent a proprietary intermediate language": doing what they did at the end (running a permanent transpilation and committing the result) at the beginning? They could have just moved from straight ASP to straight PHP, and then later done it again to move to straight C#. No rewrite necessary, no technical debt necessary.
- cwyers 11y ago
  Path dependency. At the time, PHP was not as easily deployed on Windows as ASP, and so the original design was set up to give them PHP on *ix and ASP on Windows.
karlmdavis 11y ago
I was 50/50 on whether or not he was just trying to defend poor decision-making with this post, up until this line: > It’s worth repeating that what’s generally overlooked is that each decision was made by the team and a variety of alternatives were considered. Moving forward with Wasabi .NET was only done after considering a lot of alternatives, including porting to python. That right there is the crucial point for me. I think the real danger (and concern) with these types of technical debt situations is that they're often forced on engineering by upline management (i.e. non-coders). But if the folks who will have to maintain any mess they create are the ones making these decisions, the decisions are likely the correct ones-- at least at that time.

118 points by GarethX 11y ago

well worth reading for the insight into behind the scenes at FogBugz - some depressingly clear headed and awkward discussions undoubtedly had. and one suspects another lesson - don't have your whole company dependant on one product. I still adhere to the idea that LOC is debt and LOTests is capital.

sopooneo 11y ago

FogCreek seems to be winning the game. So I agree with the sentiment that it was productive debt.

mkozlows 11y ago
Winning what game? I can't find solid numbers about bug-tracker marketshare, but if I type "FogBugz vs" into Google, it throws up Jira as the first result. If I type "Jira vs", FogBuz doesn't show up -- I get Rally, Trello, TFS, Redmine, and Asana first. FogBugz definitely used to have a lot of mindshare, but...
- sopooneo 11y ago
  You have a valid point. But just as an aside, you know who makes Trello, right?
  - timv 11y ago
    Yes, that would be Trello, Inc https://trello.com/about https://trello.com/about The fact that FC managed to come up with a successful (but not necessarily profitable) product idea and spin it off into its own company doesn't really say much about the validity of their decisions on a completely different product. Nor is it evidence of Fog Creek "winning the game" (whatever that might mean)
    - deleted 11y ago
      [deleted]
  - serve_yay 11y ago
    Yeah - Trello Inc. :)
  - snowwrestler 11y ago
    Was Trello written in Wasabi, though?
- rjbwork 11y ago
  Is there anything else like Kiln Harmony on the market? The ability for our developers to use Git or Hg (with a couple of caveats...) on any of our repositories is a great recruiting point.
  - chii 11y ago
    i really dont think anyone would base their choice on whether they used hg or git (or both, or either for that matter). It's a very small, and rather unimportant in the grand scheme of things.
- hesselink 11y ago
  Yes, this doesn't look like winning: https://www.google.com/trends/explore#q=fogbugz%2C%20atlassian%20jira&cmpt=q&tz=Etc%2FGMT-2 https://www.google.com/trends/explore#q=fogbugz%2C%20atlassi...
- snowwrestler 11y ago
  So maybe Fog Creek was correct to take whichever path cost the fewest resources. If it took fewer hours to write and maintain a small transpiler than to re-write the entire application, then that would help profit margins on a product that is not taking over the world anyway.

quanticle 11y ago

Looking back, maybe Fog Creek should have built itself a boat instead of walking up the beach. Except rule number one was never, ever rewrite code. That is the crux of the problem. Sometime requirements change enough that a total rewrite is the better and cheaper option. Having to support an entirely different operating system is certainly a change of that magnitude. Obviously, second guessing is easy and shipping is hard, but can anyone tell me coherently why Joel didn't push for a rewrite when he received the requirement to support Unix servers? My perceptions may be inaccurate here, but it seems like the reasonable thing to do when confronted with having to support Unix servers in addition to Windows is to rewrite the code in a cross platform way, and perhaps add shims to support the differences between platforms. I don't think I know anybody personally, whose response would be, "I know, let's write a compiler to translate our VBScript into something that runs on Unix." And in fact, lots of other successful companies (Twitter, Reddit to name two offhand) have successfully embarked on full rewrites, with much less justification than having to support a brand new OS. It seems to me that Joel was so committed to his "don't rewrite" principle that he was willing to take on a massive amount of technical debt to avoid comprimising on it. Which... well, it worked out well in this case, but I have a hard time seeing it as good general advice to follow when building software.

reymus 11y ago
Well, the task of writing the compiler was given to an intern, so I would guess it was an experiment that ended up working well enough that became their strategy for supporting Unix.
mwcampbell 11y ago
It seems to me, as an outsider, that Joel's reason for avoiding a rewrite at any cost is because so many rewrites have failed. Perhaps it's better to prefer steady, step-by-step progress over a giant leap that might be a leap backward in the end. What is often forgotten in these discussions is that, because Fog Creek had talented programmers, writing Thistle and eventually Wasabi was just another series of steps on the road, not a giant leap as a rewrite would be.
ams6110 11y ago
I don't think I know anybody personally, whose response would be, "I know, let's write a compiler to translate our VBScript into something that runs on Unix." Yeah it was an odd strategy, I agree. But on the other hand, translating one scripting language to another doesn't sound sound that unreasonable either. From the article: The super obvious answer is to tell unix customers to install Chilisoft ASP. Boom. Done. Except it costs more than FogBugz does. I remember hearing of Chilisoft ASP. Never used it, and I have no idea what it cost. I'd be curious if they attempted to negotiate any kind of discount for Chilisoft ASP, maybe locked to FogBugz somehow. Compared to running FogBugz on ASP, which I'm guessing would have required at minimum a Windows Server and a SQL Server license, you'd think some kind of deal could have been arranged. The other thing I'm curious about is how many Unix installations of FogBugz were sold? From what I've seen, customers who are willing to actually pay for a bug tracker would not blink about buying a Windows server to run it, if that's what it required.

ChuckMcM 11y ago

I really like the metaphor of walking up the coast because you're getting closer to London. So many projects are like that, some sort of fitness function that tells you that you are getting incrementally closer to your goal, but nothing to tell you that you are fundamentally ill equipped to actually make it to your goal, or even that your entire strategy which is "working" is fundamentally wrong.

cwyers 11y ago
They made it to London, though.

peteretep 11y ago

> A much hipper programmer might say something like “you > ain’t gonna need it.” This is a little bit like saying "a much hipper programmer might describe this approach as being 'AJAX'", a term that is at least 4 years older than YAGNI :-)

mmphosis 11y ago

Those who don’t learn from history are doomed to repeat it. Any day now, I suspect some fools are going to want to write web apps, but they won’t want to use raw javascript and they’ll create some ridiculous custom language to javascript compiler. I can only hope they have the good sense not to tell anybody about it.

hesselink 11y ago
We wrote a custom language, only it's javascript. We built a very simple module/class system that compiles to javascript, in javascript. It consists of functions called 'Module', 'Class', 'Static' and such, that generate javascript code. This has had so much value for us. It allowed us to abstract some patterns into 'compiler extensions' for things like scoping, timeouts and cancellation, etc. And more recently, it allowed us to add typechecking by outputting typescript instead of javascript. I think it was a great idea and would do it again, but it's only been 6 years, so perhaps ask me again in 4 years :)

derefr 11y ago

So, what about the path between "complete rewrite" and "invent a proprietary intermediate language": doing what they did at the end (running a permanent transpilation and committing the result) at the beginning? They could have just moved from straight ASP to straight PHP, and then later done it again to move to straight C#. No rewrite necessary, no technical debt necessary.

cwyers 11y ago
Path dependency. At the time, PHP was not as easily deployed on Windows as ASP, and so the original design was set up to give them PHP on *ix and ASP on Windows.

karlmdavis 11y ago

I was 50/50 on whether or not he was just trying to defend poor decision-making with this post, up until this line: > It’s worth repeating that what’s generally overlooked is that each decision was made by the team and a variety of alternatives were considered. Moving forward with Wasabi .NET was only done after considering a lot of alternatives, including porting to python. That right there is the crucial point for me. I think the real danger (and concern) with these types of technical debt situations is that they're often forced on engineering by upline management (i.e. non-coders). But if the folks who will have to maintain any mess they create are the ones making these decisions, the decisions are likely the correct ones-- at least at that time.