
Technical debt and tacking into the wind - GarethX
http://www.tedunangst.com/flak/post/technical-debt-and-tacking-into-the-wind
======
quanticle
_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.

~~~
tptacek
Isn't the story of Wasabi that changing OS's and dev platforms is manifestly
_not_ a good reason for a rewrite?

People seem to be mistaking the big story about Wasabi today. Wasabi _worked_.
Yes, they're migrating away from it --- ten years after introducing it. They
defered to 2015 what people on HN are telling them they should have done in
2005.

Not only that, but the "port" to C# was _mechanical_. They _didn 't_ rewrite
to get away from Wasabi. Because they put the time in to build Wasabi, all
their code was instrumented, and they were able to _write a program_ to do the
final port. They deferred the port for a decade, and also mechanized it.

I can't help but think you've taken exactly the opposite message away from the
posts today that the authors intended.

~~~
blub
There's nothing new here, a company can have a crap tech stack and still build
a successful product if it has a competent team and good leadership.

This was I imagine a bit of a PR problem for FogCreek, because at the end of
the day they were using Visual Basic to build a Windows-only website, not
exactly the most awesome stack in today's world (or yesterday's for that
matter).

It's normal that they want to communicate to the world the fact that you won't
have to learn their custom version of Visual Basic in order to work there.
It's also normal that people aren't giving them a pass that easily.

~~~
tptacek
I think you may have commented on the wrong thread. I can't see what your
comment has to do with mine.

------
ChuckMcM
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
They made it to London, though.

------
mmphosis
_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
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 :)

------
karlmdavis
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.

------
lifeisstillgood
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.

------
derefr
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
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.

------
peteretep

        > 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
:-)

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

~~~
mkozlows
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
You have a valid point. But just as an aside, you know who makes Trello,
right?

~~~
timv
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)

