3 ms·

> My customers don't want "early and continuous delivery". I hate App Store apps that release new versions every week with cutesy uninformative release notes li

> My customers don't want "early and continuous delivery". I hate App Store apps that release new versions every week with cutesy uninformative release notes like "We've improved the software for you". That's bullshit. And users don't want "early" half-baked buggy crapware; they want their software to Just Work™. Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack. For large dev houses those service packs were complicated and hard to ship, because their entire organizational structure was based around big bang releases. Competitor comes out with a killer feature? Well users of your software weren't going to get it for literally years, during which time a fair number of them might very well defect to the competitor's software. And a lot of software you use gets updated all the time, you just don't notice. Performance bugs get fixed, memory leaks patched, and UI quirks, that you may not have run into, are removed.

palata 3y ago
> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. Did you experience that, or did you read it in one of your Agile bibles? Genuinely interested.
- com2kid 3y ago
  I worked at Microsoft. Windows releases, Office releases, Visual Studio releases. I started my career in the mobile (originally Windows CE) compiler team. Releases were a big deal, support contracted lasted seemingly forever. (Ironically, internally the mobile compiler team was actually very agile, with weekly full test passes happening, the compiler always being in a shippable state, and development occurring in what would now be considered modern practices.) Microsoft was getting destroyed because they were very non-agile. As soon as the iPhone came out, Apple started releasing a new OS every year, and back then OS updates had significant developer API improvements. Windows Phone couldn't complete with that. I remember how lacking the camera API was soon as instagram types apps with filters came along, Windows Phone went from amazing to instantly behind the curve. Look at what happened to Hotmail when GMail came out, it took Microsoft years to catch up just with the storage space increases, UI improvements took even longer. Microsoft ended up losing their top spot in the webmail game. Internet Explorer (eventually Edge) was tied to OS releases. Even when MS started to invest in their browser again, being tied to OS releases meant it could never complete with Chrome releases happening every few months. Edge would have a big release, pull ahead on benchmarks, then 6 months later be out of date and behind the curve again. Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later". That forcing function alone is a huge improvement.
  - palata 3y ago
    > Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later". Is it Agile, though, or is it Internet? Because having the possibility to send regular updates over the Internet seems to have permitted to ship buggy software quickly, and pretend that it will be improved later. That's faster, but I feel like software is lower quality today than it was years ago.
lapcat 3y ago
> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack. This is all nonsense.
goalieca 3y ago
> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack It still would if you had to go print CDs. The internet changed all that of course. Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions.
- palata 3y ago
  > Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions. Which allows us to ship bad software and hope that we will fix it later (spoiler: we never really do, it usually stays pretty bad).

palata 3y ago

> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. Did you experience that, or did you read it in one of your Agile bibles? Genuinely interested.

com2kid 3y ago
I worked at Microsoft. Windows releases, Office releases, Visual Studio releases. I started my career in the mobile (originally Windows CE) compiler team. Releases were a big deal, support contracted lasted seemingly forever. (Ironically, internally the mobile compiler team was actually very agile, with weekly full test passes happening, the compiler always being in a shippable state, and development occurring in what would now be considered modern practices.) Microsoft was getting destroyed because they were very non-agile. As soon as the iPhone came out, Apple started releasing a new OS every year, and back then OS updates had significant developer API improvements. Windows Phone couldn't complete with that. I remember how lacking the camera API was soon as instagram types apps with filters came along, Windows Phone went from amazing to instantly behind the curve. Look at what happened to Hotmail when GMail came out, it took Microsoft years to catch up just with the storage space increases, UI improvements took even longer. Microsoft ended up losing their top spot in the webmail game. Internet Explorer (eventually Edge) was tied to OS releases. Even when MS started to invest in their browser again, being tied to OS releases meant it could never complete with Chrome releases happening every few months. Edge would have a big release, pull ahead on benchmarks, then 6 months later be out of date and behind the curve again. Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later". That forcing function alone is a huge improvement.
- palata 3y ago
  > Agile forces code to always be in a shippable state, which is a good thing. It doesn't let code become bug ridden and then say "we'll fix it sometime later". Is it Agile, though, or is it Internet? Because having the possibility to send regular updates over the Internet seems to have permitted to ship buggy software quickly, and pretend that it will be improved later. That's faster, but I feel like software is lower quality today than it was years ago.

lapcat 3y ago

goalieca 3y ago

> Prior to Agile delivery, updates came once every 3 or 4 years and software languished in-between releases. If software shipped with a bug, that bug stayed around for a long time, unless it was lucky enough to get fixed in a service pack It still would if you had to go print CDs. The internet changed all that of course. Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions.

palata 3y ago
> Now we have a business model based on continuous sales (like app stores instead of big launches) and subscriptions. Which allows us to ship bad software and hope that we will fix it later (spoiler: we never really do, it usually stays pretty bad).