How Intuit Manages 10 Million Lines of Code

CowboyRobot writes "Intuit launched QuickBooks in 1992, and it has grown into the best-selling retail software for small-business accounting worldwide. QuickBooks is available on multiple platforms with different feature sets (Pro, Premier, Enterprise), in specialized editions (accounting, contracting, etc.), is available on CD or via subscription, and is offered in localized versions for the U.S., Canada, and the U.K. How they manage so many builds is a case-study for large scale programming. 'The Windows version is about 80,000 source files, 10+ million lines of C++ code plus a little C# for the .NET parts. Plus help files, tax tables, files defining local accounting rules, tax and other government reporting forms, upgrade offers — a lot of files. Every customer gets the full version. Specific feature sets are turned on and off with the license key.' And the lessons are not just technical. 'One surprising lesson is that small teams work, even for very large codebases — especially, Burt says, in sustaining an entrepreneurial, creative culture.'"

Comments

-2000 Lines Of Code

[Osgeld]

n early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.

Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.

He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.

He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.

I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.

http://folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt

point is, just cause you can manage it, doesnt mean 10,000,000 lines of code is really something to brag about, especially for something that feels as cheap as quickbooks (though it does a ok job if your accountant cant use excel and must have things that visually represent checks)

Re:-2000 Lines Of Code

[Lev13than]

point is, just cause you can manage it, doesnt mean 10,000,000 lines of code is really something to brag about, especially for something that feels as cheap as quickbooks (though it does a ok job if your accountant cant use excel and must have things that visually represent checks)

If your accountant is using Excel to run your books that means it's time to get a new accountant.

Re:-2000 Lines Of Code

[Osgeld]

excel is a tool not a solution

quickbooks is more of a solution, but like the the 150 piece toolkit for 19.95 at harbor freight, it may do the job just fine, it may snap under the load

Re:-2000 Lines Of Code

[AuMatar]

I joke that in my last job I fixed two bugs on my first day without writing a single line of code. One bug required me to add a line, one required me to remove a line. Net LOC of 0. And a completely useless measure for my day.

Re:-2000 Lines Of Code

[Sir_Sri]

doesnt mean 10,000,000 lines of code is really something to brag about

No, but managing 10 million lines of code successfully is something to brag about.

However it got there, it's there now, and trying to figure out what to do with it, in a way that gets customers their product, teams their appropriate access, doesn't break every time a new intern looks at it, and can track changes back to individual employees so you can evaluate them somehow.

I'm not saying this isn't a problem other people haven't solved - certainly they have, but different solutions may offer some pieces of unique insights.

Re:-2000 Lines Of Code

[sapgau]

point is, just cause you can manage it, doesnt mean 10,000,000 lines of code is really something to brag about, especially for something that feels as cheap as quickbooks (though it does a ok job if your accountant cant use excel and must have things that visually represent checks)

I don't think this is your typical criticism for bloat. Just managing an annual mountain of tax laws and applying them correctly would easily go over thousands of lines. Fine lets use Excel to do that, what is the limit for tabs in a workbook? I bet VB will be a tiny bit slower calculating your tax refund and lets hope it doesn't blow the stack.

Re:-2000 Lines Of Code

[Anonymous Coward]

No, but managing 10 million lines of code successfully is something to brag about.

Depends on what you mean by managing. If by managing you mean keeping it a stable, problem free, high quality piece of software while extending it and keeping it up to date, then I agree. But demands vary. I could "manage" the 400000 LOC of the space shuttle flight guidance system just fine, because the space shuttle's retired.

Most SMB software of Intuit's age is in quality decline, however, because the SMB software market does not reward good software engineering practices. Large businesses, which pretty universally have custom written management software, do care slightly more because the eventual cost will catch up with them. Of course, they discount future costs compared to present profits, so there's a lot of bad code there as well, but not half as much as in COTS small and medium business software. There the cost of bad software is well hidden and eventually distributed over many, many companies.

Re:-2000 Lines Of Code

[Anonymous Coward]

If the form asks how many lines he wrote, why is he including lines he deleted?

Do you "write" deleted lines? No.. then stop being a smart ass and put what you wrote on the form.

Re:-2000 Lines Of Code

[cheesybagel]

Since they have US, Canadian and UK versions of the software I doubt the tax rules are hardcoded.

Re:-2000 Lines Of Code

[spiffmastercow]

Since they have US, Canadian and UK versions of the software I doubt the tax rules are hardcoded.

Define 'hard coded'. It would be really difficult to implement that logic through settings, and I seriously doubt they're using any sort of scripting or plugin system.

Re:-2000 Lines Of Code

[macs4all]

If the form asks how many lines he wrote, why is he including lines he deleted?

Do you "write" deleted lines? No.. then stop being a smart ass and put what you wrote on the form.

You must be a real joy at parties.

He was trying to make a point. And a good one at that.

And I dare say Bill Atkinson can program circles around most anyone you could name. His 68k assembler code in the Macintosh Toolbox was the very model of efficiency.

So yes. Yes you DO put deleted lines in that form, as they were "altered" in the process of development, you pedantic dullard.

Re:-2000 Lines Of Code

[JDG1980]

I don't think this is your typical criticism for bloat. Just managing an annual mountain of tax laws and applying them correctly would easily go over thousands of lines.

Shouldn't business logic be separate from code? Why can't these rules be kept in databases rather than hard-coded?

Re:-2000 Lines Of Code

[louzer]

Just because you can find a needle in a haystack does not mean we should start storing needles in haystacks.

Re:-2000 Lines Of Code

[Bert64]

Even worse, bad code can lead to more paid support incidents... If the code is bug free, they will make a lot less from their support offerings.

Re:-2000 Lines Of Code

[pinkushun]

Thanks for that little gem of folklore! Adding that to my library next to "The story of Mel" :-)

I spent a few years writing integration systems between QB and in-house software. I gave it the benefit of the doubt at first. I won't ever get those years back.

After aeons of debugging against their "API", and "UI", battling with their licensing and development "support" dept's, submitting bug reports (resulting in delaying their releases), I have concluded: Their code base is rubbish. It's flaky at best, likely contains yarns of spaghetti and unused cruft, is highly flammable and is likely to cause hemorrhaging if swallowed.

Re:-2000 Lines Of Code

[ciderbrew]

because tax laws are mental and getting a database to do that would drive it insane. I had to spec out a tiny bit of function with an accountant and the amount of exceptions to the rule made it pointless to have a rule.

Re:-2000 Lines Of Code

[davidbrit2]

Yeah, he's just wasting your money if he's using anything fancier than 1-2-3 Release 2.4.

Re:-2000 Lines Of Code

[slartibartfastatp]

For instance of a "hardcoded" rule, thinking of web software, I would mention evaluating taxes in the middle of your controller like this

... if ( $country=='usa' ) $taxes = $total * 0.17; elseif ( $country == 'uk' ) $taxes = $total * 0.15 + 0.1; ...

Tax evaluation is probably something that is going to be used in several places in a software, so the example above ensures doom in the future.

The non-hardcoding solution here, as I see, is something like

$TaxFactory = new TaxFactory( $country ); $taxes = $TaxFactory->evaluate( $total, ... );

Re:-2000 Lines Of Code

[zippthorne]

Although, for something with the scope of Quicken, a scripting or plugin system would actually not be a bad idea for the tax logic. It's not intended to do the taxes for a large corporation, is it? It's supposed to be used by individuals with perhaps hundreds of transactions in a year, running on machines that are idle at lest 90% of the year.

With a signed plugin system, they could support changes to tax law without having to upgrade the entire program annually, and with a scripting system, savvy users could do those updates without having to buy the patches, even.

Re:-2000 Lines Of Code

[zippthorne]

The "business logic" is code...

Re:-2000 Lines Of Code

[Anonymous Coward]

Prolog to the rescue?

Re:-2000 Lines Of Code

[RabidReindeer]

I worked in a shop like that once. Worst job I ever had. Like Bill, I strive to produce tighter, cleaner code rather than sheer bulk product. Only good thing about the whole deal was that I ended up seeing real numbers that demonstrated what amount of time and effort goals were expected to require versus how much time, effort (and lines-of-code) they actually required and that it was pretty consistent no matter who the developer was.

I'm not really impressed about an inventory of 10 million LOC, especially considering that as far as I can tell, QuickBooks cannot export to Excel unless there's an actual copy of Microsoft Excel installed on the same machine as QuickBooks. No love for LibreOffice, no CSV, no Excel-on-some-other-machine. Then there was the eval copy that expired. Apparently the command that you must use to remove it is "FORMAT C:".

Re:-2000 Lines Of Code

[scobiej]

And if you can't spell cheques .... ?

Re:-2000 Lines Of Code

[MacGyver2210]

Excel is a perfectly good spreadsheet program. I don't know what you think they're using it for, exactly, but for storing grids of numbers and applying simple calculations to them repeatedly, it can't be beat. I know it's the 'cool' thing to hate on Microsoft, but they actually have some good accomplishments if you look beyond their modern ventures and current vomiting-up of Windows.

The sad thing is Excel can probably do every last thing QuickBooks can, likely in about 5% of the code.

Re:-2000 Lines Of Code

[spiffmastercow]

But allowing the user to change the tax code breaks their business model and potentially opens them up for lawsuits. Why would a user buy the next version when they could just download a user-made patch? And what happens when somebody codes something stupid? A big selling point for tax software is that it's guaranteed to adhere to the tax code.

Re:-2000 Lines Of Code

[spiffmastercow]

Both your solutions, as far as I can tell, are hard coded. The second uses a bit of polymorphism, but still does not allow users to extend their system.

Re:-2000 Lines Of Code

[Anonymous Coward]

I'm not doubting the genius that is Bill Atkinson. This is a nice story.

However, I was there for the 68k architectures' heyday. The code was assembler, C was non-existent
at Apple; PASCAL was king. But the thing that must be remembered is that he was coding for ROM sizes
that a modern "hello world!" in .NET would never fit in (I forget the original MAC rom's size - 64K?).
So, he may have wrote -2,000 on the report, but in fact it may have been -100 + complete rewrite of the algorithm.

You have to remember the times then, attitude was the norm among the bit-twiddlers back then (oh, something's
in my eye).

Re:-2000 Lines Of Code

[kestasjk]

There are accountants (or any sort of professionals) that don't use spreadsheets?

Re:-2000 Lines Of Code

[Anonymous Coward]

Excel is a perfectly good spreadsheet program. I don't know what you think they're using it for, exactly, but for storing grids of numbers and applying simple calculations to them repeatedly, it can't be beat. I know it's the 'cool' thing to hate on Microsoft, but they actually have some good accomplishments if you look beyond their modern ventures and current vomiting-up of Windows.

Nobody said Excel was a bad spreadsheet program - you just don't use a spreadsheet as your accounting book of record.

The sad thing is Excel can probably do every last thing QuickBooks can, likely in about 5% of the code.

http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system

Re:-2000 Lines Of Code

[Anonymous Coward]

excel runs most of the government's accounting....

Re:-2000 Lines Of Code

[datavirtue]

Hold on, I think Windows NT 4.0 was 10 million lines of code. This is a big WTF.

Re:-2000 Lines Of Code

[Anonymous Coward]

Hi slartibartfastatp,

I think you're somewhat mislead in the complexity of the actual tax code, and the true depth of the intricacies between tax calculations not just between countries, but even between various individual situations (married, divorced, deceased, with kids, disabled, native person,.....). There are hundreds of thousands of rules - and there's no simple, easy way of making this somehow "configurable".

And yes, IWFI (I work for Intuit).

Re:-2000 Lines Of Code

[datavirtue]

Just managing an annual mountain of tax laws and applying them correctly would easily go over thousands of lines.

[citation needed]

Re:-2000 Lines Of Code

[datavirtue]

There is no way to comply with this stuff in a XML file. It has to be coded spaghetti style.

Re:-2000 Lines Of Code

[datavirtue]

Besides, it is a gaggle of 10 million LOC and there is no way to graft in a sensible solution like this. The system is set in stone without a rewrite.

Re:-2000 Lines Of Code

[datavirtue]

Whoa whoa whoa, it is taxes not business, and there is no logic involved.

Re:-2000 Lines Of Code

[tibit]

You'd hope they have some sort of a domain specific language inside of their system that can be used to express those rules, validate their consistency, solve constraints (for financial problems, such as how to maximize return on a given investment within certain limits), etc. These days you could use C++ template metaprogramming for that, but there's a point where "leveraging" the C++ compiler turns into digging a hole under yourself. I'd personally not use C++ and simply write the rule language and "engine" from scratch. It could be prototyped in LISP.

Re:-2000 Lines Of Code

[tibit]

You could equate "configurable" with "written in a language higher level than C or C++". I'm sure even Prolog would be better than plain C++ for that, in terms of programmer productivity in writing new rules, testability, verifiability against requirements, and maintainability.

Re:-2000 Lines Of Code

[jpapon]

Next you're going to tell us we can't spell color either... or civilization.

Re:-2000 Lines Of Code

[Anonymous Coward]

excel is a tool not a solution

Excel is a solution for tools.

Re:-2000 Lines Of Code

[colinrichardday]

It means we kicked your butts at Yorktown.

Re:-2000 Lines Of Code

[Kelbear]

What the OP means is that Excel is useful for analysis, calculation, and tailoring reports. It's a tool. However, Excel is not an accounting database, (a solution).

Excel isn't database software and can't generate the many day to day reports that accountants need. Aside from the most basic 1 or 2 man companies, the errors and lost audit trail from trying to generate and maintain records in excel would be disastrously bad for any company that tried to do it. You need automated processes and controls in accounting so that you can track all information properly and pinpoint fluctuations within the company with ease. If it's all in an excel file, there's no practical way to track the ongoing changes in the records.

Re:-2000 Lines Of Code

[Anonymous Coward]

On the other hand, more support incidents means that if you offer a support plan (ie. one year of support for $X), you spend more money offering the support. If you are bug free, then that support contract is pure profit.

Re:-2000 Lines Of Code

[LearningHard]

We use JD Edwards from Oracle running off an iSeries server.

Excel is used a lot for putting together large journal entries and analysis. I also have to use PL/SQL quite a bit for pulling data out of various data warehouses we have setup. Those are currently on a cluster but we are working on moving them to a nice netezza system.

Quickbooks is ok for a small business. I've always worked in enterprise so I don't have much experience with it. I tried it at home once and though it sucked.

Re:-2000 Lines Of Code

[Anonymous Coward]

30 lines of python and a MySQL instance will do this.

Source: accountant turned code monkey.

Re:-2000 Lines Of Code

[Anonymous Coward]

That's what "tax tables, files defining local accounting rules" was referring to. The "rule", by definition, is just the exception that is used in most of the cases. There, you've got youself a rule with lots of exceptions :)

