4 ms·

I have seen some of this code (worked at Intuit briefly) and it is some of the most horrible Java (for web products) and C++ (desktop apps) code I have seen in

I have seen some of this code (worked at Intuit briefly) and it is some of the most horrible Java (for web products) and C++ (desktop apps) code I have seen in my life. Admittedly this was a few years ago, but I've never ever seen such convoluted code anywhere, with (literally) thousands of cut and pasted fragments and poke-your-eyes-out code. You could look at a fragment of code and discover >1 in error every other line. I once asked my boss to select a random file of code from one of the flagship products and discovered 40 errors in 5 minutes (he was not happy, long story). It is a wonder these apps work as well as they do. At the time they had this weird home brew mix of PSP and "agile" as their 'methodology' and while it generated a lot of meetings and paperwork, it didn't improve the code one bit. I am glad to know that they are moving towards better practices, but Intuit is the most technically inept organization I've seen, so I wouldn't be too hopeful of the end results. OTOH they do understand their customers (and marketing to them) really really well. I learned a lot from Intuit about these aspects of product dev. Which goes to prove you can make billions with totally screwed up engineering.

edwinnathaniel 14y ago
There's no way 10M LoC can be improved without taking a loss in the balance sheet. No Way. Because in order to do that, you need to stop writing new code effectively and just heads down and improve things. The thing is, if the codebase is tightly coupled, you've got tons of work to do as typically you can't improve one thing without changing the other. In the absence of unit-testing, nobody has the guts to refactor the code without high-risk of breaking the product. I haven't even mentioned the cultural (human) issues that need to be fixed/changed as well. So people truck forward, like in any software development shops :). Speaking of which, thanks for sharing your insight working for Intuit. The article never mentioned the actual quality of code, but instead focusing on things that he improved :) (not a small feat, but probably don't improve the quality of the code).
- anthonyb 14y ago
  The cultural issues are usually the largest issue (qv. Conway's Law). You don't need to stop writing new code, but you do need to stop adding crap code (or at least stop adding it faster than you can clean it up). It's why I'm a big fan of code ownership as a negative reinforcement tool. Despite it being a really bad idea, it does tend to rein in the cowboys - because they're too busy fixing the bugs in their code to add new ones.
- nahname 14y ago
  Absolutely they have to take a loss to fix it, but they are already suffering from a massive lose to software engineering productivity and are unlikely to retain any talent. This is technical debt at it worst.
- deleted 14y ago
  [deleted]

edwinnathaniel 14y ago

There's no way 10M LoC can be improved without taking a loss in the balance sheet. No Way. Because in order to do that, you need to stop writing new code effectively and just heads down and improve things. The thing is, if the codebase is tightly coupled, you've got tons of work to do as typically you can't improve one thing without changing the other. In the absence of unit-testing, nobody has the guts to refactor the code without high-risk of breaking the product. I haven't even mentioned the cultural (human) issues that need to be fixed/changed as well. So people truck forward, like in any software development shops :). Speaking of which, thanks for sharing your insight working for Intuit. The article never mentioned the actual quality of code, but instead focusing on things that he improved :) (not a small feat, but probably don't improve the quality of the code).

anthonyb 14y ago
The cultural issues are usually the largest issue (qv. Conway's Law). You don't need to stop writing new code, but you do need to stop adding crap code (or at least stop adding it faster than you can clean it up). It's why I'm a big fan of code ownership as a negative reinforcement tool. Despite it being a really bad idea, it does tend to rein in the cowboys - because they're too busy fixing the bugs in their code to add new ones.
nahname 14y ago
Absolutely they have to take a loss to fix it, but they are already suffering from a massive lose to software engineering productivity and are unlikely to retain any talent. This is technical debt at it worst.
deleted 14y ago
[deleted]