16 comments

[ 3.0 ms ] story [ 51.7 ms ] thread
"Where software goes to live" sounds tongue in cheek.
Seems like a retirement home for software.

Kind of like the Apache project.

I remember a guy at work calling Compuware the place that "Software goes to die", although I'm sure there are many other examples.
Hm, a bundle of maintenance mode software is a better fate than the usual "our incredible journey."
Some context:

FogBugz was acquired in 2018 by DevFactory, a different ESW-funded company.[0]

The new owners promised that FogBugz would be rewritten in under 5000 lines of code.[1] (For comparison, the Flash ActionScript code for the “evidence-based scheduling” feature’s UI alone was over 5000 LOC.)

Nathan Vardi, then at Forbes, called ESW a “global software sweat shop”. Not really relevant to FogBugz, but maybe it explains some of what’s behind this IP transfer [2]

DevFactory announced the alpha of Cloud Native FogBugz in 2021 [3]

Now, in this article, IgniteTech is promising:

> 1) to save and stabilize the software and business[… and] 2) to continuously innovate and transition products to the AWS cloud

implying, to me, that the DevFactory “cloud native” version was a total failure, and that the old creaky legacy .NET version they acquired is too expensive for DevFactory to be able to run, and also somehow not yet fully transitioned to AWS?! (I had heard that they decommissioned the physical colo datacenter by 2019, so I’m not sure where FogBugz is actually running now.)

[0] https://www.prnewswire.com/news-releases/devfactory-acquires...

[1] https://twitter.com/FogBugzTeam/status/1098287969700433920

[2] https://www.forbes.com/sites/nathanvardi/2018/11/19/how-a-my...

[3] https://blog.fogbugz.com/fogbugz-the-road-ahead

For all of Joel Spolsky sounding smart in essays on the internet (hey, I like them, too), I've heard that FogBugz was / is not a very good product, actually. Does anyone have additional information about the product?
I don’t, but the early blogging definitely could skew our perception. Nowadays I’d take everything with a grain of salt, including his blog. I believe I tried to use FogBugz back then but iirc the price was absolutely prohibitive at that moment.
We're currently used it, I'm also the OP.

The product sucks, I've been using it for about ~18 months and it's been stale and close to abandoneware for longer than that.

For me it's too little too late, we're moving else where.

Sorry, LB.

18 months is about half as long as it has been owned by private equity, and unfortunately the product was being under-invested in when I was last working on it 3 years ago.

It’s sad to see it languish, since I and many of my friends spent so long working on it.

Always hurts to see something you were once proud and happy to be working on languish away and deteriorate, you've my condolences too friend.
Dunno but Spolsky wrote there was some developer velocity metric in some blog post about estimations he was really proud of. So I guess it some proto-Jira with Scrum madness.
Most likely this - https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

The approach sounds lovely on paper, in practice most software development environments range from absolutely terrible to terrible - that level of organisation isn't something I can see more teams doing even if the tool does help.

Oh ye that one. I remember reading that and thinking to my self "that can't possibly work" - years before I was exposed to Agile for the first time learning first hand how silly upfront no-research estimations are.

What I learned is that people pad and fudge numbers to make the burndown chart nice, which might be what Spolsky's employees did in the end to please his try to make an estimation tool.

Also, breaking down task in my experience counterintuitively makes them harder to estimate. I.e. summing many small estimates over doing one big for the set of subtasks.

For summer vacation, I’ve been reading some histories of modern computing (electronic, digital, programmable). One of the ENIAC’s first tasks was to run Monte Carlo simulations to help design the H bomb. The first Cray jobs also used Monte Carlo simulation for weather modeling (important Cold War knowledge; you need to know where your fallout is likely to spread) and weapons design.

This technique is also how Evidence-Based Scheduling works.

I led the engineering team for FogBugz and Kiln at Fog Creek from 2017-2018, and worked there for almost a decade prior.

Joel Spolsky hasn’t been involved in FogBugz at all since 2018, when it was acquired by DevFactory. Forbes calls their parent company a “software sweatshop.” None of the engineers at Fog Creek even bothered to interview to stay on after the knowledge transfer, if that gives you an idea of the corporate culture difference.

Before the acquisition, Joel gave Anil Dash the CEO role in 2016. Jordan Harris (COO) and Rich Armstrong (GM) led FogBugz/Kiln operations before then.

And even before that, it was fairly clear (at least to us employees) that Joel was more focused on his other companies: Stack Overflow, Trello, Glitch.

Trello spinning off into its own company in 2014 was a huge relief for Creekers, because we felt like we could finally focus on our own company again.

We were operating with a small, self-funded, crew, which made it very hard to compete with Jira and GitHub. With hindsight, I can say we bit off 1000% of what we could chew. Kiln was a maintenance nightmare, yet didn’t provide a quarter of the revenue FogBugz alone did. The FogBugz Plug-in API was a plain mistake (Second System Syndrome plus running user code in-app?!?). FogBugz’ database tenancy model was always a pain. ElasticSearch was fantastic for speed, but maintainability wasn’t great. We had a real bad case of The Lava Layer Anti-Pattern. Oh, and we were about infinity years late to the cloud: on my very last day, we were still on seven racks of hardware in a DC in the most expensive real estate in the country.

I would say the last “Joel” version of FogBugz was 7.0, announced July 20, 2009. Lots of customer excitement with that release.