Re:-2000 Lines Of Code

[slartibartfastatp]

It's easier to extend the second solution, though. Depending on how the class is instantiated inside the factory (i.e., something like reflection), you doesn't even need to change the original code, but add another library to the path.

I think what you're calling not hardcoded it's what I call configurable

Re:-2000 Lines Of Code

[spiffmastercow]

It's easier to extend the second solution, though. Depending on how the class is instantiated inside the factory (i.e., something like reflection), you doesn't even need to change the original code, but add another library to the path.

I think what you're calling not hardcoded it's what I call configurable

And I think you're confusing loosely coupled for not hard coded, unless you're talking about plugging in different DLLs or something. From the wikipedia article:

Hard coding (also, hard-coding or hardcoding) refers to the software development practice of embedding what may, perhaps only in retrospect, be regarded as input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

Re:-2000 Lines Of Code

[Bert64]

Just being bug free doesn't mean you don't need support, support is there to help people who aren't using the software properly too.
Also if the support is never used, eventually the bean counters will think its not worth the cost and cut it.

Re:-2000 Lines Of Code

[Anonymous Coward]

The idea would be to deal with it as an absolute number - he did 2000 lines of code regardless of whether it was added in or taken away (in fact -2000 should be weighted more highly than +2000 bloat, that is a separate issue).

Re:-2000 Lines Of Code

[shutdown -p now]

The most popular accounting software in Russia (and several other ex-USSR countries) not only has a scripting language, it has one that covers practically everything from GUI all the way down, stopping only at the database itself - and the product is then written in that scripting language. And it's precisely why people buy it - because they can adapt it to their needs, track local tax code changes quickly etc. Of course, only the stock unmodified scripts offer any guarantees with respect to how it reflects the tax code, but even so enough people mod it that it's one of the most popular software developer positions around there, rivaling PHP in popularity (and crappy pay).

Re:-2000 Lines Of Code

[sapgau]

I'm having a hard time understanding how configuring country parameters in the pseudo-factory is equal to hardcoding. And then you jump to implementation details with suggesting how DLLs could be used.

I think you muddled a few concepts... But, granted that might not be the best solution... what do you propose??

Re:-2000 Lines Of Code

[spiffmastercow]

I'm having a hard time understanding how configuring country parameters in the pseudo-factory is equal to hardcoding. And then you jump to implementation details with suggesting how DLLs could be used.

I think you muddled a few concepts... But, granted that might not be the best solution... what do you propose??

Hard coding indicates that something is not configurable at the user level. If you have plug-in DLLs or something of that nature then it is in fact configurable at the user level, and thus not hard coded. Whether you use a factory or indicate an actual value is not actually relevant to whether or not a value is hard coded, which was the point I was trying to make. I'm not making any suggestions about how to go about it, just pointing out that the poster's use of "hard coded" does not mean what he thinks it means.

Re:-2000 Lines Of Code

[sapgau]

I think we are almost on the same page... the big assumption here is that using parameters (like the country parameter) can be and should be user defined, thus the value read from a user provided selection, configurable text file, etc will be passed to the Factory object.

Still mentioning DLLs makes me think on how to implement it, on Windows...

Re:-2000 Lines Of Code

[spiffmastercow]

Well I guess if there were a linux version of quickbooks it would be .so files. The point is that a plugin system would allow for configuration. Just substituting values won't really work -- there are very few, if any countries whose tax policies vary only by their rates.

Re:-2000 Lines Of Code

[Anonymous Coward]

point is, just cause you can manage it, doesnt mean 10,000,000 lines of code is really something to brag about, especially for something that feels as cheap as quickbooks (though it does a ok job if your accountant cant use excel and must have things that visually represent checks)

If your accountant is using Excel to run your books that means it's time to get a new accountant.

Why? I'm sure I can manage your accounts better with Excel better than you can without it.

Re:Bah.

[russotto]

Given that they haven't managed to come out with a native version of Quicken for Mac in over 6 years, I suspect that they kept that code on a napkin... then lost the napkin.

Dr. Dobbs

[santax]

could have better done a research at how to keep a site alive with 10 mil+ ./-ers come knocking at the door.

Re:Bah.

[JoeMerchant]

Real programmers kept their code on punch cards.

Or toggle patterns written on a napkin.

FTFY

My college took out the card punching stations the semester before I took Fortran, though they still had the vacuum drum reader and used it occasionally. And, of course, the CRT terminals were inputting card format - first six characters for line number, 78 characters per line max.

The fossilized prof told stories of entering assembly op codes, in octal, with rotary dial interfaces.

Now, get off my... um, I forget, but get off it, NOW!

Re:Bah.

[larry bagina]

Well they did finally re-compile Mac Quicken 2007 for x86 (only $15! to upgrade) so I guess they found the napkin. After a year of searching for it.

Re:Bah.

[eruci]

They still do not support quickbooks for mac. I had to find a windows machine just for it

I thought I disabled ads.

[WiiVault]

Oh and as most anybody who uses QB often knows- it does suck quite mighty and gets slower even as PCs get faster. Piles of code isn't always a good thing, sometimes it just means you have a bloated heifer with lazy programming and no real improvements in half a decade or more.

Re:I thought I disabled ads.

[PhunkySchtuff]

As a QuickBooks user, who prefers it to MYOB at least, I ask this question in all honesty:

What else is out there for small businesses that's better than QuickBooks and isn't a cloud-based service?

Re:I thought I disabled ads.

[c0lo]

Piles of code is never a good thing

FTFY.

for anyone that may need an explanation - does anyone? - either the code is necessary (and, thus, won't be thrown into a pile, but carefully and continuously polished and made as small as possible) or it's not - in this case, it's truly a liability.

Re:I thought I disabled ads.

[Amouth]

a quick google - shows

http://www.gnucash.org/

and it seems to be quite active

Re:I thought I disabled ads.

[larry bagina]

GnuCash, perhaps?

Re:I thought I disabled ads.

[WiiVault]

There are a number of solutions, and I'm not one to call somebody an idiot for using one over the other if it works best for them. But as a fellow Mac user (oftentimes) I guess it depends on size and complexity. That said, even the big bad slow Excel can at times to the job better than QuickBooks. I think for the very small Excel can be enough, but for larger, even entry level "enterprise solutions" are often a better fit. It just sounds like you are comfortable with QB, and that's fine. I'm not so high and mighty to think I can dictate to others. I just feel like it hasn't gone anywhere, and the company behind it seems to be stuck in the past just like Quicken demonstrates. But either way this whole article is pretty much an ad, praising codebloat nonetheless and seems out of place on a news site.

Re:I thought I disabled ads.

[rueger]

Gnucash is most assuredly not a replacement for Quickbooks, if for no other reason that ta some point you need to interface with a real accountant, and Handing over your files from Quickbooks or Simply Accounting makes that MUCH easier.

Re:I thought I disabled ads.

[WiiVault]

Indeed, as the parent you nailed what I actually meant.

Re:I thought I disabled ads.

[DogDude]

Excel and Quickbooks are as similar to each other as Quicktime and Oracle: they're not in any way similar.

Re:I thought I disabled ads.

[DogDude]

Gnucash is to Quickbooks like Notepad is to MS Office. Gnucash has no functionality for any kind of business accounting.

Re:I thought I disabled ads.

[Anonymous Coward]

This, unfortunately, is the problem. Quickbooks is a bloated, buggy pile of crap, and the only thing worse for small business accounting is not using Quickbooks.

Re:I thought I disabled ads.

[afidel]

Sage Peachtree is the main competitor in the self hosted small business accounting realm. To be honest if my dad wasn't so opposed to a hosted solution I would have had him go that way as even with 5 users the cost difference once you add up the server and licenses wasn't that great over five years.

As far as QB goes, it seems to finally be ok. Up until 2007 it still couldn't run as a limited rights user and required short printer names both of which caused me serious pain as I was the IT department for a midsized accounting firm and getting QB running in Citrix was NOT fun. We had premier enterprise support and their answer to the LRU issue was to grant Everyone full rights to HK_Classes_Root (NOT a good idea). I eventually figured out what keys the user needed access to and published the solution online to help others but their spaghetti code was so bad even then that nobody could actually tell what it was doing to give me the right answer.

Re:I thought I disabled ads.

[macs4all]

As a QuickBooks user, who prefers it to MYOB at least, I ask this question in all honesty:

What else is out there for small businesses that's better than QuickBooks and isn't a cloud-based service?

Sure! How about PostBooks?

Simple, Open Source. FREE. Works on Macs, Linux, and oh, yeah, those Windows things.

I believe it even will read QuickBooks files, and will scale to the full-blown (not free) xTuple ERP system!

Re:I thought I disabled ads.

[ChunderDownunder]

isn't gnucash compatible (file filters) with Quicken?

Re:I thought I disabled ads.

[PhunkySchtuff]

Looks very interesting. I've never heard of it before, but am downloading it now.

Re:I thought I disabled ads.

[MacGyver2210]

You can use pretty much any spreadsheet program if you're not afraid of math and numbers.

Re:I thought I disabled ads.

[ekimd]

Bologna. I've been using Gnucash for years on a sizable business with no problem. I'm also very familiar with QuickBooks (I worked as a staff accountant for several years). Sure, there's a lot that quickbooks can do that Gnucash can't, but there's nothing fundamentally missing from Gnucash to prevent someone from using it for business purposes. If FOSS means anything to you, Gnucash is the only way to go.

Re:I thought I disabled ads.

[ekimd]

I disagree. As long as your books are kept correctly, the accountant only needs three things:

1) Profit and Loss
2) Balance Sheet
3) Depreciation Schedule

Gnucash does all of those. Print them out. Hand it to your account. And you're done.

Re:I thought I disabled ads.

[Anonymous Coward]

GNUcash's reporting is dismal, and very few accountants out there will touch it come tax season. QB is the only other Windows app aside from Adobe CS that keeps me on Windows. Every couple years I check out GNUcash' progress and have been disappointed every time.

GNUcash is plenty fine as budget software (as it's Quicken compatibility would suggest), but it has nowhere near the functionality of the major business accounting apps. As much as I wish it was. Quickbooks/Simply/whoever's yearly 'march of death' upgrade path is ridiculous, and the only reason customers grudgingly go along with it is because there's no viable alternative for a similar price.

Re:I thought I disabled ads.

[Stirling Newberry]

The value of bad software is the pain of switching from it.

Re:I thought I disabled ads.

[datavirtue]

Peachtree.

Re:I thought I disabled ads.

[DogDude]

GnuCash has no payroll functions at all. How do you run a "sizeable" business without paying employees?

Re:I thought I disabled ads.

[Anonymous Coward]

procmon and procexp from sysinternals works a treat

Re:I thought I disabled ads.

[Anonymous Coward]

If you use an open source app like GNUcash, why would you be paying your employees? Shouldn't they be free as well??

Re:I thought I disabled ads.

[TemporalBeing]

I disagree. As long as your books are kept correctly, the accountant only needs three things:

1) Profit and Loss 2) Balance Sheet 3) Depreciation Schedule

Gnucash does all of those. Print them out. Hand it to your account. And you're done.

As a small business owner using GnuCash, it's not quite that simple. Accountants like using tools like QuickBooks that they are very familiar with, and they don't want to have to re-enter all the data. So printing out the information is useless for them. You really need to export it to a format that both support.

