Archived

This forum has been archived. Please start a new discussion on GitHub.

Starter question: assessing the technical indebtedness

Hello,

This is kind of a high level, but would anyone care to comment, share stories, recommend pros cons, pitfalls, etc? There's probably more I can get into, just not aware of. Any enlightening tidbits would be helpful. Thanks!

I am involved in a project that has recently shifted gears from a Linux/ARM Mono C# track to more of a C++ track. Today's Linux flavor is ArchLinux; not sure why that flavor versus others, perhaps for embedded performance reasons, kernel compactness, I don't know. If we have a case to move to another distro, I think we would do that.

A little background, I am no stranger to distributed computing, concepts and such. Have had exposure to CORBA in past years, COM-family, WCF and web methods more recently, and so on. In terms of grasping what Ice (or possible Ice-E) have to offer: seems like active (current) culture, it's alive and being maintained today.

Additionally, I've sold the team on the benefits of a distributed approach, to decouple embedded on-device interfaces (servants) from more app-centric subscribers (clients), keep concerns separate, isolate for development and test, etc. Our initial thought was roll our own infrastructure, but upon further reflection, that's promising to be more of a black hole, putting distance between where we are and deploying to market.

Specifically, we will be in a C++ realm. I've decided boost is the library of choice for engine modeling purposes. Not so much for infrastructure (i.e. infrastructure as a service), with the reasoning: let the infrastructure experts handle that (i.e. enter omniORB or ZeroC Ice, for example). The chief reason is that I want to be focused on solving the core business competency as opposed to getting sucked into any black holes like infrastructure.

We are also employing Qt for UI integration purposes. We're exploring a more recent version of Qt than the one that Ice incorporates (4.8 something > 4.5). Is this a problem, or how seamless a transition would this be? Any other version conflicts we should be aware of adopting this as our middleware infrastructure of choice?

The language-polyglot is attractive from a hosting standpoint. We can simulate or connect remotely in development phases to separate concerns, isolate for test, accelerate time to market, and all those things. Plus potentially expose Slice'd concerns to different language environments: C++ boost Qt on the one hand, or C# .NET for other facets of the overall suite.

We'll want to figure out the cross platform, cross compile issues sooner than later I expect and agree on a project workspace that we can all live with. I'm taking the lead on that one mainly taking into consideration project risks like rebellious subcontractor.

I've already had the conversation with my employer: not sure his relationship with our subcontractor is a strong as he would like: subcontractor interest is not employer's (is it ever?): their concern is being paid for services, not delivering products, necessarily. That sort of thing.

My concern is making sure whatever tech choices we're making that the project can sustain, we end up with maintainable, extensible code, which track record has proved, has been anything but, there's a lot of concretions floating about, which don't float well for very long. Can make a couple of deliveries, but don't expect to swim for very long.

Comments

  • benoit
    benoit Rennes, France
    Hi,

    Regarding Qt, there's no dependency on it so you should be able to use Qt 4.8 with no issues for your client applications. Qt is only used optionally by the IceGrid and IceStorm services for the Qt SQL layer (and only if you enable the DB plugin for SQL).

    Cheers,
    Benoit.