XP was developed in the Chrysler Comprehensive Compensation project. The project began in 01993 and brought in Kent Beck to reboot it in 01996, at which point they still hadn't gone live; they went live in 01997 and continued work on the project until 02000. Frequent releases are one of the cornerstones of XP — every 2 weeks, I think, on C3. You can read about it in https://martinfowler.com/bliki/C3.html and https://wiki.c2.com/?ChryslerComprehensiveCompensation.

ESR wrote http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral... in 01997, but Jim McCarthy said "Release Early, Release Often" in his 01995 software-process book https://www.amazon.com/dp/1556158238 (which I haven't read) according to https://devops.stackexchange.com/a/80.

Releasing often isn't always a good idea, but it isn't necessary for every user to upgrade to every release. Here are some advantages of releasing every iteration (once or twice a month):

1. You can never have the software in an uncompilable or unshippable state for an entire iteration, much less three months at a time, so the only time you don't know how long a showstopper bug will take to fix is immediately after you find it, and you're never "integrating, don't know how long this will take," because frequent releases force continuous integration. You never slip a ship date, at least not by more than a week or so; you just cut scope. Slipping can be enormously painful and sometimes fatal to a business.

2. A hacker costs a business US$200k a year. A team of ten hackers costs US$38000 per week. If you release once a quarter, then, on average, at any given moment, you have six weeks of work that you've paid for that haven't reached users and are thus not yet producing any value; that's about a quarter of a million dollars of "inventory"—having a lot of inventory might sound great if you're a survivalist or an RPG player, but for a business, "inventory" is wasted money. If you can cut that to monthly, you only average two weeks of inventory, so you've saved US$170k, almost the cost of a person-year of work.

3. When you ship software to users, they react, which is an opportunity to learn from them about what they value and what they don't; this both gives you ideas for new features and gives you more information about the value of features you'd already thought of. This is true even if only some of your users install the new release. If you ship once a quarter, you get four of these round trips per year; if you ship once a month, you get twelve. So you can learn a lot more from your users. Evidently that wasn't enough to get Skype on track.

4. If you're a business, the business environment changes as you're developing software: for example, your competitors add new features, systems you interoperate with change their behavior in ways that break your software, and new libraries become available. To remain profitable and in particular to remain better than the competition, you must observe these changes, orient yourself with respect to them, decide what to do, and then act. In competitive environments, the competitor who can go through this "OODA" loop faster will almost invariably win. Shipping features that embody the right decisions for this month instead of the right decisions for three months ago can be a decisive advantage—though I think this is what WhatsApp was better at.

5. When your sales guy meets with a potential client on October 10 and finds out about a missing feature that's a showstopper for that client, and the October 28 release now has that feature, it gives you totally different chances of closing the deal than if the January 10 release has the feature. Even if they don't buy then, you've made a totally different impression, and you're more likely to make a sale later or get a lead on another potential client from them.

6. More generally, frequent releases make progress and quality legible to people outside the programming team, circumventing the "thermocline of truth" problem named in https://brucefwebster.com/2008/04/15/the-wetware-crisis-the-.... Having five features "80% done" after four months could mean you'll deliver them in another month, or that you'll deliver them in another 8 months. By contrast, the difference between delivering four of those features in four monthly releases, and delivering one of them, is a difference observable to users, management, sales, and customers. Sometime it's even helpful for keeping the people inside the development team from fooling themselves, despite being below the thermocline of truth.

I'm writing this based on the experience of utterly smashing two established competitors at AirWave, where upgrading one of our clients always involved a field engineer, often doing a site visit. We weren't writing open-source software, either.

I strongly agree with the above 2 comments.

You are describing what a manager is supposed to do. And you don't give enough details to diagnose the situation. I've seen coworkers who seriously had ADD (and were on enough prescription meds that their pill jar looked like a bowl of skittles), and I've seen coworkers who've had problems at home.

The guy with ADD couldn't see the 10000 ft view if you hit him on the head with it because ... ooh, look, shiny! He had to be micromanaged because his own steering mechanism was faulty.

May I recommend that you read Dynamics of Software Development? Because it sounds a lot like you want to flip the bozo bit over there. http://www.amazon.com/Dynamics-Software-Development-Jim-McCa...