Sadly, GnuCash does not support exporting Quicken/QuickBooks formats. It will important them with some extra file filters, but no export capability. My solution is to export to CVS which QuickBooks can import as well. Haven't tried it yet, but my accountant & I will be working through it when the time comes.

Re:I thought I disabled ads.

[Anonymous Coward]

As a QuickBooks user, who prefers it to MYOB at least, I ask this question in all honesty:

What else is out there for small businesses that's better than QuickBooks and isn't a cloud-based service?

Is Peachtree still around? It was big in that market in the 90s.

Re:I thought I disabled ads.

[GNULinuxGuy]

A quick search reveals payroll can be handled with a 4 step process. Seems pretty simple to me. If it's actually a problem for you it really shouldn't require much additional code to implement something.

Re:Not for public companies

[Joe_Dragon]

that is in the cayman islands ver of the software.

Re:Bah.

[Anonymous Coward]

How Intuit Manages 10 Million Lines of Code?

Very carefully. Next question!

Re:Bah.

[SuluSulu]

Real programmers keep their code on punch cards.

No, real programmers do it by hand.

I have to use this software at work

[credd144az]

I find it to be bug laden and amateur for the most part. Use both Quickbooks Accounting (Retail) and their Point-of-Sale. Quickbooks works for the most part I guess, Point-of-Sale is Busch League...

Re:I have to use this software at work

[Pope]

Quickbooks works for the most part I guess, Point-of-Sale is Busch League...

Ah, you nailed the problem: too much drinking on the job!

Re:I have to use this software at work

[credd144az]

I need to start. If you can't beat 'em join 'em, right?

Was Intuit important in the past or something?

[EzInKy]

And, even they had some signficance sometime or somewhere, why should I care about how they manage lines of ancient code?

Re:Was Intuit important in the past or something?

[DogDude]

Intuit makes the most widely used accounting software on the planet. They have significance, but you're just clueless.

Re:Was Intuit important in the past or something?

[RulerOf]

And, even they had some signficance sometime or somewhere, why should I care about how they manage lines of ancient code?

Because they roll up the money they make on re-selling the same code base year after year, insert the money in their nostrils, then finally, they separate out single lines of code and snort them.

That's why.

Re:Was Intuit important in the past or something?

[rgbrenner]

$3.9 billion in revenue last year

Re:Was Intuit important in the past or something?

[PmanAce]

Because unlike yourself, I have worked with many, many thousands lines of (current, not ancient) code. Doing so requires discipline and good skills by all team members to be able to be productive and keep the project streamlined and on time. It is a good read for all professionals involved in the software industry. If you don't care about either the company or code, why the funk are you reading this and posting here???

Re:Was Intuit important in the past or something?

[macs4all]

$3.9 billion in revenue last year

Yet they whine about "spreading resources too thin" as an excuse for inexcusably bad Mac support...

Die, Intuit, Die. Die, Die Die.

Re:Was Intuit important in the past or something?

[macs4all]

keep the project streamlined and on time.

I think I just threw up a little...

Re:Was Intuit important in the past or something?

[EzInKy]

If you don't care about either the company or code, why the funk are you reading this and posting here???

Good question! I guess it's because I got hooked on slashdot over a dozen years ago. Back then it was much more than an advertising medium for billion dollar corporations such as Intuit though.

Re:Was Intuit important in the past or something?

[lwriemen]

You really have to wonder how much companies pay for product placement in these articles. I counted at least 10 companies besides Intuit getting explicit mention with some product of theirs.

Re:Was Intuit important in the past or something?

[Anonymous Coward]

They are most widely used only for small business and only in the US. So in this case you are the one that is clueless... There are actually packages that are more popular and work better, but they are not in the same market segment

You mean...

[stanlyb]

That paying well to a small team, and treating them like a people, not commodity, is actually worth the money!!!!
Oh, noooo, no, what about all the HR screams that this is not a sound business???

Re:You mean...

[JaredOfEuropa]

It’s not only about the money; I recently had an interesting discussion on this topic with a few “management by the numbers” suits of a large company. They do see the downside of increased specialization, compartmentalization and commoditization in IT jobs, combined with an overload of process and management. They understand this has a profound impact on speed, quality, job satisfaction and especially agility and the capability to innovate, but besides a cost reduction it brings something else to the table: predictability. In other words: a standard team of corporate IT drones may deliver “X” with good-enough quality, in 8-10 weeks, for $150k. A small, agile team of motivated coders can deliver “X” with great quality, in 5-12 weeks, for $140-170k (depending). The small team might seem the better pick but the suits prefer the more predictable standard team. Easier to plan, to budget for, to outsource, and it is a hell of a lot easier to manage resources than it is to manage (highly individual) people.

In fact, these managers understood that their approach is likely more expensive in the long run; there are lots of hidden costs in the reduced quality of the work, in talent management (staff turnover and getting the replacement hires up to speed, something I see a lot of in outsourcing partners), loss of agility and the ability to react to changing circumstances... but despite all that, they still prefer the predictable way of doing things.

Re:You mean...

[heathen_01]

Your suits might have a point about predictibility being worth paying a bit more for, however because of

lots of hidden costs in the reduced quality of the work, in talent management (staff turnover and getting the replacement hires up to speed, something I see a lot of in outsourcing partners), loss of agility and the ability to react to changing circumstances...

And the fact that a lower quality team may fail alltogether to actually produce the desired product, there is actually no more predictibility anyway. The problem is they manage by numbers, regardless of if the numbers are correct or not.

Re:You mean...

[stanlyb]

I want to give you just one example of predictable management: RIM

If it takes 20 million lines of code

[codepunk]

If it takes 20 million lines of code to do ones taxes there is simply something very wrong with the process.

Re:If it takes 20 million lines of code

[jmerlin]

There isn't any need for it. I suspect it's because they're doing things horribly, horribly wrong. I'd be willing to bet a few billion dollars that a competent group of people could implement QB in under a quarter of the lines of code while both improving the quality and making it significantly faster in every regard.

Re:If it takes 20 million lines of code

[Anonymous Coward]

If it takes 20 million lines of code to do ones taxes there is simply something very wrong with the process.

Taxes in which country, state, province, etc?

Do you see the problem with your statement?

Re:If it takes 20 million lines of code

[Anonymous Coward]

Also, stable. If it's 11 mill. C++ code lines, want to bet there are any crash or memory corruption bugs in there? You don't just update to modern practices in a heartbeat either, so I expect this is more like C/C++ like it was 12 years ago than C++ as it is today.

(I know of a small shop that still compiles their multimillion line code base with Borland C++ version 3)

Re:If it takes 20 million lines of code

[DogDude]

I'd be willing to bet a few billion dollars that a competent group of people could implement QB in under a quarter of the lines of code while both improving the quality and making it significantly faster in every regard.

So then why has nobody come up with a better product, then, Mr. Billionaire?

Re:If it takes 20 million lines of code

[codepunk]

I have often thought about this very question in regards to quickbooks. The best assumption I can come up with is it is difficult to get anyone interested in writing such a application.

It is tax software for god sakes, I cannot really seeing that many developers jumping up and saying hey that fucking rocks I want to write some tax software.

Re:If it takes 20 million lines of code

[Capt. Skinny]

I'd be willing to bet... that a competent group of people could implement QB in under a quarter of the lines of code

Agreed. But then the business aspect comes into play: can they market it well enough to displace the market leader? There's plenty of crap out there that makes money despite the fact that better options exist. If it was as easy as just competent programming, someone would have done it already.

Re:If it takes 20 million lines of code

[DogDude]

It might be boring, but there are buckets and buckets of cash to be made from it. Right now, almost every privately owned, small business in the US uses it, and pays a few hundreds bucks every year or every few years to "upgrade" it. It ain't sexy, but it's lucrative as hell.

Re:If it takes 20 million lines of code

[kalpaha]

That may be true of most any software, but in almost no case is it wise to do so. Read: http://www.joelonsoftware.com/articles/fog0000000069.html

Re:If it takes 20 million lines of code

[oatworm]

It's not terribly difficult from a technical perspective, but there are a few caveats to keep in mind:
- Everybody and their mother (at least in accounting-related clerical work) knows Quickbooks. Whatever you come up with would have to be similar enough to justify the training expense.
- Intuit really does spend a lot of effort keeping track of various local, state, and federal regulations, at least in the US, and applying them to their software. That's not cheap or easy.
- Since Quickbooks is something of an "industry standard", it's possible to share Quickbooks files among necessary individuals (outsourced accountants and the like) and know that the books are getting from point A to point B. Not everyone has a copy of, say, Peachtree lying around, to say nothing about GnuCash or anything else.
- Accounting is generally not something that businesses start "experimenting" with. Predictable and supported are what they're looking for. Given a choice between a technically superior product from a company that just received angel capital last week and a predictably wrong product supported by a company that's been selling and supporting accounting software for 30 years, most businesses will go the safe route and buy the technically weaker package. It's actually pretty rational if you think about it; switching accounting packages is not trivial by any stretch of the imagination, so picking the product from the company with proven staying power makes a lot of sense.

Personally, I think Quickbooks is kind of the Microsoft Access of the accounting world - oh yes, there are better, far more stable tools out there, but too many people know Access and its quirks for all but one or two of them to catch on in any meaningful sense. That's inertia for you.

Re:If it takes 20 million lines of code

[gmhowell]

I'd be willing to bet a few billion dollars that a competent group of people could implement QB in under a quarter of the lines of code while both improving the quality and making it significantly faster in every regard.

So then why has nobody come up with a better product, then, Mr. Billionaire?

He said 'willing', not 'able'.

Re:If it takes 20 million lines of code

[PmanAce]

Depends on how many versions of the damn thing you are willing to upkeep in the same or different code base. Good luck integrating a moderately complicated bug fix in multiple branches of different code bases.

Re:If it takes 20 million lines of code

[UnknownSoldier]

Agreed. The problem is most people are too stupid to demand a simple solution.

Re:If it takes 20 million lines of code

[jmerlin]

That article isn't particularly correct, on the one hand, and it's not apt in this discussion at all. Creating a competing product is not a refactoring, and reducing millions of lines of code to a few hundred thousand is almost certainly going to massively increase maintainability..

For example:

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time

That's just flat out untrue. Everything around us is constantly improving. Database techniques, database systems, file systems, operating systems, APIs, networking, hardware, engineering principles, and the trends that accompany these changes, libraries that do a lot of the stuff you did manually, etc. I've seen fairly large JS apps written years ago before wide adoption of tiny-yet-powerful libraries reduced by over a factor of 30x in code size. That's moving non-DRY code into a more maintainable fashion. It's sound architecturally. You see, Joel also advocates this: http://www.joelonsoftware.com/articles/fog0000000007.html. This is in many ways contradictory to that very statement. While you may not necessarily have MORE EXPERIENCE from the team re-writing it, you have the advances in computing which are constantly growing. To deny that this would have a significant impact in re-engineering a product is foolish.

As much respect as I have for Joel and his experience, some of his beliefs are just wrong in the world of software engineering.

Re:If it takes 20 million lines of code

[cheesybagel]

Perhaps they are paying those Lahorian Indians by the LOC.

Re:If it takes 20 million lines of code

[jmerlin]

This is more in the spirit of my response. That's the point I meant to make; by today's standards, what they have might be "the wrong thing to do." With the significant advances in in almost area of software engineering platforms, frameworks, libraries, and engineering principles we've had since a majority of the product was designed, my expectation is that it will be significantly smaller, significantly faster, much easier to maintain, and naturally much more stable a product. If I owned QB, I would be spending a few tens of millions refactoring my product with the latest technologies.

Look at Chrome. It's constantly inundated with the latest and greatest in many areas. It's arguably the best browser that has ever existed. And it pushed Firefox to behave in the same way, which has made it a better browser too, and Google pushes those changes up to V8 and WebKit, which in turn make Safari and anything else that uses WebKit better (like Netflix on non-PC platforms) or anything that uses V8 better (Chrome OS, Node.JS, etc). This modularization and projects sharing dependencies is important and fundamental to this rapid progress and high quality. These are lessons that could be used to make QB significantly better than it is today.

Re:If it takes 20 million lines of code

[Anonymous Coward]

The "single worst mistake" is a mistake because atomic single step megaprojects always fail.

If a competent developer rewrites a single component from scratch, it's more likely a success than not. The disaster happens when the size of the rewrite grows too big even for a well-knit team.

Re:If it takes 20 million lines of code

[DMUTPeregrine]

My father used to work for Intuit. Their license code scheme was terrible.
Essentially they encoded the number of licenses to be bought by a simple substitution cypher (think a not-invented-here version of Base64). You could buy packs of licenses up to 999 at a time, or pay a bunch for unlimited licenses. An unlimited key was indicated by setting the number to 000. Anyone with the desire to and a few example license codes (say, from buying packs with different numbers in previous years) could easily find the encoding scheme, then change any license code into an unlimited code.
He bugreported this, only to have it closed as a "won't fix". It wasn't considered an important enough problem to bother with.
So yeah, I can see how they'd end up with ten million lines of code.

Re:If it takes 20 million lines of code

[EuclideanSilence]

