Do we need to adopt a black-box asset our project is inheriting from its predecessor?

Question

Our client has an eCommerce site which was developed by an in-house team, and is now showing its age. I work for a firm brought in as external contractors to build a replacement. Part of the current site is a Flash viewer applet which displays media about the product - zoom-able images, 360-degree views, movies, and so on. We need to show the same media the current site does, so we are simply reusing the viewer.

The viewer is embedded on a page in the usual way, and told what media to show by means of an XML file it loads from our server, which is pretty simple for us to generate. We've got this working; it was pretty straightforward.

But what else do we need to do?

The thing is, as far as we're concerned, the viewer is a binary blob which is served from the client's content-distribution network. We embed it, feed it some XML, and it does its job, but we have no power over its internals. It's completely opaque to us - a black box. We can use it to do what it does, but we can't change it, so if we ever need to do something different, we're stuffed.

We're building this site for the client, and when we're done, we'll hand it over for them to maintain. We won't be doing the maintenance ourselves. There's a small team within the client who are working as part of our team, and who will be the ones doing the maintenance. That team only includes one person from the team that built the old site, and it's not someone who knows the image viewer. The people who do know the image viewer are not slated to join our team when our system replaces theirs - they'll be moved to other projects. The documentation on the viewer is extremely thin, and as far as i know doesn't cover the internals at all.

My worry is that if someone doesn't take some positive action, all knowledge of the internal workings of the viewer - even down to where the source code for it is - will be lost. It's possible it already has been.

Is this something to worry about? If so, whose job is it to worry about it? What should they do about it once they've got worried?

Answer 1

As I see it you have a choice between two problems. Black boxes have rarely worked for me, and are difficult to feed and care for. However, you've figured that part out--something that works for now. On the other hand, while the technology exists to replace the black box you have to determine if it is worth replacing.

Pros for Keeping the Black Box

• It's in place.
• It does everything your client needs right now.

Cons for Keeping the Black Box

• It's unknown, both stability and security wise
• The integration is a kludge, and possibly brittle

Pros for Replacing the Black Box

• You have control over the inner workings
• You can extend it to do new things your client hasn't thought about yet.

Cons for Replacing the Black Box

• If you build it, you have to support it
• It might be a bigger project than you expected (this is a big potential risk)

You'll have to do your due diligence to flesh out these pro/con tables with the information you have. If I were in your shoes, knowing that the solution works, and knowing that the relationship is not intended to be an ongoing relationship I would opt to keep the black box. Document your decision and integration process, and let whoever comes along next worry about it. If the relationship were going to be a long term one where we have a series of new features over time planned out, I would take a serious look at replacing the black box.

Consider your time, budget, and potential future revenue before making your final determination. There's no technical reason to have to keep the black box. The only reasons would be contractual or just because the oportunity cost is too great (i.e. you won't be able to deliver other features to replace this).

I hope this helps.

Answer 2

I would treat this as a risk to the project - at least with respect to long-term maintainability.

As such, I would consider it an absolute minimum to document and advise your management (in this case, the company that hired you as consultants) that this situation exists.

What you don't want (from a CYA) perspective, is for the team-member who is staff at that company to - some months/years from now - say that something is impossible because of this crufty thing that was created by some consulting company (even though you inherited it also).

As part of the risk mitigation strategy, you could outline alternatives, including open-source or commercial alternatives. It is also possible that that the company actually has the appropriate source code and maintainers for the component, just that they were not assigned to this particular project, so don't overstate the case, just the facts as you see them.

Good Luck

Answer 3

the [component] is a binary blob .... We embed it, feed it some XML, and it does its job, but we have no power over its internals. It's completely opaque to us - a black box. We can use it to do what it does, but we can't change it, so if we ever need to do something different, we're stuffed.

Are you talking about the operating system? The database? The web server? The LDAP server? The Javascript engine in the browser?

When I put in [component] I saw that your comment is true for a large number of elements of your technology stack.

Why worry about just one? Why not worry about them all?

Or, conversely, why worry about any of them?