5 ms·

While a fun read Joel on Software always seemed like a what-not-to-do blog to me. The complexity for the sake of complexity! No, you don't need to write your

While a fun read Joel on Software always seemed like a what-not-to-do blog to me. The complexity for the sake of complexity! No, you don't need to write your own programming language and compiler to deploy a webapp across multiple platforms. No, you don't. Whatever the problem is. Yes, I understand it's complex but really, you don't. (Even in 2006 when you couldn't just stuff your whole support stack into a container.) Trust me.

krallja 5y ago
How would you deploy an ASP web application to Linux hosts in 2005? Linux and Mac made up a small but meaningful portion of our revenue for over a decade. Would you have foregone that, all because you didn’t want to write a compiler? It took one intern three months to do the first version of Thistle.
- Thetawaves 5y ago
  You could have chosen any of the cross platform frameworks of the day? PHP or Python would have been an easy choice at the time.
  - krallja 5y ago
    In 2006, the app was already seven years old. We couldn’t go back in time and decide to write it in a different language.
    - Lascaille 5y ago
      Could have just shipped the customer a server, especially as Joel's article suggests that most of your on-prem customers went with dedicated servers for the software anyway. Find it hard to imagine that a significant percentage of your customers were 100% linux/mac to the extent that they'd refuse any win boxes in their shop. I was in IT at the time and catered to a number of 100% mac shops (mostly ad agencies/gfx design studios) and there were always one or two win boxes around, usually a couple for fileserver/backup and one for the sysadmin to do sysadmin things with. >We couldn’t go back in time and decide to write it in a different language. You had an intern write a program that rewrote it in a different language for you, time after time after time. You could have just rewritten it once :)
      - krallja 5y ago
        We didn’t have the margins to ship physical servers to customers. User seat licenses were $100 or so, and most customers were SMBs - 5-15 users, so we would have lost money on shipping any customer a Dell with Windows Server on it. We didn’t have a sales channel for real enterprise customers until quite late in the lifecycle of the product, so even our biggest customers weren’t that big. Joel said PHP and Python were non-starters on Windows. We could have used the compiler to do a one-time cutover to C# in 2008, but the CodeDom generated code was fairly icky, so we decided to keep the Wasabi code and just ship the machine-generated DLLs with friendly Wasabi debugging symbols. We were only able to cut over once I rewrote the generator (I think that was the fifth generator, and there was also a Wasabi interpreter for compile-time evaluation… PHP, JS, ASP, .NET DLL via CodeDom, plain C#) using Roslyn. That took me just over a month, in two phases: first, use Roslyn to generate duplicate code to the CodeDom backend (2-3 weeks). Then, I deleted the CodeDom backend and started making syntactic improvements (and generate comments and white space!) until I hit the point of diminishing returns (1-2 weeks). Finally we checked in the C# source code, removed the Wasabi build step, and let ReSharper go to town. (2 days) Each step we took was low-risk, because it didn’t create any new technical debt or accumulate as inventory. Each step was small and low-cost. None of them were the optimal step, but they also didn’t risk the entire business on stopping-the-world. There were plenty of other disasters in that codebase. For me, the FogBugz Plug-in Architecture was the worst of all of them. Adding all those layers of indirection, plugin hooks was a huge performance cost, and maintenance burden because we couldn’t ever change function signatures once they were shipped. I wish we had just added web hooks. That would have gotten us 95% of the extensibility with 10% of the performance cost, and 0% hosting other peoples’ code in our FogBugz On Demand web server processes. I think I once murdered a fledgling startup by mentioning we were thinking of removing it.
        Lascaille 5y ago
        Thanks for the context, I appreciate it. At the time I remember the concept of running PHP on Windows/IIS did have this air of 'hmmmmmmmmmmmno' associated with it. In my experience it ran fine, but for obvious reasons when shipping software that might make or break their company I can understand Joel preferring the familiar territories of ASP/IIS/Win or LAMP.
- deleted 5y ago
  [deleted]
reginaldo 5y ago
"What I cannot create, I do not understand", as Feynman said. I for one defend people's right to do unusual things. You do not need to write your programming language, but when you do that, you end up with something that changes you, even if the idea of writing your programming language was stupid in hindsight, perhaps especially if the idea of doing whatever you did was stupid in hindsight. Two thoughts for you to ponder: exercising will is doing precisely what you don't need to do. Also, I feel that programming is a lot like writing. When you read something as a reader, you just read it, but when you read it as a writer, you're thinking about what makes the text flow, or "tick", and the ultimate test of that is whether you can write a similar thing yourself, or perhaps a slight variation.