If it takes 5 million lines of code to do one's taxes, then there is still something very wrong with the process.

Re:If it takes 20 million lines of code

[Geeky]

Nail. Head.

Even when better, cheaper (even better free/open source) alternatives exist, brands count. Look at monitoring (something of my specialist area). BMC still does well despite being ridiculously expensive for what it does. I'd wager that most customers would get just as much functionality from one of the cheaper alternatives (even the likes of Nagios), but BMC have managed to occupy the Gartner magic quadrant and big companies will only look at the big names.

I'm forced to use BMC Patrol, and some of the bugs in what should be a mature product are shocking.

Re:If it takes 20 million lines of code

[Viol8]

Thats all config, It shouldn't affect the core engine size.

Re:If it takes 20 million lines of code

[Anonymous Coward]

Don't forget the international market - there are a shit load of different tax environments out there beside the USA, all with their own quirks, special cases and plain out weird regulations.

Re:If it takes 20 million lines of code

[zippthorne]

The statement is still correct. If it's not a problem with the computer program, there is something wrong with with the tax code portion of the process if it requires 20 million lines of computer code to calculate. How can you ever be sure you have done them correctly? Even without using a computer.

Perhaps especially without.. 20 million computer-lines worth of tax code doesn't seem like something that a person would even be able to calculate without a computer.

Maybe computers are the worst thing to happen to accounting and taxation, because they allow the code to accumulate to preposterous levels without collapsing under its own sheer weight.

Re:If it takes 20 million lines of code

[MacGyver2210]

Considering QuickBooks gained much of its end-user popularity and success from spamming infomercials on every TV channel they could, as well as free tax return prep from Intuit slathered with QB ads, extreme internet and flyer marketing, and a lot of door-to-door pushing to large companies, I have a good idea of where to start.

Also, I think you severely underestimate how absolutely mind-numbingly boring writing accounting software is. Just because I COULD rewrite QB doesn't mean I want to.

Re:If it takes 20 million lines of code

[Anonymous Coward]

If it takes 20 million lines of code to do ones taxes... there is simply something very wrong with the tax code!

Re:If it takes 20 million lines of code

[Anonymous Coward]

Accounting > Tax Return Preparation

Re:If it takes 20 million lines of code

[datavirtue]

I love writing business and tax software. It is the reason I do this shit. Although, my dream is to one day retire and write video games.

Re:If it takes 20 million lines of code

[datavirtue]

Also, the area of payroll is virtually unexploited. But it need to be written for the small service providers. The thing is, software for small business is a niche. It is literally a small fraction of the overall user base. When you run the numbers a large company sees that they throw away more money each year on paperclips than they could make in building a niche product for small businesses.

Re:If it takes 20 million lines of code

[datavirtue]

Boring for you.

Re:If it takes 20 million lines of code

[DogDude]

No, Intuit has an elaborate payroll system for small businesses. It's between $100-$500 a year, and it's done through Quickbooks. It's brain dead simple to use.

Re:If it takes 20 million lines of code

[Anonymous Coward]

I'd be willing to bet that a competent group of people could assemble a football team for less than the Giants payroll. SO WHAT? This conversation has absolutely no relevance on anything resembling real business. go back to coding.

Re:If it takes 20 million lines of code

[Anonymous Coward]

