Lines Stations Bins Parts

C3 payroll architecture was described as Lines, Stations, Bins and Parts. Could an C3 person please explain how you got there from the simplest thing that could possibly pay one person? Seemed like it might be an interesting story, and also help me understand how an Xp project evolves. Plus, that sounds a lot like the architecture for a manufacturing production line, which is where I work. Is this the simplest architecture for everything? 8>) Thanks. --Bob Haugen

Part of the startup for a new XP project is the "boot camp". Part of that activity is to pick the basic "metaphor" for the program. We considered all kinds of metaphors, like Pez, Accounting, Prom Night, DNA, Recipe. We kind of talked through each idea to decide what the objects would be like and to see if we liked the feel of it.

We liked the feel of the manufacturing metaphor, and we thought it would be familiar to users and such in a company like Chrysler.

Turns out it works just fine, actually quite neatly, and the users haven't a clue about manufacturing - they're payroll people, after all! --RonJeffries

Something related: SystemOfNames

I am very curious, suddenly, about what a PezMetaphor? might be. "The essence of our system is lifting a plastic toy's head and extracting the candy from within" ...?

I believe that the idea was what a computer scientist would call a stack or list. The Pez thing clicks an item off the top when needed. The Pez was an idea that had been had in the previous incarnation of the project, it was offered in jest and if we explored it even for a moment I don't remember.

Could someone of the C3 people please tell us the LinesStationsBinsParts story. I´d like to see how you play the metaphor with blank CRC cards. --FrankWestphal

Stop by any time and we'll take you through it. We don't know a way to write down a CRC session, especially if we can't write on the cards. It'd sound like this:

We pay people with an assembly Line (putting down one card), which is made up of Stations (putting down a row of cards below the Line card). Each Station has some input Bins (putting cards to the left of one of the Stations), and output Bins (putting cards to the right of the same Station).

Each input Bin contains Parts (putting some cards on one of the input Bins), which are processed (picking up part, passing it over Station) and put into the output Bins (putting the card into one of the output Bins).