krallja 5y ago

How would you deploy an ASP web application to Linux hosts in 2005? Linux and Mac made up a small but meaningful portion of our revenue for over a decade. Would you have foregone that, all because you didn’t want to write a compiler? It took one intern three months to do the first version of Thistle.

Thetawaves 5y ago
You could have chosen any of the cross platform frameworks of the day? PHP or Python would have been an easy choice at the time.
- krallja 5y ago
  In 2006, the app was already seven years old. We couldn’t go back in time and decide to write it in a different language.
  - Lascaille 5y ago
    Could have just shipped the customer a server, especially as Joel's article suggests that most of your on-prem customers went with dedicated servers for the software anyway. Find it hard to imagine that a significant percentage of your customers were 100% linux/mac to the extent that they'd refuse any win boxes in their shop. I was in IT at the time and catered to a number of 100% mac shops (mostly ad agencies/gfx design studios) and there were always one or two win boxes around, usually a couple for fileserver/backup and one for the sysadmin to do sysadmin things with. >We couldn’t go back in time and decide to write it in a different language. You had an intern write a program that rewrote it in a different language for you, time after time after time. You could have just rewritten it once :)
    - krallja 5y ago
      We didn’t have the margins to ship physical servers to customers. User seat licenses were $100 or so, and most customers were SMBs - 5-15 users, so we would have lost money on shipping any customer a Dell with Windows Server on it. We didn’t have a sales channel for real enterprise customers until quite late in the lifecycle of the product, so even our biggest customers weren’t that big. Joel said PHP and Python were non-starters on Windows. We could have used the compiler to do a one-time cutover to C# in 2008, but the CodeDom generated code was fairly icky, so we decided to keep the Wasabi code and just ship the machine-generated DLLs with friendly Wasabi debugging symbols. We were only able to cut over once I rewrote the generator (I think that was the fifth generator, and there was also a Wasabi interpreter for compile-time evaluation… PHP, JS, ASP, .NET DLL via CodeDom, plain C#) using Roslyn. That took me just over a month, in two phases: first, use Roslyn to generate duplicate code to the CodeDom backend (2-3 weeks). Then, I deleted the CodeDom backend and started making syntactic improvements (and generate comments and white space!) until I hit the point of diminishing returns (1-2 weeks). Finally we checked in the C# source code, removed the Wasabi build step, and let ReSharper go to town. (2 days) Each step we took was low-risk, because it didn’t create any new technical debt or accumulate as inventory. Each step was small and low-cost. None of them were the optimal step, but they also didn’t risk the entire business on stopping-the-world. There were plenty of other disasters in that codebase. For me, the FogBugz Plug-in Architecture was the worst of all of them. Adding all those layers of indirection, plugin hooks was a huge performance cost, and maintenance burden because we couldn’t ever change function signatures once they were shipped. I wish we had just added web hooks. That would have gotten us 95% of the extensibility with 10% of the performance cost, and 0% hosting other peoples’ code in our FogBugz On Demand web server processes. I think I once murdered a fledgling startup by mentioning we were thinking of removing it.
      - Lascaille 5y ago
        Thanks for the context, I appreciate it. At the time I remember the concept of running PHP on Windows/IIS did have this air of 'hmmmmmmmmmmmno' associated with it. In my experience it ran fine, but for obvious reasons when shipping software that might make or break their company I can understand Joel preferring the familiar territories of ASP/IIS/Win or LAMP.
deleted 5y ago
[deleted]

reginaldo 5y ago

"What I cannot create, I do not understand", as Feynman said. I for one defend people's right to do unusual things. You do not need to write your programming language, but when you do that, you end up with something that changes you, even if the idea of writing your programming language was stupid in hindsight, perhaps especially if the idea of doing whatever you did was stupid in hindsight. Two thoughts for you to ponder: exercising will is doing precisely what you don't need to do. Also, I feel that programming is a lot like writing. When you read something as a reader, you just read it, but when you read it as a writer, you're thinking about what makes the text flow, or "tick", and the ultimate test of that is whether you can write a similar thing yourself, or perhaps a slight variation.