3 ms·
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. Do
by ahartmetz 4y ago
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?
- wruza 4y agoI 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.
- LilBytes 4y agoWe'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.
- krallja 4y agoSorry, 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.
- LilBytes 4y agoAlways hurts to see something you were once proud and happy to be working on languish away and deteriorate, you've my condolences too friend.
- throwawaymanbot 4y ago
- rightbyte 4y agoDunno 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.
- noir_lord 4y agoMost likely this - https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ 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.
- rightbyte 4y agoOh 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.
- krallja 4y agoFor 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.
- krallja 4y agoI 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.