The Stations run one at a time, processing from input to output (picking up another Part, passing over Station, into output Bin, up from output Bin to next Station, showing Part flowing downstream.

When the Stations have all run, the result Parts are all in the final output Bins. From there we summarize them and print the check.

So, how's that ... got it? Or are the visuals important? (We suspect that they are.) --RonJeffries

Okay, after seeing Kent telling the HotDraw story with blank cards, I finally got it. Thanks, Ron. --FrankWestphal

Heavy guessing here: So a "Part" starts out being a person, and what they did (say, hours worked). They're acted upon by processes (Stations) that add things, like union dues and taxes, causing the person/Part to essentially become the paycheck. Like, you put the right "union dues processing" instance into the assembly Line for correct processing of this person. Am I anywhere near the mark? -- JeffGrigg

Essentially yes. For all practical purposes, a Person (intentionally not in my story) "has" a Line. Hours are Parts, converted by stations to EarningsParts? with Dollars, converted by further stations to TaxDeductionParts?, etc. The final assemblage of Parts, which is owned by the person, defines the check stub.

I thought the story was clear, even before this last explanation, but I've worked on several systems with a similar architecture. It looks like a dataflow system to me, just like the scientific data visualization and the music improvisation systems I've used/studied. That is a good metaphor for business transaction processing systems, of which payroll is a typical example. RalphJohnson

It looks like dataflow to me, too, but I didn't tell the applications guys. --rj

Why didn't you tell the application guys? I didn't get it until the second explanation (and I'd like to consider myself a decently intelligent person). I think all descriptions help (the metaphor, the explanation of the metaphor, and linking the metaphor with a dataflow architecture). They all seem to provide different information that could important in building the system. From dataflow I can apply my knowledge of dataflow systems to the consequences of picking the system. From the metaphor I can relate what the system does to non-technical types as well as how the system does its thing to technical-types. From the explanation of the metaphor I can concretely relate to how the system was implemented. I've gained a lot from all three. --HankRoark

The metaphor was a manufacturing plant not data flow architecture. If we had used both then names could, and probably would, have gotten confused. It was often very tempting to use a more abstract name for something when we were drawing a mental blank. But we stayed true to the metaphor and hashed it out till we found a good name. It is not as if Ron and Kent were keeping us poor idiots in the dark. --DonWells

Ron certainly implied that he was keeping you in the dark. What I'm trying to get at is it is not a good idea to do such and that multiple views make this problem of developing software easier instead of harder. --HankRoark

Yes, Ron and Kent have both implied that independently now. But they were not with holding information because we were too stupid to understand. They knew it is far better not to cloud or dilute your SystemMetaphor. A single, simple, universal view of the system is what we were after. Being able to guess at what something might be called if it did already exist and to guess right most of the time is a real time saver. --DonWells

Don, it appears that I've implied that you were stupid, hence the reason Ron and Kent (supposedly) withheld information. I am sorry and never intend to do such. What I am trying to get at, is do you think knowing that the C3 system was based on a dataflow architecture would have helped/did help with building the system? --HankRoark

Actually the information wasn't withheld at all. At the planning meeting where we picked the metaphor, I told the group that I was particularly comfortable with this decision because it was basically a dataflow architecture and I had successfully implemented those a couple of times. What did and does happen, all the time, is that an XPer works hard not to contaminate the simplicity of what she's doing with her knowledge of ANY advanced structures or algorithms. We call that "digging deeply into the bag of tricks" and do it only when it is really necessary.

For example, this week I showed someone how to do twos-complement arithmetic for signed COMP ebcdic conversions. We could have done it three years ago, but this week was the first time we needed it. It's not hiding info that matters ... it's not USING it until it's really called for.

Because I do know a bit about dataflow, I also know that C3 is much simpler than it would have been had we built it as you would a dataflow "framework". XP really did result in a better design, from less-experienced people, than I would have done had I done it myself. Fascinating. --RonJeffries

Ron, this is great. This is what I've always want to know about the SystemMetaphor. If you don't mind, I'd like to ask a few more questions: do you feel your knowledge or any member's knowledge of previous and documented dataflow systems (e.g., pitfalls, benefits, drawbacks, etc.) helped with quick building of the C3 system? --HankRoark

No, it would not have helped and would have potentially hurt us. A big part of XP is the code conventions in SmalltalkBestPracticePatterns. With in that, particular importance is placed on naming things well. I believe that we all had some experience with other systems of similar architecture not the least of which was the previous version of C3 itself. It was not unusual to see names from the pervious version creep into the system and conversation. We had to try hard to avoid that as tempting as it was to already have a common language. As I recall we actually went as far as to set up a $1.00 penalty for using an old name in conversation. By sticking to one and only one view of the system those important names converged on a well chosen set rather quickly. Once and only once is difficult if you do not have good names. --DonWells

Don's right, of course. Because XP is specifically designed NOT to rely on the specialized knowledge of gurus, folks like Don and I tried very hard not to bring in things that we knew from of old. The idea is that the huge bulk of the system is created by and understood by ordinary folks. Sure, there were special places in the system where we had to dig deeply into the bag of tricks, but it's very much the exception, not the rule.

One place where we do, in my opinion, suffer, is that we really don't have anyone who's really good at GUI design. Our GUIs are well-implemented, but they are artistically depraved. We need access to a GUI wizard. OTOH, XP (and especially C3) isn't particularly GUI-driven. GUI tweaking can consume entire projects. We work hard to avoid that. --RonJeffries

If this is the case, how deep is TooDeepIntoTheBagOfTricks? --HankRoark

I'm curious now, what kind of SystemMetaphor have the other ExtremeProgrammingProjects chosen? --FrankWestphal

VcapsProject uses one big BillOfMaterial? to represent the production of cars and trucks.

As I recall the current C3 architecture is not entirely dissimilar to the architecture that was thrown out. A Line was called a Processor, a station was called a Manager with Managers grouped under Practices, a Bin was called both Bucket and Account, and Parts, well, they had many names. It too was a data flow architecture. ProcessorPracticeManagerBucket?

Now in order to write the above paragraph I had to dig out the old design and look. I could only remember Manager the rest I had forgotten. But even after being away for years I could still describe LinesStationsBinsParts with crc cards. Which is exactly what you are looking for in a SystemMetaphor.

At the VcapsProject our original architecture had no SystemMetaphor. Finding the data you needed took on many aspects usually associated with mythology or voodoo. But after redesigning with a consistent top to bottom metaphor we were able to predict exactly where our data should be and lo and behold that is where it was, no frantic searching, no tracing it from the input file, no connecting to the production DB and running an exhaustive test to make sure it was always valid, etc., etc.. SystemMetaphor can help you. --DonWells