Well, at least in Germany, the Government provides a free tax program (called "Elster", after the bird that likes to steal shiny things for their nest). Everyone is required to use it to do their taxes, so the program is always up to date. You can also use it as a library (i.e. you don't have to use the GUI they provide) and you can use an online service to submit your taxes electronically, even signed with an electronic certificate, so you don't even have to print the pages and sign them anymore.

So yeah, no real need to "track" laws and such, just to get the rules incorporated into your program. Just use the damn government provided library, and if something is wrong, its not your fault.

Re:If it takes 20 million lines of code

[lwriemen]

As much respect as I have for Joel and his experience, some of his beliefs are just wrong in the world of software engineering.

That's because he is often making ignorant statements based on inexperience. This is prevalent in the software industry, where some guru who is very good at apples gets an audience for his statements on oranges.

Re:If it takes 20 million lines of code

[lwriemen]

If you look at a list of their acquisitions, you can see why they have 20 million lines of code in a single code base. Merging and kludging generates a lot of overhead.

Re:If it takes 20 million lines of code

[clintp]

disclaimer: I work in the financial software field in a business very similar to Intuit.

Every time this comes up Slashdot is inundated with lots of comments about how easy this should be. It's not. Get over it.

The problem with financial software is that because of regulatory constraints and tax laws it's nearly impossible to start from scratch. Tax laws are vast. You just won't believe how vastly, hugely, mind- bogglingly vast they are. I mean, you may think it's complicated to write an operating system, but that's just peanuts to tax law.

The secondary problems for payroll compliance and tax law is that they change (with alarming frequency). You probably don't know this because you're a single case, but on the federal and state level hundreds of changes happen each quarter for something like payroll taxes. Almost none of them apply to you. But every one of them applies to someone, and it's something you've got to get right. Oh yes, and let's not forget the thousands of cities, counties, and school districts that all have their own compliance.

In software development, you're left with a few choices in this matter. Pare down the problem, scale up the development, or adopt a progressive model and hope you don't go bankrupt waiting to ship while keeping up with the changes along the way.

If you pare down the problem you've limited your market share. Deciding that you'll only handle, say, Federal filings means that your customers are left on their own for state compliance. It's a niche, sure, but a really small one. That's how every one of the companies you've heard of doing tax filing or payroll software started. And then you work really hard to make your company more and more relevant and scaling up quickly.

For option two, development can't scale this large from scratch. Brooks's Law (in this case) means the entire thing will collapse into a black hole of non-shipping code long before you've made it out of Year 1. And it's got to be nearly perfect -- people will tolerate a certain number of bugs in their games, but getting penalties from the IRS will keep your customers from coming back.

So you want to tackle federal and state taxes (no local) with your launch product? Expect to take at least a couple of years for this, and line up the appropriate capital to keep you in business meanwhile. Plan on using the last 25% of your development and test cycle bringing the code up to compliance with the regulations that have shifted while you were mucking around building the product. (i.e. if you can write and test it in 18 months, expect to ship in 2 years because you'll need the last 6 months just to catch up). That number is from experience, folks. Just try to find a venture capitalist that'll fund this kind of effort into a market that already has a few large players (Microsoft Dynamics, Intuit, Solomon) and dozens of small ones for a product that's just marginally better. Just try.

"I'm a web developer! I deal with shifting standards all the time!" No, not like this. There are thousands of standards and they move as often as quarterly and they're all published separately by different entities that don't interact at all. Screwing up browser standards in a web application usually means something doesn't display right and you find out right away; doing the same in payroll taxes means large penalties vastly disproportionate to the size of your mistake which you don't hear about until the letter arrives months later.

"I'll build clever databases!" "Properly designed rule sets will be my silver bullet!". Nope, think again. You're working against an adversarial opponent: politicians. Politicians need to raise taxes without looking like their raising taxes. Their rule sets can have unlimited complexity in their efforts to tax you while not looking like they're taxing you. They do just make shit up. If Congress wants to have an employer payroll tax for companies over 20 employees that have more than

Re:If it takes 20 million lines of code

[jmerlin]

Then you've just pointed out a huge design flaw: even if there are millions of tax rules over decades that need to be accounted for, you don't do it with code. I've seen projects that can scale to post-processing effects like this and they don't do it with code. The magnitude of the problem doesn't imply a need for a lot of code, nor a complex solution. It's harder to maintain code than it is to write code. That's the entire principle behind modern software engineering: if you don't have to write code, don't. I don't want 200 programmers hammering out specific edge-case tax rules in my software. You don't maintain code written like that.

Re:If it takes 20 million lines of code

[jmerlin]

Based on facts and evidence, not my opinions. Learn to read and comprehend before you troll, thanks. We call this scientific evidence. It tends to trump opinion pieces like most of Joel's work.

Re:If it takes 20 million lines of code

[clintp]

Almost everything can be accounted for in good table design and is. There does come a point where table design and maintenance simply can't accommodate a particular rule. Sometimes exceptions are thrown, longjmp() invoked, raise() called and god help us a GOTO executed.

Tax law is just another programming meta-language which later has to be compiled to code.

Re:If it takes 20 million lines of code

[bored]

Your using chrome as an example? Sure its fast, but its also 6M LOC. The main reason apple chose KHTML/KJS was that it was easy to maintain at something like 150K LOC.

Re:If it takes 20 million lines of code

[jmerlin]

4.3M of which is Webkit, which is developed by Apple. That figure also includes a massive number of tools, 3rd party libraries, testing code, chrome frame, etc. Chrome itself isn't that large. V8 is also its own completely separate project (albeit still maintained and developed by Google). And Chrome shares code with Chromium, too. The point is that it's not one monolithic behemoth like QB. It's a very nice ecosystem of well behaved, well written, and well maintained pieces working together, not some enormous 10Mloc monster that can't be maintained to any reasonable degree.

Re:If it takes 20 million lines of code

[Anonymous Coward]

The "he" in my comment referred to Joel(onsoftware), not you. I have no idea who you are or what you usually say in comments.

"Poorly"

[Anonymous Coward]

Story has too many words when one will suffice.

there's no good competitor

[Skynyrd]

My last job involved many, many frustrating hours with QuickBooks - every week. It's a steaming pile of crap. There were so many basic things missing, like decent reporting, that it was a total joke. I could go on for many long rants about how much I hate the software. We wanted to integrate Fishbowl, so we could do some trick inventory manipulation, but it wasn't implemented before I quit. They are still working on it.

In my new job, I get the daily reports from our 5 stores. QB failures are mentioned daily. I am so happy to be in an entirely different department.

I really wish there was competition for QB. I think it's a fine platform if you are a very small business with a limited product line. Get complicated, and it fails.

Re:there's no good competitor

[DogDude]

Quickbooks is an accounting package, not inventory/point of sale. It sounds like your last job involved pounding nails in with a screwdriver.

Re:there's no good competitor

[Sechr Nibw]

Oh okay. http://intuitpayments.com/POS

Re:there's no good competitor

[DogDude]

Those two programs are completely and totally unrelated to each other in any way. Their POS system is the codebase from RetailPro that they bought about 10 years ago. Quickbooks is obviously much older, and unrelated.

Re:there's no good competitor

[DerekLyons]

I really wish there was competition for QB. I think it's a fine platform if you are a very small business with a limited product line. Get complicated, and it fails.

So rather than wishing for a competitor for QB, which would be designed for the same market and thus almost certainly have the same flaws... get off your butt and search out the proper program designed for your business/sector. QB is a good tool, but if you're pushing past it's boundaries, that's not QB's fault.

Re:there's no good competitor

[DigiShaman]

Sage (ERP, Peachtree Quantum), and Microsoft Dynamics seem to be pretty popular too.

Re:there's no good competitor

[afidel]

Dynamics is fine as long as you don't involve the POS CRM module (at least that was the case six years ago when I last had to deal with that evil, evil pile of junk).

Re:there's no good competitor

[Anonymous Coward]

I was going to post my experience, but looks like you've covered rather completely. Giant steaming shit-pile. I am simply astounded how badly it is designed. I soppose "designed" isn't the word I'm looking for, more like crudely mashed together with fucking sausage hands.

-s

Re:there's no good competitor

[macs4all]

Dynamics is fine as long as you don't involve the POS CRM module (at least that was the case six years ago when I last had to deal with that evil, evil pile of junk).

WHICH Dynamics? Great Plains, Navision, or Axapta?

They are ALL considered "Microsoft Dynamics", but are not in ANY real way "related" (well, Navision and Axapta share some history) other than Microsoft has spent the past 10 years RUINING each of them in its own special way...

Re:there's no good competitor

[Buchenskjoll]

You could add Solomon and C5 to the list. I think Dynamics C5 covers the same customer groups as QuickBook in the vastly interesting markets of Denmark and Iceland. NAV and AX share very little history, they were mostly merged because the company behind Axapta was close to bancrupcy. After the merger the new company spent about a year getting pimped up for a Microsoft takeover.

Re:there's no good competitor

[Anonymous Coward]

I agree quckbooks sucks. Always has. We just wrote our own account tracking, and had a real accountant do the review and sign off. At the time, quicken wanted to hijack your data, and was difficult to use in a multi-user multi office (different region) environment. I was so happy to get rid of that quick books, and I wonder how any one can trust them after they pulled that stunt.

Re:there's no good competitor

[Anonymous Coward]

Installing IE 9 breaks the "Import Accountant's Changes" function on QB 2011. Yes, the desktop version. The solution is to uninstall IE 9 and revert to IE 8. No joke. QB is indeed a steaming pile of crap.

Re:there's no good competitor

[DaveGod]

QB... for 5 stores?

QB is for small organisations. It works very well for that. QB is by far and away the easiest widely-used software for a non-skilled person to use. Most small biz do not have their own bookkeeper, they get some administrative assistant to do it with maybe half a day's training from an accountant. And no, an administrative assistant is no substitute for a bookkeeper, which is a skilled, specialist job requiring training, experience and discipline.

QB is not crap just because it doesn't do the job you wanted it for in the same way a motorcycle isn't a crap vehicle just because it doesn't do haulage very well. You had the wrong tool for the job. Well okay, it's premier line is maybe stepping out into waters it's not best suited for, but I'm surprised if anyone who has any idea what they're doing is recommending that.

With 5 stores, the obvious software to have a look at is Sage. It's a lot more powerful, but does require a competent bookkeeper with good Sage experience and a skilled-person salary. There's a very good chance you'll have even more problems with Sage, not so much due to the software not being able to do something, but rather because it often requires a specific way of doing things - a particularly disciplined, systematic approach that is a result of their higher product lines which assume you have dedicated sales and purchase ledger clerks, carefully thought out systems with regular housekeeping routines etc. Once mistakes get entered and things get messy, the mess stacks up real fast.

Re:there's no good competitor

[afidel]

GP, I forgot they had other ERP offerings.

Re:there's no good competitor

[Skynyrd]

I really wish there was competition for QB. I think it's a fine platform if you are a very small business with a limited product line. Get complicated, and it fails.

So rather than wishing for a competitor for QB, which would be designed for the same market and thus almost certainly have the same flaws... get off your butt and search out the proper program designed for your business/sector. QB is a good tool, but if you're pushing past it's boundaries, that's not QB's fault.

Read much?

I no longer have that job. In my new job, I see the reports, but it's isn't even my department. I have no desire to spend my evenings and weekends finding a solution to some other guy's' problem.
The department I run has plenty of ways to use my time. I certainly don't need to go to IT/IS and tell them what software to replace our POS system with.

Re:there's no good competitor

[DerekLyons]

I no longer have that job. In my new job, I see the reports, but it's isn't even my department

Then STFU. It's not QB's fault that your past or current company is using it for a purpose it's not intended for, and you're a jackass for blaming it.

Intuit is the only game in town

[atchijov]

and it shows. First of all, I have been using Intuit for last 6-7 years. Secondary, I do appreciate the fact that US tax law is horribly complicated. However it seems that over last 5 years quality of Intuit software is going down the drain. Go to Intuit support forums and you will see what I am talking about. So answer to the question "How Intuit Manages 10 Million Lines of Code" is - poorly.

Re:Intuit is the only game in town

[Anonymous Coward]

This is not at all surprising. I could mention a dozen companies which make off-the-shelf software for Small and Medium Businesses, which have followed the same trajectory (I'm working for one myself right now, sigh...) It goes like this:

There is initially lots of competition. But some companies hire coders like GoodNewsJimDotCom below - coders who can churn out a couple of hundred thousand lines and get something that work reasonably well. These people did of course learn about software engineering practices at school, and they may even think they're following them, but because they're coding alone, they don't. In a sense, these people can be very productive, and there's definitively something enviable about their lack of self-criticism and self-doubt. Let's call him "Jim".

Companies with these types of coders succeed in the beginning, because if a customer asks for a new feature, Jim can provide it much faster than a more careful developer. And of course, buyers have no way to judge code quality, even if they were aware of the costs that is quietly incurring, which they aren't.

Then after a year, the product is already getting profitable and they're expanding. A new developer, Joe, is hired. He has trouble reading the codebase (because the only way Jim can keep track of those already plentiful code lines in his head, is that it's all done exactly the way he expects it to be done). However, this isn't a problem, because Joe was hired to develop a separate subsystem in the software anyway. When it has to interface with Jim's code it's kind of messy, so Joe reduplicates a lot of effort, but that isn't yet a problem, because Joe is a kindred spirit to Jim (there's a reason Joe chose him out of the 40+ applicants), and can churn out thousands of lines of code without trouble.

They hire a few more developers (Jack, Jill and Jeremy), each one with effective responsibility for a smaller and smaller part, and thus less productive. Now and then, they are forced to deal with each other's code, and typically lots of bugs are introduced when that happens. The weight of the codebase starts to make itself noticed, and more and more time is spent on bugfixing. The sales department, out of experience, are no longer promising custom features as a carrot, and in fact they've started to charge by the hour for implementing some of the more "ambitious" new features.

Then disaster strikes. Joe is divorced. Or his father dies. Or he has a baby. Or he has a religious experience and leaves to develop scripture browsing software for a non-profit. Or he's hit by a bus. Whatever, suddenly a mind has responsibility for millions of lines of code which it didn't write, or which suddenly seem incomprehensible from depression, distraction or sleeplessness. Now the downturn starts.

The company is desperately looking for someone to replace or assist Joe, while keeping up outward experiences. Customers aren't complaining more than before - not yet, anyway. They don't find it. New developers, although with the same spirit Joe had when he started, are overwhelmed with a mountain of code they can't possibly understand. Developers who have worked outside the SMB market (consulting for large companies, probably) laugh and shake their heads - not for a million dollars! And we're better paid where we are anyway! The years pass. Now Jane leaves too (she had a baby, and decided to move back to her hometown), and the module she had responsibility for falls into disrepair. Customers who relied on that module are getting increasingly chilly towards customer support - since Joe's responsibility was the mostly stable core of the product, his loss is felt less directly by customers, but Jane is another matter. More years pass. Customers pretty universally hate the product, but it's become a standard, it's what you have to work with if you're in this business. Profits are still rising. Hordes of developers are added, but it's hardly noticeable when it comes to features - all effort is spent keeping the program marginally afloat.

Linux - Not Even Close

[rueger]

Quickbooks is the one thing that keeps Windows on my machine, and is the only reason I ever boot into it.

I tried hard to beat WINE into running it, but alas no luck - at least the version I run.

I looked at what's out there in Linux accounting software, and either it was really obscure, apparently abandoned, or aimed at mega-corps, not small and home businesses. Plus none of it offered an easy way to handle Canadian tax frameworks.

And of course we wanted an accounting package that our accountant would accept at year end. That means one of Quickbooks or Simply Accounting.

Re:Linux - Not Even Close

[macs4all]

Quickbooks is the one thing that keeps Windows on my machine, and is the only reason I ever boot into it.

I tried hard to beat WINE into running it, but alas no luck - at least the version I run.

I looked at what's out there in Linux accounting software, and either it was really obscure, apparently abandoned, or aimed at mega-corps, not small and home businesses. Plus none of it offered an easy way to handle Canadian tax frameworks.

How about PostBooks? Runs on Macs and Linux (and even Windows). And since xTuple is based in Canada, I'm pretty sure they understand Canadian Tax Laws. And if you outgrow it, you can move up to the full-blown (non-free) xTuple ERP system.

Breakage

[Anonymous Coward]

As someone who tried to use their Quicktax (web) product earlier this year, and managed to break it to a point where it wouldn't continue, I wound up using a competitors product for this year.

I don't think Intuit is necessarily bad, but their attempts to limit a product artificially so they have several different SKU's seems, for me, is resulting in lost sales as the limitations are being turned on/off at the "each key entry" level instead of "at the purchase" level. This is not exactly a product that people are going to pirate since it has their identification tied to it legally.

Rather they should only turn off features that "print" those pages rather than trying to prevent entry of those pages. Like for example I tried to enter about 100 lines about stock trading, but this is only available to the most expensive tier, I okayed "upgrading" to this, but for some reason it was this action that killed the web version, and I was forced to go back to square one with a competitors product.

So IMO, if quicken and quickbooks are managed the same way, I think they're losing sales with trying to upsale at key entry instead of at print. It may make more sense to turn off the features at key entry to avoid wasting time, but you're actually making the user go "well if this product is so limited, let's see what limits are out there"

This is a good example of where an Open Source product could probably replace proprietary software, since the market leader's software is such a poor performing bloated pig.

Still, I don't think intuit's products are intentionally bad, but rather their licencing model is making it feel like their software is bloated at best and broken at worst. Software should be using "plugin" models where additional features in other licence levels can simply not be initialized instead of initializing the entire product and checking at every key entry to see if the licence allows that feature.

Re:Bah.

[WiiVault]

Mac user or not Quicken like Intuit is a joke of a "pro" software company. When Symantec looks to hire people who can pack more useless lines of CPU hogging code they must hire from these guys. How this company has kept it's niche is beyond me.

this is exactly what not to do.

[Anonymous Coward]

monolithic code bases are in the top 3 three killers organization productivity. don't confuse the success of the company with bad practices.

What about Intuit Profile?

[zivan56]

They don't mention Profile anywhere, which is even more horrible than Quickbooks. Last time I had to support it I remember downloading dozens of VB runtime files...

You can survive

[symbolset]

Quicken and Quickbooks is the only application I know of to have survived a full-on Microsoft assault on their business. Microsoft Money has folded. It's something to be proud of, I guess - for now.

Re:You can survive

[GodfatherofSoul]

I thought Money was a better product.

Re:You can survive

[symbolset]

There are lots of folks who thought their Microsoft product was better for a while. But when it doesn't suit Microsoft's strategic goals to maintain it it's dropped like a hot rock. When that day comes it doesn't matter how much you liked it, nor how much you had invested. They have no care for the preservation of your data either - they made it incompatible on purpose, and you should have known better is their view.

Whether or not you can be made to know better before putting your data into their products is a whole other question. How intellectually disabled are you? Obviously you can read and write, but are you impaired by some sort of memory loss?

Re:You can survive

[Anonymous Coward]

Way better, unfortunately. Now that Money is gone, I'm using Quicken, but it's pretty awful.

Re:You can survive

[cold fjord]

Quicken and Quickbooks is the only application I know of to have survived a full-on Microsoft assault on their business. Microsoft Money has folded. It's something to be proud of, I guess - for now.

Detailed here: Inside Intuit: How the Makers of Quicken Beat Microsoft and Revolutionized an Entire Industry

Re:You can survive

[unk98]

I agree, and I still use the sunset version. Mainly for the money flow graph that details your future finances. I have tried Quicken a few times and still find the old Money version simpler and cleaner to use.

Re:You can survive

[TemporalBeing]

Quicken and Quickbooks is the only application I know of to have survived a full-on Microsoft assault on their business. Microsoft Money has folded. It's something to be proud of, I guess - for now.

So have PeachTree and a number of other solutions. Good to see Microsoft Money gone; it what pure shiite.

Maybe the small business standard...but

[lilfields]

Quickbooks maybe the industry standard, but it's also a giant jumbled up mess. Our company's quickbooks were down all day due to corrupted files leading to unsequenced invoices. I've never meet someone really happy with Quickbooks...it's just accounting software is really hard to develop, so it doesn't have many strong competitors.

Re:Maybe the small business standard...but

[CodeBuster]

it's just accounting software is really hard to develop, so it doesn't have many strong competitors.

Not only that but accountants (aka bean counters) are notorious for being cheap as hell. Almost none of them would be willing to pay the likely unit price of a really good small business accounting system. Indeed, I wonder what the piracy rate on QuickBooks is? I'll bet that it's probably pretty high.

Re:Maybe the small business standard...but

[DigiShaman]

This!

I support Quickbooks as a consultant/sysadmin for SMBs. One of my biggest gripes about QB is that if the client PCs arn't configured correctly, it will attempt to take over the role of sharing out the file while the actual file is still on the server. And it's compounded by the fact Windows XP doesn't route data over the ethernet as a priority over WiFi connection. It can get ugly in the office real quick over "who has the file open". The proper way is to install over the server side hosting agent on the server, and clients arn't configured to host. Although some users get confused over the concept of "hosting" vs "multi-user mode". Bah!!! Curses!

The other major problem is that Quickbooks accounting administrators are not performing backups. Sure, Windows Backup or Backup Exec may be capturing the file. But that's not the same thing. The transaction log will not flush until after Quickbooks itself is allowed to perform a full backup with verification. Sometimes if you wait too long, the entire damn thing gets corrupted. In fact, one of my clients is facing this very problem. She wants to upgrade to the latest version of QB. But until the data can be repaired (if possible) via special services at Intuit, she has no safe way of converting the file without it either bombing out or causing even more corruption.

Re:Maybe the small business standard...but

[zaphod777]

As an IT person who deals with a lot of small companies this is what I hate most about QB. I don't really care how much the user interface sucks but why not put the data into a SQL database?!? Anytime someone mentions a QB problem I shutter. In Japan they have a piece of software called yayoi hanbai instead of QB which actually uses an SQL backend and even though the interface is all in Japanese migrations are a breeze.

Re:Maybe the small business standard...but

[macs4all]

This!

I support Quickbooks as a consultant/sysadmin for SMBs. One of my biggest gripes about QB is that if the client PCs arn't configured correctly, it will attempt to take over the role of sharing out the file while the actual file is still on the server. And it's compounded by the fact Windows XP doesn't route data over the ethernet as a priority over WiFi connection. It can get ugly in the office real quick over "who has the file open". The proper way is to install over the server side hosting agent on the server, and clients arn't configured to host. Although some users get confused over the concept of "hosting" vs "multi-user mode". Bah!!! Curses!

The other major problem is that Quickbooks accounting administrators are not performing backups. Sure, Windows Backup or Backup Exec may be capturing the file. But that's not the same thing. The transaction log will not flush until after Quickbooks itself is allowed to perform a full backup with verification. Sometimes if you wait too long, the entire damn thing gets corrupted. In fact, one of my clients is facing this very problem. She wants to upgrade to the latest version of QB. But until the data can be repaired (if possible) via special services at Intuit, she has no safe way of converting the file without it either bombing out or causing even more corruption.

Poor excuses for poorly-written software. Period.

Re:Maybe the small business standard...but

[Vintermann]

I don't really care how much the user interface sucks but why not put the data into a SQL database?!?

Because the program was started in 1992, and it's now 11 million lines of code. Think it's well documented? Think it got unit tests? Think it's got a nice, clean interface through which all database calls are made? Then you're not working in with SMB software :)

I've seen secondhand the amount of work it takes on a comparable application (Mamut, started in 1995, switched to SQL by version 11 some years ago). I understand why Intuit wants to avoid this, especially when making profit in the billions.

Re:Maybe the small business standard...but

[MacGyver2210]

I've never meet someone really happy with Quickbooks...it's just accounting software is really boring to develop

FTFY.

I like to think I didn't go to school for computer science to write an over-sized calculator, and I'm not sure my mind could handle days and days and days of just programming math algorithms.

Re:Maybe the small business standard...but

[ixidor]

had level 2 QB support tell me that if a user is hosting, it can mess wit the sharing from the server for the rest of the lan. wrote a quick-n-dirty PS script to look for qb hosting on the clients. mind you, it is not as easy as turning off the service on the machines, have to do it from quickbooks on their pc. this spits out who has hosting on, no responce == good. save below into a file with .ps1 extension. and make sure you have "Set-ExecutionPolicy RemoteSigned" $Servers = @("pcname1","pcname2l","pcname3", "pcname5","pcname6") for ($i = 0; $i -le $Servers.length -1; $i++){ $qbService = Get-Service -Name QuickBooksD* -ComputerName $Servers[$i] | where { $_.status -eq 'running' } if ($null -ne $qbService){ write-Host $Servers[$i] echo $qbService}

Re:Maybe the small business standard...but

[DaveGod]

QB often just can't update older versions. If you're going from 2006 to 2012 you probably need to first update it to 2008. Also, it needs to be an admin account doing it.

If either of those things are a problem, the QB error message usually does not offer any clues. If you have a private accountant they probably have all versions and can do it for you very quickly.

And yeah, take a backup from the old QB, install the new QB then load the backup. Usually works better than trying to upgrade the currently installed software + data at the same time. It also does not overwrite the old version so you should be fine to carry on with the old version if the upgrade doesn't work.

If all else fails, wait until the year-end, take the printouts from the old QB and start afresh on the new QB.

^ UK version, YMMV

Re:Maybe the small business standard...but

[terrahertz]

I support Quickbooks as a consultant/sysadmin for SMBs.

I have felt your pain. Which is why I wanted to respond when I noticed this part...

And it's compounded by the fact Windows XP doesn't route data over the ethernet as a priority over WiFi connection.

Check out the first set of instructions in http://support.microsoft.com/kb/894564 which should let you set a wired connection to a higher priority than a wireless.

By not fixing code that sucks?

[bhlowe]

I've had some simply horrendous user experience problems with Quickbooks that have persisted release after release.. I imagine the real question is how do they manage feature requests from 100M customers.. Do they simply make it difficult for developers to fix obviously wonky UI?

Re:By not fixing code that sucks?

[Anonymous Coward]

A small business I know of uses Quickbooks. I have to call them at least three times each year because they can never properly print and mail their annual invoice to me. Going on four years in a row fail this year.

My impression interviewing with Intuit was that a format interview with more than one person asking the same question, and asking me if I was from the city they were in, along with silly mind games like make the phone call, leave the room, and see if I could handle the call on my own.

Re:By not fixing code that sucks?

[datavirtue]

You have to pay to make feature requests. Seriously. We used to pay for this privilege.

Code quality vs language used.

[Anonymous Coward]

I wonder if the language used influences code quality?

Bad breed

[Anonymous Coward]

Speaking as an accountant, i.e. the poor fucker who has to use Quickbooks, Quickbooks is a goddamn mess. It's constantly crashing or messing up for some reason or another. Version upgrades are like pulling teeth and its interface is terribly organized. The worse part? It's the best of a truly bad breed.

Hope they handle their code better than customers

[dotancohen]

The last time that I tried to contact Intuit about Quicken on Linux was a mess:
http://dotancohen.com/eng/quicken_on_linux.html

I certainly hope that they handle their code better than they handle their customers.

Re:Bah.

[DogDude]

Quickbooks and Quicken are similar only in that they are owned by the same company. They are not related in any other way. It sounds like you're giving too much weight to the "Quick" part of the names.

No offense, but that doesn't sound like a lot

[GoodNewsJimDotCom]

As a solo developer, working 800 hours, I was able to write ~400,000 lines of debugged and play tested code. So 10 million lines doesn't sound like a lot at all to me. The only thing I experienced in writing so many lines of code is that I found a problem with the Eclipse editor. Once a single file starts going over 30k lines of code, there is type lag. The more code, the more type lag until you can no longer use Eclipse to edit that file, you gotta use Notepad.exe or Scite.exe.

Link here in case you want to play the game I wrote

Just out of idle curiosity: I wonder how many lines some of the bigger projects out there have. For example, how many lines of code do some of the Linux OS Kernels have? I'm curious because is 10 million lines actually a really large code base, because it doesn't sound it.

Re:No offense, but that doesn't sound like a lot

[godrik]

Just as a curiosity, why do you have a single file of more than 30K lines? Isn't that way over the top?

Re:No offense, but that doesn't sound like a lot

[cecom]

Yeah, right, you wrote, debugged and tested 500 lines per hour for 800 hours... We believe you. Now take your pills, your straitjacket, go back to your room and let the adults talk.

Re:No offense, but that doesn't sound like a lot

[CodeBuster]

Just as a curiosity, why do you have a single file of more than 30K lines? Isn't that way over the top?

Not if the entire program is one enormous switch statement in the main() function.

Re:No offense, but that doesn't sound like a lot

[Prof.Phreak]

Managing your own code vs managing 10m of code someone else wrote are very different. Even the most stupidly trivial functionality can take forever to figure out in someone else's code.

There's also code densitity... I once single handedly `wrote' 250k lines of code in an evening... by writing a generator against Rational Rose files... Draw a box with a name and some attributes, and bam... you got a dozen files of about 10k total lines (ddl, store procs, database helpers, value objects, corba stubs/skeletons, list view gui, detail view gui, edit view guil, all that crap). I seriously doubt any significant portion of that intuit 10m code base is anything other than boilerplate code... but who knows... perhaps 2/3rds of the code base are setter/getter methods generated from some metadata :-D

Re:No offense, but that doesn't sound like a lot

[antifoidulus]

Most languages allow you to use multiple lines to define literals(some even allow multi-line statements), so maybe he just used a line per character? Something like:

#include

int main(int argc, char** args) {

char *msg= "T"
"h"
"i"
"s"
" "
"i"
"s"
" "
"a"
"n"
"n"
"o"
"y"
"i"
"n"
"g"
;

printf("%s\n",msg);

return 0;

}
Theres 29 lines right there, and it didnt take a lot of time to code or debug :P

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

Not if the entire program is one enormous switch statement in the main() function.

Heheheh. You're fired...just as soon as we figure out what the heck that function does!

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

You wrote 500 debugged and tested lines of code per hour?? I call Bullshit on that one, that is a good 500% higher rate than the generally acknowledged DAILY rate of what a good developer can produce in tested code or 4000% higher than the hourly rate.

Re:No offense, but that doesn't sound like a lot

[GoodNewsJimDotCom]

You're right that reading other people's code is a vastly different thing. I guess 10 million lines starts to be a challenge in that regard as different people are writing different parts.

The code I write is in such a hyper agile methodology that I use shorter variable names for disposable variables just in order that I don't have to type a long name out. If I would just slow things down a bit, I could make my code more readable to other people, but I never planned on anyone else besides myself using my code.

I guess there are best practices for managing any amount of code. I guess it couldn't hurt for me to read up on how people do it different ways. Up until now I've always felt that programming styles was like a kungfu style. There are best practices for certain styles, but you can have a radically different style from other people. Then you get to the point where you're just arguing who's kungfu is better to go with. So since industry standard really puts the breaks on my speed of development, I just put my hands on my ears and didn't want to hear about it for a while.

I think though since I've never worked on a big collaboration project where my code needs to be readable to other programmers, I could use a dose of industry standard in this situation. I think I'm going to read the article now. At first I was too focused on thinking 10 million lines of code doesn't sound like a lot, but you brought to light the fact that if you don't write all the code yourself, it gets difficult to read let alone manage.

Re:No offense, but that doesn't sound like a lot

[GoodNewsJimDotCom]

I wasn't trying to brag or anything. I just rough estimated from memory at first. I'm guilty of doing the order of magnitude physics estimation for a lot of my math. I did a more accurate count up my map editor and Shell, looks to be around 80k-100k lines of code. I thought it was more because for some reason I thought by memory, my one file had 120k lines to it. So at low estimates, I guess I wrote, debugged, and tested 100 lines per hour for 800 hours. Is that a good rate? I know my manager says I code more efficiently in 14 hours a week than the four of his old coders did in 40 hours. I don't have much experience working with others to compare myself, no one ever wants to hire me.

I admit that I have a problem with low motivation to be an entrepreneur with no one ever hiring me from a job even though I graduated from Carnegie Mellon(not fun to graduate right after DotCom bust). Its hard for me to clock more than a couple hours each day without getting paid until the next year. If I was getting paid a normal paycheck I could put in the 8 hours a day. I'm working on discipline now to code more each day.

My large amounts of off time away from office contributes greatly to my problem solving and coding aptitude. I wonder if I can keep up my productivity if I do start clocking 8 hour days.

Re:No offense, but that doesn't sound like a lot

[rgbrenner]

you're guessing at the number of lines? too lazy to run sloccount? It's in the packages repository on a lot of distros.

Re:No offense, but that doesn't sound like a lot

[PmanAce]

If your one file has 120k lines to it it screams bad design and discipline. Either you don't know how to design objects, use design patterns and/or refactor code.

Re:No offense, but that doesn't sound like a lot

[phantomfive]

my one file had 120k lines to it. So at low estimates, I guess I wrote, debugged, and tested 100 lines per hour for 800 hours. Is that a good rate? I know my manager says I code more efficiently in 14 hours a week than the four of his old coders did in 40 hours. I don't have much experience working with others to compare myself, no one ever wants to hire me.

That's not why no one wants to hire you. The reason no one wants to hire you is because you write 120k line files. You suck at programming, no one wants to read that crap. Industry standard tends to be around 1,000 lines per file in C code, and 500 lines per file in Java. I am 99% certain your poor habits show up in your interviews. Learn to write readable code.

I will tell you though, I would LOVE to give you a job interview, because I you would surely do something entertaining that I would tell stories about long after.

Incidentally, 100 lines per hour is a fine rate, so you don't have any problem there. Consider dropping it down to 30 lines an hour and spending the extra time thinking how you can organize your code more readably.

Re:No offense, but that doesn't sound like a lot

[cheesybagel]

No you use Vim or Emacs. Notepad does not handle large files well. In fact old versions of Notepad did not even allow opening very large text files. You had to use Wordpad or something else. Or even better split your code into smaller files. Not only will you recompile the project faster when you do a minor change but if you name the files sensibly it will actually be easier to find what you want.

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

You sure talk a lot.

Re:No offense, but that doesn't sound like a lot

[Vintermann]

For some (low) value of "debugged and tested", and generous use of the cut and paste functionality of modern editors, this is quite possible.

Re:No offense, but that doesn't sound like a lot

[Vintermann]

Rather than practicing coding every day, you should practice coding with other people. You may be productive in your own way, but you simply won't learn to write code others can extend/maintain/work with the way you're doing now. It's like learning Russian from a textbook alone. You may think you understand the importance of clean, readable, DRY code, like you may think you understand Russian pronounciation, but you won't really until you need it.

Try to get into a small, agile-ish team, including a dedicated tester! The skills needed to see problems just aren't as compatible with the ones needed to see solutions as we might wish. Whatever you do, don't let yourself be confined to a "silo", responsible for your own code and nothing else. Then you'll become rich as an Intuit developer, and lose all pride in your work by 35.

Re:No offense, but that doesn't sound like a lot

[Vintermann]

I will tell you though, I would LOVE to give you a job interview, because I you would surely do something entertaining that I would tell stories about long after.

You bastard! I envy this kid. It's much easier to take an optimistic person and make them pessimistic (about how well they will understand their code in two years, about how well others can work with your code) than vice versa. We natural pessimists are only good for writing tests ;)

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

No problem, I bet the parent can offer consulting for mere $500/h.

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

The Linux kernel source's size in lines depends on the version, of course, but it is about 10 million lines of code (considering only the .c and .h files).

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

find, xargs, wc -l, grep.

Re:No offense, but that doesn't sound like a lot

[datavirtue]

I found a problem with the Eclipse editor. Once a single file starts going over 30k lines of code, there is type lag.

You are doing it wrong.

Re:No offense, but that doesn't sound like a lot

[datavirtue]

I was feeling kind of sheepish at 3000 LOC in an interface class.

Re:No offense, but that doesn't sound like a lot

[phantomfive]

Why do you envy him?

Re:No offense, but that doesn't sound like a lot

[Vintermann]

Because at some point, being aware that you're not writing good code comes in the way of being productive. He thinks he has problems with motivation, ha! I kind of mean it when I say I'm best at writing tests.

* I was good at correcting other people's programming homework.
* Back when I played around with topcoder I scored more points from finding subtle bugs in others' code (that the automatic tests missed) than my own solutions.
* I am good at helping colleagues figure out strange bugs.
* I am good at seeing potential problems.

But conversely, I have never completed a personal programming project on the scale of what GoodNewsJimDotCom (2244874) linked, either in time or code lines. My code sucks, or at least it seems that way to me, which dampens motivation. I get bogged down in rewrites (on my own projects), which kills most of them.

Actually, I'm convinced the world, and the business world in particular, needs negative people. Kinda like in Hindu mythology, you know? Brahma creates, Vishnu preserves, Shiva destroys. I guess I'm a "Shiva" sort of person. But it's a hard sell in job interviews.

Re:No offense, but that doesn't sound like a lot

[kat_skan]

Heheheh. You're fired...just as soon as we figure out what the heck that function does!

Well that's an easy one: EVERYTHING!

Re:No offense, but that doesn't sound like a lot

[phantomfive]

Oh yeah, over my time, I've noticed that the #1 trait of successful programmers (whether they are bad at programming or good is irrelevant, they still manage to make a career), is persistence. When they come on a problem, they keep working at it. Those who give up become QA.

No one writes perfect code, so don't worry about that. It's an art that all of us improve at every time we write code. But this code ranking system might be helpful. There are three things to consider in quality of code:

1) Does the code work? (if it doesn't do what you want, nothing else matters).
2) Is the code readable?
3) Is the code flexible?

Most programmers are still working on #1. If you can get #2, then you are easily in the top 10% of programmers. So have confidence in yourself.

Re:No offense, but that doesn't sound like a lot

[rgbrenner]

sloccount will give you the same count, even if you use completely different formatting.

Re:No offense, but that doesn't sound like a lot

[Anonymous Coward]

That's no joke. I worked on some code Samsung had in it's UI for phones it was selling in 2004. (D500/D600) There was a switch statement that exceeded 28k lines in one file. It swtiched on a variable (uimode) and several thousand lines later switched on the same variable again still in the orginial block.

switch (uimode){
case 0: ....
thousands of lines later
    switch (keypress) {
    case '0': .....
thousands of lines later
      case 'enter':
          switch(uimode) {
          case 0:

It hurt trying to make sense of what was happening. Oh and all the variables were global.

I can laugh about this now but at the time I cried a lot!

Re:Bah.

[stephanruby]

So this Quicken Essentials for Mac isn't the Quicken you wanted?

Re:Bah.

[Anonymous Coward]

Well, it could be an indication that this software management philosophy of "11 million lines of ancient C++ isn't a problem if you have the right attitude!" is shared.

Sounds like a lot

[Casandro]

Particularly considering it's just a "simple" tax programme.
It sounds like, instead of implementing the logic in data (i.e. arrays, external text files, etc) and having a fairly small compiler targeted at the problem, they implemented everything in C. This is something even C advocates advise against.

Re:Bah.

[shugah]

People who own Macs don't understand technical geeky things like numbers and are way too cool for accounting.

Code?

[Anonymous Coward]

Far easier to maintain a single properties file rather than millions of lines of code. Want to change the application then change the design and regenerate the whole application. Done this.

Re:Bah.

[gmhowell]

Given that they haven't managed to come out with a native version of Quicken for Mac in over 6 years, I suspect that they kept that code on a napkin... then lost the napkin.

They kept it on a floppy drive. They weren't sure how to access it when they got their new iMacs. They got someone to copy it to a CD, but that was at the same time their MacBook Airs showed up.

Intuit's software is a programmatic pile of crap

[Anonymous Coward]

Intuit's software uses like it's been written by some undergrad CS students. They make among the most disorganized software I have ever seen and what would never pass a competent professor's eye just crops up in their software.

Needing to restart every day so you can update the timestamp? Really?

I will complement their NON-techies on convincing so many banks across the nation to go on board with their software. That is a very impressive feat. But their techies have my ire.

Re:Bah.

[gmhowell]

People who own Macs don't understand technical geeky things like numbers and are way too cool for accounting.

Considering we overpay for everything and buy new iShinies every 3-6 months, I'd say keeping track of our finances is even more important for us than for you bottom feeding 99%ers and your 'PCs'.

Support is the other question...

[bradley13]

Maybe Intuit does feed their programmers well. Now if they would just hire some decent support people. We used to use a multi-currency version of QuickBooks, and the errors were simply astounding in their stupidity. As one, minor example: it was completely clear that some conversions were handled using floating point numbers, with the inevitable decimal rounding errors. At the end of the year, we had huge currency conversion errors - far beyond what even floating-point errors could explain - and essentially impossible to justify to the tax authorities.

There were lots of other problems as well. Trying to report errors was like talking to a black hole. The one time we really needed some real-time support, we spent ages on hold, or going around in circles with different people, and wound up getting no useful help at all. In the end, the only solution was to go back to a single-currency system, and deal with currency outside of QuickBooks.

Still, as bad as our experiences with QuickBooks have been, there's nothing better in the same price category.

Re:Bah.

[Spy Handler]

they wrote "about 8 million" lines of code to run a theme park on a little island back in the early 90's, so 10 million lines for Quickbooks 2012 seems reasonable.

How good can Intuit's code be...

[Anonymous Coward]

when the Windows and Mac versions of Quicken use different file formats and the conversion process between the two platforms has been fraught with errors forever?

Re:Bah.

[Anonymous Coward]

I briefly worked for Intuit. IIRC, their policy is to focus on Windows because they "... don't want to spread their resources to thin."

Re:Bah.

[macs4all]

Given that they haven't managed to come out with a native version of Quicken for Mac in over 6 years, I suspect that they kept that code on a napkin... then lost the napkin.

Pretty disgusting for (yet) a(nother) company who owes its success to the Apple ][.

For those of you too young to remember, Quicken started out as an Apple ][ ONLY checkbook program written in (of all things) Pascal.

Re:Bah.

[macs4all]

I briefly worked for Intuit. IIRC, their policy is to focus on Windows because they "... don't want to spread their resources to thin."

Yeah right. Like they can't afford to hire some Objective-C programmers.

As I said before, pretty disgusting for a company who owes its very EXISTENCE to Apple.

Re:Bah.

[macs4all]

How Intuit Manages 10 Million Lines of Code? Very carefully. Next question!

You meant "Not very well".

Re:Bah.

[JDG1980]

Yeah right. Like they can't afford to hire some Objective-C programmers. As I said before, pretty disgusting for a company who owes its very EXISTENCE to Apple.

It's absurd to say that they owe their very existence to Apple. Does everyone who develops software for Windows "owe their very existence" to Microsoft?

If they thought they could make a profit by porting their software to OSX, they probably would have done it. But large companies generally don't act for purely sentimental reasons.

Re:Bah.

[Bert64]

Does everyone who develops software for Windows "owe their very existence" to Microsoft?

Pretty much yes, MS can cut off their market whenever they want. That's what Valve don't like, and is one of the main reasons why they are making Mac and Linux versions of Steam and many of their games.

Only ten million lines?

[MichaelSmith]

What do they do with the rest of their time? Test it?

Re:Bah.

[TheSeatOfMyPants]

Pretty disgusting for (yet) a(nother) company who owes its success to the Apple ][.

Not really, given Jobs did all he could to undermine & destroy the Apple IIgs (Woz's creation) because it was outselling the unprofitable Macintosh (Jobs' baby), and decided that no more Apple II family systems would be released. If I was shoved violently into a ditch to give a less-worthy sibling the sole chance at survival, I sure as hell wouldn't protest if old friends of mine turned their back on said sibling the moment he ceased benefiting them in a huge way (and would likely cheer if they gave him the boot ahead of time).

Nyan Cat

[iLLucionist]

How many lines of code would it take them to implement Nyan Cat??

The Finite Monkey Theorem States:

[pinkushun]

A monkey hitting keys at random on a keyboard for a finite amount of time will almost surely code a 10 Million LOC program, such as the complete works of Intuit.

* adaptation of the Infinite monkey theorem

Re:The Finite Monkey Theorem States:

[Hillgiant]

Well, for a sufficiently large amount of finite, I suppose.

quickbooks

[crutchy]

is shit

Re:Bah.

[gtall]

Meds not working like they used to any longer? I know how you feel, try the little blue ones.

Re:Bah.

[RaceProUK]

Does everyone who develops software for Windows "owe their very existence" to Microsoft?

Pretty much yes, MS can cut off their market whenever they want.

Apple makes software for Windows. Does that mean Apple owes its existence to Microsoft?

10 million LOC? INBD

[140Mandak262Jamuna]

My small team is managing some 600K lines of code all C++, (no graphics no gui), which is a silly measure anyway. Source code for a typical engineering design analysis tool can easily top 10 million loc. And add to this material property libraries, model libraries, part libraries, abstracted behavioral model data, etc etc. These are not source code, but data files, with every number carefully verified ( for example: the coefficient of viscosity of hydraulic fluid brand XYZ at 250 degree c or the impact strength of ALCOA AL 75032 alloy at STP) And many companies own/develop/ship multiple products in diverse physics realms (thermal, fluids, electronics, mechanical, civil, electrical etc) with very little overlap.

So 10 million LOC? meh! seen that. INBD.

Re:Bah.

[hawkinspeter]

They probably do owe their continued existence to Microsoft since their 1997 deal ($150 million investment).

Re:Bah.

[gblackwo]

Nice Michael Crichton reference!

10 million lines

[Anonymous Coward]

And it still is a piece of shit.

Re:Bah.

[Anonymous Coward]

So this Quicken Essentials for Mac isn't the Quicken you wanted?

It doesn't even understand that a loan is made up of both interest and principle -- so, no, a product that can't track your finances if you've taken out a loan is NOT providing the "essentials" of financial management.

Even Intuit knows that which is why they started selling a kit to people who bought the 2007 version of Quicken continue to run it on current OS X versions.

From the looks of Quickbooks

[Anonymous Coward]

They arent managing those 10 million lines very well. QB is the bane of my IT existence.

Re:Bah.

[Lumpy]

Exactly, there area lot of better choices for real accounting software, QuickBooks is money for dummies. And my wife cringes when the new company she goes in to fix has quickbooks, She knows that it will be all screwed up. Quickbooks will let you fudge the books easily, and most "entrepreneurs" not only know nothing about book keeping and accounting, they are too cheap to hire one right off the bat to make sure everything is kosher. So my wife gets big $$$ to come in and fix their books and accounting system. Typically the "CEO" of the company hates it when told, "you are not in charge of any money decisions anymore, your accountant is. the4y can over rule you at any time. Get used to it."

They always choose Quickbooks because the crap can be bought off the shelf at Staples or other office supply place. It can be used as a decent accounting package, but it encourages the business owner to engage in bad or even illegal business practices.

Re:Bah.

[Anonymous Coward]

Did they use those Unix workstations that even a little girl can recognize?

Re:Bah.

[MacGyver2210]

No kidding! If it takes 10 million lines for QuickBooks, then it is probably stored in a .txt file using the decimal number ASCII representation of the letters in the code instead of the letter itself.

I have seen programs that do a hell of a lot more than that does (3D graphics, advanced audio processing, database software) written in fractions of that amount of code. Two million lines should pretty well top out any overcomplicated calculator program, unless it's written for the government. It sounds like they would be well suited by starting from scratch and re-writing it.

So in summary, their case study should be titled "How NOT to manage program code"

Re:Bah.

[AngryDeuce]

Does that mean Apple owes its existence to Microsoft?

I just felt a great disturbance in the Apple fandom, as if millions of fanboys suddenly cried out in terror and were suddenly silenced.

Re:Bah.

[Pope]

Not really, given Jobs did all he could to undermine & destroy the Apple IIgs (Woz's creation) because it was outselling the unprofitable Macintosh (Jobs' baby), and decided that no more Apple II family systems would be released.

You mean the IIgs that came out in September 1986, a year after Jobs left Apple? Man, you guys really don't even know the basic facts about Apple.

Should've used Python

[Anonymous Coward]

I don't know how many of those 10,000,000 lines are auto-generated. The project I'm working on now is in Java and I'm sure many hundred thousand lines came spewing out of the various toolkits with an "autogenerated - do not modify" comment at the top.

Of course if Intuit had used Python they still might have 500,000 LOC

Re:Should've used Python

[TheSkepticalOptimist]

Had they used Python, they would have been bankrupt by now.

Re:Bah.

[kestasjk]

MS can cut off their market whenever they want.

How?

Re:Hope they handle their code better than custome

[nitehawk214]

The last time that I tried to contact Intuit about Quicken on Linux was a mess:
http://dotancohen.com/eng/quicken_on_linux.html

I certainly hope that they handle their code better than they handle their customers.

So you filled out a crappy web form that makes you log in and got a reply within 2 hours from a large corporation with the correct answer without any lies or bullshit? That seems like perfectly acceptable customer service. That they did not give you the answer you wanted is inconsequential to the quality of customer service. Granted I don't believe for a second they actually ever intend to make a Linux version of their software, but they came right right out and admitted they have no plans.

Re:Bah.

[datavirtue]

No one has made a move into the niche. It is like Windows, Quickbooks is the dominate software and no other company thinks it is worth trying to penetrate. On CNET you can see reviews of their free bait offerings and they are not good--many, many rants. They are ripe for the picking; their software is bloated to hell, expensive, and the users hate it. It is very costly for a small business or start-up to purchase QB and there are no breaks or decent entry points. You pay the QB tax or you don't play, period. On top of this, there is nothing quick and easy about it, and out of the box it makes your company look amateurish.

It's simply a matter of scaling...

[Assmasher]

10 million lines of code doesn't need to be any more complex or confusing that 4 million lines of code, or 2 million lines of code, or 500,000 lines of code, et cetera.

Good organization, regression testing/QA, and DRACONIAN check-in rules make it possible.

I've never worked in 10 million lines of code before, but I've worked in 4 million line products (SoftImage/Microsoft.)

Everything was organized nicely, well written (for the most part), and most importantly - we had a very very rigid process for checking in that worked really well. We had 80 people working in the codebase - the subsection you worked on (i.e. "mentalray dag traversal" or "render farming") would have maybe 4 or 5 people working in it at any one time so although the codebase was huge (including active work in the DS framework XSi was based on) the scope of conflict was usually relatively small.

In the years I worked there I never saw the build break except when someone did not follow the check-in procedure. They brought out a really big hammer for times like that and hung the developer up like a pinata...

Re:Bah.

[datavirtue]

Agreed. As my Grandma says, "Quickbooks makes me money." She has owned a bookkeeping/tax business for 40 years. I grew up hating QB. Quicken was awesome in the DOS days.

Re:Bah.

[datavirtue]

Why did I capitalize "grandma?" We may never know.

Re:Bah.

[Stirling Newberry]

Your money is gone, and they quickly book the sale.

Re:Bah.

[Stirling Newberry]

The peace treaty is that MS will continue to make Office for Mac. The absence of it severely hurt apple in the enterprise market for years.

Re:Bah.

[Stirling Newberry]

db2 for zos maintains 72 character limits for lines of code.

Re:Not for public companies

[datavirtue]

Believe it or not, that is one of the main reasons for the software's success. One the most common questions I get about Nevitium is, "How do I delete an invoice?" I have to then explain accounting principles, legal issues, and possible customer service issues involved with allowing that functionality.

Paying By Lines Of Code

[assertation]

Ever read "Les Miserabes" or "War And Peace"? Ever notice that many 19th century novels are HUGE?

That is because they paid by word.

It would be interesting to see what would happen if a company experimented with metrics for and paying by:

- the fewest lines of code for a given task
- speed
- useful error messages
- ease of maintenance
- fewest memory leaks, least memory usage

Re:Bah.

[DrXym]

If only it were a matter of hiring some obj-c programmers. I'd like to see your mental state after have 10 million lines of shit dumped on you with with non-trivial task of porting it to a completely disparate operating system and then maintaining both systems annually. I've ported a large amount of ERP code from OS/2 to Win32 during a 30 day crunch and I was ready to kill somebody by the end of it. I expect porting Quickbooks or Quicken would be close to an 18 month job and would involve 20-30 engineers plus 20 QA staff plus project managers etc at least.

No surprise as to why Intuit sucks

[RogueWarrior65]

10 million? For an accounting app? Seriously? Something seriously wrong here. Of course this is no surprise when you're asking why the Mac versions have no feature parity to the Windows versions. This is no surprise that the most obvious of features e.g. a real bill-of-materials feature for QB Manufacturing edition continues to elude us. Maybe they're writing the thing in native assembly language.

No good competitors?

[King_TJ]

From what I've seen, you also have the issues where real CPAs prefer software to "speak their own language", while most small to medium size business owners just want a solution they can use every day without too much hassle, and can hand the data off to the accountant at tax time every year.

I work at a company who standardized on ACCPAC accounting software back when it was a DOS based program. These days, it's a huge, bloated, slow Windows-based part of a Sage ERP solution - but we still use it.

It's clearly far more powerful and flexible than Quickbooks, but at the same time, less user-friendly and a much bigger financial commitment to license properly.

After all these years, it seems accounting packages still wind up in one of two categories: easy to use, friendly packages with very limited expandability, and huge,complex packages that ONLY accounting majors really understand how to use properly.

In the more user-friendly, less costly, and easy for non-accountants to use category, you've got programs like MYOB and Quickbooks, but not a whole lot else....

Re:Bah.

[XxtraLarGe]

Well they did finally re-compile Mac Quicken 2007 for x86 (only $15! to upgrade) so I guess they found the napkin. After a year of searching for it.

It's not an upgrade for $15, it is a stand-alone product that's Mac OS X Lion compatible, no previous version required. You can get the direct download for only $15. I opted for this instead of dumping $50 on Quicken Essentials which from all accounts is inferior in every way. After I upgraded to Mountain Lion this weekend, it was the first app I launched, and I was promptly greeted with an update notification to improve Quicken 2007 performance for Mountain Lion.

Re:Bah.

[The Askylist]

It doesn't even understand that a loan is made up of both interest and principle

That'd be principal. But hey, English isn't needed for accounts, is it?

Re:Bah.

[XxtraLarGe]

For those of you too young to remember, Quicken started out as an Apple ][ ONLY checkbook program written in (of all things) Pascal.

For some reason, I thought Quicken started life as a HyperCard stack.

10M lines is not a large codebase

[swillden]

It's a respectable size, of course, and one that requires a intelligent management, but in 2012 it isn't a large codebase.

Linux 3.5 comprises 10,389,941 lines of code (per sloccount), and that's just a kernel + drivers + architecture dependent files. I'm sure Windows is at least 50M LOC, and it wouldn't surprise me at all if it tops 100M. I work for Google, and while I'm not sure I can say how much code we have, it's far, far more than 10M lines. I used to do a lot of work with major financial institutions, and I'd estimate that most of them have on the order of 100M LOC.

I'm sure Intuit does some useful things that would be interesting to learn about, but I don't think I'd consider them a case study in how to manage a large codebase. They don't have a large codebase. I suppose they have a large codebase for a small to medium-sized software company, but many enterprises and large software companies manage much more code.

Re:Bah.

[Sebastopol]

What's the alternative? And don't give me some unix freeware crap, I've tried several, they are crap. Microsoft Money was the only viable alternative, but the conversion process sucked ass. I have 18 years of quicken data that I'm not about to lose, and until there's a real alternative for consumers (i.e., $100 price point), I'm not leaving, regardless of the weird interface, and periodic interface bugs. At least the database is rock solid. (runs to knock on some wood)

Please tell me more

[Gazzonyx]

Could you point me to those registry changes? I've been fighting with Sickbooks to get limited users (read: users, not super users or admins) to run Quickbooks. I used the settings that Intuit specified, but no go. Then I created a domain group "quickbooks users" and gave them full ownership of all the folders and registry keys that they should need. No joy. Now all "quickbooks users" are super users on their local machine.

Still won't allow them to do the update that it bugs the users about ever couple of weeks when they decide to push a new release that doesn't fix anything you need and breaks more stuff you do need. The installer fails citing that the user isn't an admin (why not check this before you nag them?). It doesn't check the permissions, it just fails when it does the GID check.

Quickbooks is the only software I've ever seen that makes you trash your box just to get it to mostly run. Bonus points for it insisting on installing an old version of Flash. I've been dealing with this stuff since the 2005 or 2003 version. It's maddening and I want to switch to XTuple Postbooks ( xtuple.com). It's open source and runs on Windows, Mac and Linux ( source forge page). Unfortunately, no one is going to want to make that switch since they know Quickbooks.

Re:Please tell me more

[afidel]

Sorry, that was 6-7 years ago and a quick Google search doesn't bring up the actual settings (probably Intuit removed the forum where I posted my results).

Re:Hope they handle their code better than custome

[cultiv8]

Up until 2010 they didn't even support Linux for their web-based "online" version of the software, you had to spoof the user agent.

Re:Bah.

[Xibby]

There are no shortage of smaller developers creating Quicken alternatives for Mac. iBank, Cashculator, and CheckBook Pro for example. I've settled on Mint.com myself after using GNUCase, Microsoft Money, Quicken, and iBank. Mint.com isn't for everyone, but after changing how I was managing money I feel it works better than other products for me. Bank Simple also looks interesting for anyone who is currently not satisfied with their bank.

It depends

[Anonymous Coward]

If the task really requires that much code, and you manage it successfully, it is something to brag about.

I'd be surprised if they add code just to add it. While I suspect there is bloat and code they are too scared to re-factor away, this is probably a very large sophisticated code base, and they apparently manage it.

I yearn for the day

[aoism]

When people stop using lines of code as any sort of useful quantification of application worthiness or personal skill level. When I hear someone mention how many lines of code their application is, my first thought is that there is a whole lot of fat that needs to be trimmed -- or that they are terrible, inefficient programmers. It's about having nothing left to take away, not adding more to the pile.

Customer shafting

[johnpagenola]

How many lines of code are in QuickBooks for customer shafting purposes? Every year there is a trivially different new version of the program with a completely different file format, so a file created in QBn cannot be read by QB.lt.n. Also, when QBn reads a file from QB.lt.n, it converts the file to the QBn format; thus any changes made using the new version of QB cannot be used by the older version. Nice. Another touch is that the payroll updates only work for 3 years, so a company using the payroll feature has to buy, install, test and train a new version of the program, with the related hassles, for no benefit except the incremental revenue to Intuit. If they would have their data files in a defined, consistent, published SQL format, they could cut the code dramatically. This would also allow for report-writing to be separated from the transaction processing instead of the current monolithic mess. These guys make Microsoft look nice.

QuickBooks is available on multiple platforms???

[Anonymous Coward]

What product other than their Enterprise server runs natively on Linux?

I don't consider WinXP, Vista, etc. to be "multiple platforms", just different version of the same platform.

Re:Bah.

[clodney]

No kidding! If it takes 10 million lines for QuickBooks, then it is probably stored in a .txt file using the decimal number ASCII representation of the letters in the code instead of the letter itself.

...

So in summary, their case study should be titled "How NOT to manage program code"

The article is actually very interesting. It is not trying to justify the size of the code base, it is discussing the mechanisms they use to make a code base of that size manageable. I've never tried to manage anything bigger than 750KLOC, but even at that size build times and broken builds were a constant problem. So talking about the techniques that let people productively work on a code base 13x that size is interesting.

Intuit is a dead-end accounting standard

[Anonymous Coward]

Accounting software is like modes of transportation. Before the engine was invented, more horses were added to pull a heavier weight and it was the standard until engineers invented the engine. Intuit made old paper concepts electronic rather than understanding the true options provided by being able to change text on the screen... :)

Outside of bugs and unhappy software engineers whom I know personally that work 50 hours+, how can Intuit not grasp that most small businesses operate on a seasonal pattern?... If you are an executive or product owner from Intuit and reading this, you have 2-3 years to get the concept in there before I personally will make Quicken obsolete as a business concept.

Re:Bah.

[russotto]

Supposedly they didn't even do that; they licensed a version of Rosetta from Apple sufficient to run their old version.

Re:Bah.

[Anonymous Coward]

Actually yeah they kind of do. Without the $150 million, Apple would likely be bankrupt long ago.

Re:Hope they handle their code better than custome

[dotancohen]

So you filled out a crappy web form that makes you log in and got a reply within 2 hours from a large corporation with the correct answer without any lies or bullshit? That seems like perfectly acceptable customer service. That they did not give you the answer you wanted is inconsequential to the quality of customer service. Granted I don't believe for a second they actually ever intend to make a Linux version of their software, but they came right right out and admitted they have no plans.

I am not complaining about the answer, it is quite what I expected. I am complaining about the process that one must go through to contact a sales rep.

Re:Hope they handle their code better than custome

[dotancohen]

Up until 2010 they didn't even support Linux for their web-based "online" version of the software, you had to spoof the user agent.

If spoofing the UA worked, then they weren't "not supporting Linux" but rather "actively blocking Linux".

Re:Bah.

[ronabop]

MSDOS was a lousy product... MS didn't start raking in cash until they made Word, and Excel, on the only desktop GUI that existed at the time... MacOS.
In short, MS owes it's existence to Apple.

Re:Bah.

[RaceProUK]

Of course. Nothing to do with shafting IBM over PC-DOS and OS/2. Nor nothing to do with backroom deals with PC manufacturers.