Oh god you poor man. We took a look at using SMB Ledger (the parent of LedgerSMB) years back and after peeling back the covers it just looked horrific both from a security and general code quality perspective. This was around the time of the fork, and I couldn't help feel that SMB Ledger had it's work cut out. Hopefully you guys have been able to get through to the other side.
1) Going to a db-centric security model has allowed us not to trust the SQL-Ledger code (good thing too).
2) We are refactoring/removing SQL-Ledger code as quickly as possible. As of 1.3 this means payment logic, reconciliation logic, contact management logic and more. 1.4 will hopefully rip out and replace all search and reporting functions. It will take us a few more years to get the codebase where we want it though.
3) The bad thing about bad code is that bad code is contagious. When you spend a lot of your time debugging bad code it is very hard to write good code. Most of what we wrote for 1.3 will need to be rewritten again. I am pretty happy with the code we are writing for 1.4.....
I think we have come through the worst of it. Pace of development is speeding up which is a good sign and much more of the application is subjected to unit tests.
As a side note, when we first added unit tests to the number rounding tests for the code we inherited from SQL-Ledger, there were failures. We replaced that logic very quickly.
Yeah, it was pretty bad... Now its getting better.
Edit: Also it seems to me the worst never seems so bad when you are in it. I don't think that I could see how many problems we had from this until I am here, half way from 1.3 to 1.4, asking why 1.3 took five years to release (we beat Perl 6 and HURD though, I guess Duke Nukem Forever in fact beat us date-wise by a couple months).
Looking back at the customers of mine who have had problems, or projects that went way over budget or took too long because of difficulties here, I can see how much that hurt us. At the time though, it was just one of those keep working on it kind of things.
Comments
Oh god you poor man. We took a look at using SMB Ledger (the parent of LedgerSMB) years back and after peeling back the covers it just looked horrific both from a security and general code quality perspective. This was around the time of the fork, and I couldn't help feel that SMB Ledger had it's work cut out. Hopefully you guys have been able to get through to the other side.
Well, here's the status so far.
1) Going to a db-centric security model has allowed us not to trust the SQL-Ledger code (good thing too).
2) We are refactoring/removing SQL-Ledger code as quickly as possible. As of 1.3 this means payment logic, reconciliation logic, contact management logic and more. 1.4 will hopefully rip out and replace all search and reporting functions. It will take us a few more years to get the codebase where we want it though.
3) The bad thing about bad code is that bad code is contagious. When you spend a lot of your time debugging bad code it is very hard to write good code. Most of what we wrote for 1.3 will need to be rewritten again. I am pretty happy with the code we are writing for 1.4.....
I think we have come through the worst of it. Pace of development is speeding up which is a good sign and much more of the application is subjected to unit tests.
As a side note, when we first added unit tests to the number rounding tests for the code we inherited from SQL-Ledger, there were failures. We replaced that logic very quickly.
Yeah, it was pretty bad... Now its getting better.
Edit: Also it seems to me the worst never seems so bad when you are in it. I don't think that I could see how many problems we had from this until I am here, half way from 1.3 to 1.4, asking why 1.3 took five years to release (we beat Perl 6 and HURD though, I guess Duke Nukem Forever in fact beat us date-wise by a couple months).
Looking back at the customers of mine who have had problems, or projects that went way over budget or took too long because of difficulties here, I can see how much that hurt us. At the time though, it was just one of those keep working on it kind of things.