Anthropic / Claude just handed Quicken a lifeline and massive business opportunity, at low cost.

I wonder how many people have worked on such old code?

And how many have used AI to refactor code, especially such old code?

And I also wonder which have done work in a company environment where there is little incentive to change core code because of the cost?

If the discussion was simply "Can you add in AI to do better queries/reports" I think that might be a possibility, but if the goal is to rewrite Quicken people are way underestimating both the complexity of the problem and way overestimating what AI can currently do without introducing more problems than it solves.

For my part, I maintain some code that was written more than 40 years ago. And I would bet that code is much easier to maintain than Quicken's for no other reason than it was created and maintained in the past by a small, very experienced group of software engineers, that stayed with the projects for most of the life of the active development of those projects. I doubt that Quicken development had either of those luxuries.

And I have been using AI for to help in some coding recently and I can tell you that you have to specify what you want exactly and it can still make mistakes not to mention depending on how you prompt it, it might not be optimal code. And as for giving it the full Quicken code base unless you have the resources of a Google, I don't think you understand what you are asking it to do. You can neither give prompt like "Make this code modern" or expect it to scan all of a large code base and expect it to understand all the details of the code. What's more it has a very "limited memory" of past actions. It has to "rescan" code that it created just a day ago to make more changes that you ask for. And it can neither do such a task as you are asking for in one go, no more than you can describe what you want in one prompt.

@Rocket J Squirrel mentioned that there must be some old C code that there that no one wants to touch.

I will go further than that and say that just because some code might be C++ that doesn't instantly make it more maintainable. In fact, the code I maintain that is more than 40 years old is pure C, and they choose to do that on purpose for future compatibility. As in, the goal wasn't to always "look modern" the goal was that the code would continue to run and run correctly. And they did achieve that.

As for the Quicken code, there is some pretty solid evidence of such old code. By all indications Quicken is using the same database engine as it used when it first was ported to Windows. One might think by that statement that is the reason for performance problems, but I personally doubt that. I have not seen any indications that the database itself is the bottleneck. All my observations point more to the GUI and infrastructure, as in the networking and refreshing code and such.

Past the database one doesn't have to look very far to see old code. How about the Tax Planner, Lifetime Planner, and Business forms. Notice that its HTML and dates to somewhere around 1996.

But there is even older code staring you in the face. The "register code", both the investment and the non-investment "registers". Of the two I think the non-investment register code is older (I'm talking the base functionality here), but for sure the "investment register code" (which to this day is actually called "investment lists) is clearly much more of a problem. I believe that is due to its history. If you go back far enough you will see that it was truly "security lists", as in you couldn't edit like a register. It is clear to me that it really suffered when they cobbled together the current investment "register" code. And @Rocket J Squirrel this absolutely some code that no one wants to touch. The proof of that is how they implemented "Move/Edit Transactions".

Clearly if you had a decent table/register the way you would implement selecting the transactions to move/edit would be the standard Windows selection methods just like you do in the non-investment registers and in reports. But instead, they created menu items that popup a completely different list that you do this selection from. That is certainly an indication that the current investment code isn't something they want to try to change.

One of the things people don't really get is that "soft"ware can be as ridged as the foundation of a building. Many times you can't just go in and change the foundations of a given program because it affects too many things, and to make that kind of change might take time that you don't have, not to mention introducing bugs and other problems.

BTW when people think that the database is the source of the performance problems (I don't) they usually say something like "Well then just replace it with a modern database". This one goes with "These days it is easy to write code that runs on all of the operating systems, they should do that."

First off, back then and even for non-highly structured programs today writing a program that cleanly separates the database from the rest of the program is hard and wasn't the practice back then. I really doubt the Quicken developers could cleanly change it out without causing all kinds of problems all over Quicken.

And I'm sure there are other core parts of Quicken just like this.

And I can tell you that depending on what resources are needed for the program, writing a program that runs on say Windows, Mac, Android, and iOS can be extremely difficult, let alone trying to do it do an existing program what has been around as long as Quicken has.

And here is one more thing I would point out about "modern", it isn't necessarily better.

Who among you believes that all the new "tables" are better than the old ones? I'm not talking about the "appearance", that is a matter of personal taste. I'm talking about having tables like the non-investment registers in comparison to the budget ones where in the register you can set the column sizes, but in the budget you can't. The basic functionality not the appearance.

And speaking of those two, do people realize that the register is definitely very old code, and the budget would represent the "modern" for Quicken (remember that budget was totally rewritten in 2012 {and in 2013 it was major reworked because of all the complaints)?

One might be fooled by the fact that the registers look "modern". What people don't realize is the overtime Microsoft has changed the appearance of the old GUI APIs to try to track with the current standards.

Here is peek at the register GUI code:

For all the non-programmers out there, these are customized/sub classed MFC GUI objects. Yes, the same GUI objects that @jtemplin mentioned that came out in 1992. And the fact they sub classed them to add their own extra functionality makes them even harder to replace.

I don't think Quicken Inc has anything to fear from another company using AI to make a program that will replace Quicken on the Desktop. I'm pretty sure they already know exactly where the "threat" is, and that is online programs. And they are clearly working towards that.

Quicken isn't memory restricted, it doesn't even use all the memory available to a 32-bit program.

And your comparison isn't applicable to Quicken's situation.

As for AI it can help but it isn't going to change a decades, long project into a few months project.

Well, you good folks here on this thread are certainly more up to date than I on this "Anthropic Claude" fellow than I am (which ain't saying much). Wouldn't it be wiser though if Quicken code masters might sit and ponder awhile 🤔 before allowing Anthropic Claude run willy-nilly over current Quicken code? Why not try something that's been around awhile, like "Anthropic Gertrude & Heathcliff". Red Skelton invented that years ago 😉