5 ms·

daily reminder > The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two mor

daily reminder > The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two more years' development. https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

flerchin 5y ago
Thanks for sharing. 9 hours to run payroll at its best. Wow.
- Jtsummers 5y ago
  Depending on the server or mainframe hardware it was being run on, databases, network connectivity, interactions with financial institutions, and potential physical activities (printing checks and such), 9 hours may not have been unreasonable in the 1990s. Digging around on C2: ChryslerPayroll (Essentially a batch app) db size: 2.5 - 4 GB server: Sun Enterprise 2000 4GB RAM interactive users: 5 So not exactly a beast by modern standards.
  - WJW 5y ago
    Still, according to wikipedia it paid around 9000 people. This would make it run at about 1k/people per hour or about 3.6 seconds per person. Now it's true that the complexity of payroll calculations is often underestimated but this seems slow even for 1993.
    - Jtsummers 5y ago
      Given disk speeds at the time, it seems the DB was residing on the box, I wouldn't be shocked by a speed like that on a single or even dual CPU machine. And that's assuming all necessary data was in residence on the machine when the batch job started, and no network connectivity was needed (like retrieving that period's time sheets from legacy COBOL systems or pushing out the results of a paycheck calculation to a legacy printing system). More on its design: The project is essentially a batch-processing system. When it is time to pay, it cycles over all employees, computing the pay due, and exporting results. There are about 15 main external export receivers and a half- dozen different input sources. There are around a hundred different input transactions. http://wiki.c2.com/?ChryslerPayroll http://wiki.c2.com/?ChryslerPayroll EDIT: http://wiki.c2.com/?WhyIsPayrollHard http://wiki.c2.com/?WhyIsPayrollHard Talks more about the scope of what was being done. 3000 calculations per employee, formatted and transmitted to various COBOL systems from the legacy payroll. 3.6 seconds isn't exactly stellar, but on hardware from the mid-1990s it's not obscene either. It's really hard to judge systems based just on a performance number without knowing details about the actual hardware and network configuration and the systems it communicates with. If I tell you I can sort 1000 item lists in 10 seconds, that sounds bad. But if I then tell you it's an 8-bit microcontroller running at 1kHz and getting data over a 300 baud modem, it suddenly sounds reasonable.
    - flerchin 5y ago
      1997
  - flerchin 5y ago
    The wikipedia article says that it paid 9k people. So 1k paychecks per hour. 3.6 seconds per paycheck. Agree that this would make sense if the limiting factor was the printer, but even so, parallelize the print job to multiple printers.
papandada 5y ago
Is the takeaway that Beck's approach doesn't work, that big things never work, or that nothing ever works?
- flerchin 5y ago
  I think the takeaway is that failure is always an option.
  - papandada 5y ago
    From my own experience, this is a good lesson. Refusing to "fail" is often based on my own stubbornness and defensiveness towards something that ends up working better. I've seen that in school, career, and relationships.
- deleted 5y ago
  [deleted]
mpweiher 5y ago
As-needed reminder: "In particular the entry in Wikipedia is misleading and incomplete, much of its comments seem to be based on a paper from a determined XP critic whose sources are unclear. Certainly its comments on performance are a misleading interpretation of material in my Refactoring book." -- https://www.martinfowler.com/bliki/C3.html https://www.martinfowler.com/bliki/C3.html
- buescher 5y ago
  Also from the Fowler piece: "C3's cancellation, however, also proves that XP is no guarantee of success." It's fair to examine the at best mixed success of the "birth project" of XP (which formed a lot of AGILE) when evaluating the breathless claims of people who sell methodologies.
  - mpweiher 5y ago
    Of course XP is no guarantee for success. Nothing is. For one, XP does not control the business environment of your project. Such as the company you are working for getting acquired in one of the more disastrous mergers of the outgoing 20th century. (And yes, disagreement and, er, "miscommunication" about whether this was a merger or an acquisition was just the start of it). If you expect your programming methodology to fix that problem...good luck!

flerchin 5y ago

Thanks for sharing. 9 hours to run payroll at its best. Wow.

Jtsummers 5y ago
Depending on the server or mainframe hardware it was being run on, databases, network connectivity, interactions with financial institutions, and potential physical activities (printing checks and such), 9 hours may not have been unreasonable in the 1990s. Digging around on C2: ChryslerPayroll (Essentially a batch app) db size: 2.5 - 4 GB server: Sun Enterprise 2000 4GB RAM interactive users: 5 So not exactly a beast by modern standards.
- WJW 5y ago
  Still, according to wikipedia it paid around 9000 people. This would make it run at about 1k/people per hour or about 3.6 seconds per person. Now it's true that the complexity of payroll calculations is often underestimated but this seems slow even for 1993.
  - Jtsummers 5y ago
    Given disk speeds at the time, it seems the DB was residing on the box, I wouldn't be shocked by a speed like that on a single or even dual CPU machine. And that's assuming all necessary data was in residence on the machine when the batch job started, and no network connectivity was needed (like retrieving that period's time sheets from legacy COBOL systems or pushing out the results of a paycheck calculation to a legacy printing system). More on its design: The project is essentially a batch-processing system. When it is time to pay, it cycles over all employees, computing the pay due, and exporting results. There are about 15 main external export receivers and a half- dozen different input sources. There are around a hundred different input transactions. http://wiki.c2.com/?ChryslerPayroll http://wiki.c2.com/?ChryslerPayroll EDIT: http://wiki.c2.com/?WhyIsPayrollHard http://wiki.c2.com/?WhyIsPayrollHard Talks more about the scope of what was being done. 3000 calculations per employee, formatted and transmitted to various COBOL systems from the legacy payroll. 3.6 seconds isn't exactly stellar, but on hardware from the mid-1990s it's not obscene either. It's really hard to judge systems based just on a performance number without knowing details about the actual hardware and network configuration and the systems it communicates with. If I tell you I can sort 1000 item lists in 10 seconds, that sounds bad. But if I then tell you it's an 8-bit microcontroller running at 1kHz and getting data over a 300 baud modem, it suddenly sounds reasonable.
  - flerchin 5y ago
    1997
- flerchin 5y ago
  The wikipedia article says that it paid 9k people. So 1k paychecks per hour. 3.6 seconds per paycheck. Agree that this would make sense if the limiting factor was the printer, but even so, parallelize the print job to multiple printers.

papandada 5y ago

Is the takeaway that Beck's approach doesn't work, that big things never work, or that nothing ever works?

flerchin 5y ago
I think the takeaway is that failure is always an option.
- papandada 5y ago
  From my own experience, this is a good lesson. Refusing to "fail" is often based on my own stubbornness and defensiveness towards something that ends up working better. I've seen that in school, career, and relationships.
deleted 5y ago
[deleted]

mpweiher 5y ago

As-needed reminder: "In particular the entry in Wikipedia is misleading and incomplete, much of its comments seem to be based on a paper from a determined XP critic whose sources are unclear. Certainly its comments on performance are a misleading interpretation of material in my Refactoring book." -- https://www.martinfowler.com/bliki/C3.html https://www.martinfowler.com/bliki/C3.html

buescher 5y ago
Also from the Fowler piece: "C3's cancellation, however, also proves that XP is no guarantee of success." It's fair to examine the at best mixed success of the "birth project" of XP (which formed a lot of AGILE) when evaluating the breathless claims of people who sell methodologies.
- mpweiher 5y ago
  Of course XP is no guarantee for success. Nothing is. For one, XP does not control the business environment of your project. Such as the company you are working for getting acquired in one of the more disastrous mergers of the outgoing 20th century. (And yes, disagreement and, er, "miscommunication" about whether this was a merger or an acquisition was just the start of it). If you expect your programming methodology to fix that problem...good luck!