Holistic Project Management vs Technical Project Management

Solving the problem of porting a Desktop Platform to Mobile Platforms with Fractal MVC Concept the Agile Way

I read this interesting interview of Flipboard CEO on BusinessInsider about the first engineer he recruited:

I hired this guy Evan Doll from Apple who was on the original iPhone team. He and I started working together and it was pretty clear to me when I met him, that he was going to be more than an engineer to work with, that he’d be the kind of person I could actually start a company with. He has the judgment, the sensibility and the holistic thinking that’s needed to be a founder, not just an engineer.

As an engineer myself – not in software but in industry and quality originally – I do always tackle any problem with a broader view than just a pure technical one. For example, I’ve just worked on a project for a financial credit subsidiary of an automobile company where our developers have to port about 50 totally independant no-mvc flash applications to mobile platforms (they should have been factorized but historically they weren’t when I arrived on the project – indeed the new architecture was also to ease future unification). The specifities are that the majority of components have to be crafted with custom graphical design per brand (2 partners brands actually). Also there were a lot of business rules that create an overwhelming number of dependencies between the different components – increasing the complexity manyfolds. Last but not least the application is meant to be used in the context of an internet mashup by 2 partners brands and we totally ignored at the time of decision what platforms these brands would be adopting – hence the new implementation should be portable also to Objective C / iPhone SDK, Java / Android SDK, Silverlight and of course Javascript / HTML5. So how to port all these components automatically in very short time to mobile and maintain them in the future with the same team ?

Well there is Adobe Air (and Adobe JSFalcon converter but which is not even ready today). But do you remember Apple did forbid Flash CS5 embedding tools for native apps some time ago ? Though this restriction has been alleviated it still doesn’t solve the problem that your application must also be accessible on the iPad in html5. So the idea of Fractal. This concept has a huge broad range of applications from 3D graphics to Stock Market modelisation. In fact I was originally attracted to Mandelbrot’s theory in that field. I thought that this concept could be applied to Software enginiering. In truth I had already that idea in mind since ten years (I first wrote a paper untitled “Unified Modeling Object” that I unfortunately lost) and start applying it already in past projects with Code Generation and Naked Object Architecture for a previous client banking system project. This time again, this concept was usable.

After all Componentization is about recursively embedding sub-components so somehow this idea should be natural. I start looking at what exist and stumbled upon this fractal framework which was unfortunately more targeted at distributed components architecture than to visual components architecture. I looked of course also at current more well known MVC frameworks like pureMVC but they all possess only “one dimension”. So an “n-dimensional” MVC was actually what I was looking for and indeed Jawaworld did publish an article untitled “HMVC: The layered pattern for developing strong client tiers”.

Nevertheless the implementation described wasn’t “Fractal” enough for me so I combined the idea of HMVC with the idea of Reactive Programming used in the Microsoft Rx Framework though there was no need to go as far as making everything reactive just the setter and getter would be enough applying the idea of SPOC (Single Point of Control). Each SPOC though not an object will act as the subject of an Observer Pattern. Then the design principle is simple: to bootstrap the system, first build an infrastructure of message pipelines, send the messages, and like for an Egyptian pyramid, the system builds up in cascade passing through all the SPOCs for business rules, and synchronize the visual GUI with all the super model and submodels magically. It also important and helpfull to understand that each entity was like a state-machine at every level.

When I did submit that kind of idea to developers, it seems simple enough in principle, but when the implementation phase came, they were stuck in front of a blank page. Because how can only a few simple rules build up a whole complex application ? I wasn’t astonished because the paradox between simplicity and complexity is always challenging. For example many developers in general have difficulties to understand how Class Interface which are completely empty could be as usefull as a plain full class. The solution to get out of procrastination is dead simple: just plan some agile iterations of course. Start with a simple component like a slider. Add some rules. Then add a parent component, then build the infrastructure for the message pipelines – if you forget to do so the messages cannot be received and the system cannot bootstrap so obviously so you’ll obviously ask why, find the reason and fix this. That’s how you can build an architecture the Agile way without any framework just using a few guidelines (we built a framework only for our public API that were exposing some query and state methods but none for the internal components).

Above all the interest is the systematic and simplicity of the code at every level of components which insure its portability and even automation through code generator that can be crafted using basic templating engine – Visual Studio T4, StringTemplate, … but even a good search & replace tool may be just fine and the whole structure of the first project can serve as kind of scaffolding template for the next ones. Crafting a full blown framework very much depends on the specifities of a platform, requires higher competencies (Use of Reflection maybe even undocumented methods) and development time which was much lacking. Flash developers are web programmers not Phd system engineers. Above all an Architecture is more about finding the Invariance of a System than building a library container per se – though this is very frequent from software editors because it is their core business – whereas the client here is not such type of company – and the the rationale is it would be counterproductive, risky and lengthy (multi-years men project just for the core system instead of a few months).

25. March 2012 by lepinekong
Categories: Agile, Architecture, Management, Principle | 2 comments