Application Development Glass Ceilings

Sometimes in app-dev we’re using technologies that have a delayed cost. Simple to use now, but with shortcomings that mean that later features might be much harder to add. The term ‘Glass Ceilings’ (whilst classically meaning something else) seems to apply here.

An Example

I’ll Assume you are familiar with Agile. The customer/product-owner asks for a change to an existing dropdown in the UI. She wants a picture of the fruit next to the name of the fruit. He remembers Visual-Basic application development from the mid 90’s where this was easy. Also, She’s seen it in Java-Swing applications not so long ago. Now, that most enterprise apps are web-based, and fifteen years have passed since She first saw it, She thinks it should be easy!

Well, it is not. HTML does not support this be default. Most formal Web-Frameworks don’t do icon+text combo boxes. If they do it at all, it is because the authors have written something special in JavaScript. It’s a very custom control in HTML-land.

Lets say that the original feature (dropdown of fruit names load and saving to the database for the ‘thing’ in question) took a day to write. If we’re using a technology that does not have that feature we are going to have to go back to the product owner with some bad news or VERY bad news. It could take an eternity or be impossible to do it with the technology we are currently using.

What you really hope for is an ‘easy’ addition of something that’s correct for your technology choices. If you were using JQuery as your substantial in-browser technology, or were compatible with it, and you had this exact problem, then you’d be very happy that you found Fairway Technology’s FlexBox. Refer example 7 on their demo site like so:

Punching through the glass ceiling yourself

If we are using a commercial closed-source technology we are beholden to the vendor to even think our change request is important, or have a channel open for such communication. Moreover, we hope they are a competent outfit, and can ship a release quickly. If the technology is open source, then we’ve recourse to fork it and make a change ourselves. In that eventuality, we hope that the canonical version’s team will accept back the changes, and not make too many changes. Incidentally, this is one place that open source teams fails – not-facilitating someone else’s idea for that technology.

The worst-case scenario is that you have to change technologies. You might be halfway through the product buildout cycle, and heads will roll on this bad news!

The best-case scenario, is that the open or closed source team has ‘plugin’ mechanism for adding capability. Even better if there’s a way of leveraging/extending supplied components.

Even in the best-case scenario we’re going to have to suggest to the product owner that the feature She needs is going to take five days, but after that’s done, similar changes to other dropdowns will take half a day.

Thus, in summary, we hope that if we encounter glass ceilings during the building of an app, we can punch though them. Perhaps we are unsure about how much effort that will be in advance of encountering it. It is probably best that we are diligent in technology choices up front. I’m going to return to that particular thought in my next blog entry.

Not just UI controls

The problem of glass ceilings does not just apply to UI affordances and effects. You could encounter it in mismatches between a self-designed relation-schema for your app, and perhaps the Object-Relational Mapping (ORM) technology you chose. Perhaps your synchronous RPC technology should have been asynchronous.

Footnotes

I’ve talked about this before Ruby versus JavaScript for Web3.0 in 2006. That one was proposing changes to web-app coding that have not come into fruition. Perhaps they could with a future version of Dart, but I’m not chasing that agenda for the time being.

I’ll link to other proper HTML combobox solutions if people email me, or comment below.