Blogged Images
The end of CASCADAS
How it all turned out after 4 days of hacking.
Well, we have more code at the end than before, and Ed was right, we had no choice but to visit a lot of those dead ends. I also learned a lot about what the ambitions of the Cascadas project are, in particular what the names of the elements should be, and which design decisions were non-negotiable.
I was increasingly frustrated through the week, since we spent a lot of time focused on aspects of the approach which were defined in terms of implementation elements and approaches, e.g. what elements were called, and what the strategy should be, rather than implementation outcomes - what it should be able to do and capabilities which would be delivered. This was particularly frustrating when aspects of the chosen programming approach were certain to create more work, and far from certain to deliver any actual advantage in deployment.
We had debates how each ACE had to be multi-threaded, (that had been documented already), that there had to be a SelfModel, Facilitator, Reasoner. An Internal Message Bus was required to carry a representation of every operation before it was executed. Very few of these elements interfaces or expected behaviours were defined with the precision required to write code. All were mandatory.
Part of the problem here is that the team has already been working on a lot of concepts and documenting them without getting down to code. Coding reveals a lot of the engineering aspects inherent in what you're trying to do, and typically determines the implementation elements and approaches rather than the other way around.
In defense of the CASCADAS guys, describing and defining outside of code is a critical aspect of an EU project, in which the funding and judged success depends on presentation of outcomes to reviewers. Given the importance of documentation, this can mean that the implementation part ends up taking the back seat. This meeting was deliberately convened by Marco and others to get down to concrete engineering. They're on the right track.
Anyway, you can imagine the clash of cultures from a documentation, concept-led academic approach met my hacker mentality. I was mostly patient with the constraints under which we were operating for the first few days. I recognised my role as a resource for the team to use, and I think we were all able to share insights which will contribute positively to the final outcome. However as time ticked by with more debate on elements and the relationships between them, a difficult-to-engineer complex which did not yet actually function at all, my mind started to fray.
I see no reason why we couldn't have had working components and interfaces for the simplest scenario by the end of the third day - single-threaded ACEs composed of SelfModel, Reasoner, Facilitator, Bus and Gateway representing arithmetic primitive values and operations, (very simple) and forming production chains to satisfy requests for specific integer numbers. I'm even tempted to throw the code together just to prove it. The interfaces and implementations may not have been final, but they would have been indicative, and be there in a working implementation, suitable for re-factoring in response to concrete requests and issues encountered when early adopters began working on the beta version.
The speed with which code was being re-factored and becoming functional again was really quite reasonable, but most of the coding time was re-factoring to avoid issues arising from the multi-threading decision. The final refactoring led to at least some working code which can be worked on further. The other ones were mainly dead ends. But everyone learned a lot, including me.
By the final day of coding I think I'd pushed myself a bit too far. My usual obsessive focus - trying to get some useful structure, create things which were actually functional was getting diverted into clause and subclause of debates which I couldn't reconcile with making any progress towards a first cut implementation. Added to this the fact I was supposed to be on holiday by Friday at the latest, and still Friday morning came without a real implementation of any interactions between ACE components! So I snapped at Ed talking about the encapsulation requirements of the code I was writing, threatened to leave that minute, and stormed off to have a coffee to calm down (it's well known that coffee calms you down at a time like this). So much for professionalism.
So the problem remains - implementation and interface and design has to be attempted with code and not designed in Microsoft Word. But there's a lot I have to learn about doing code collaboratively without getting stymied by interesting but diversionary debates. I won't be implementing the Arithmetic scenario - that's what the past week was for and my time just ended up being invested differently - I can deal. I have to get back to rebuilding the Hubbub forum, and preparing for Ian Livingston's briefing on Tuesday, Challenge Cup run-through for Wednesday, and preparations for my trip to MIT.
Latest | Search | Contact