• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Looking for example of Shearing Layers in software development

aggle-rithm

Ardent Formulist
aggle-rithm
Joined
Jun 9, 2005
Messages
15,334
Location
Austin, TX
Hello,

I'm writing an article where I'm discussing the dangers of shearing layers in software development, but I can't think of any high-profile concrete examples. (For those of you unfamiliar with the term, "shearing layers" is borrowed from architecture and describes different parts of a system that change at different rates. The point where they interact with each other is a potential weakness.)

I thought of the Y2K bug as a possible example, but I'm not sure that's applicable. I've also considered bank web apps, which have a shiny new front end but a ancient, creaky back-end...the problem here is that I can't think of any concrete examples.

Any ideas?
 
aggle-rithm said:
Any ideas?
Click to expand...

I don't want to be dismissive, but I'm wondering if perhaps this is a metaphor in search of some concrete? Is there some reason to assume that this is a real phenomenon, or is there some deeper linkage than metaphor to anchor this to? I considered back over my career as a programmer and cannot find an example. Perhaps it would be good to know what exactly change rates means here?

I'll understand if you just want to say you'll give a link to the finished article later, or some such.
 
shadron said:
I don't want to be dismissive, but I'm wondering if perhaps this is a metaphor in search of some concrete? Is there some reason to assume that this is a real phenomenon, or is there some deeper linkage than metaphor to anchor this to? I considered back over my career as a programmer and cannot find an example. Perhaps it would be good to know what exactly change rates means here?
Click to expand...

A good general example would be the difference between data and data schema in a software system. The data changes constantly, but the schema remains unchanged for years, maybe decades. At some point, the nature of the data may change so that a new data schema is needed, but change to the schema is expensive. What usually happens is that the schema includes fields like "misc_data_1", "misc_data_2", etc., and the new values are shoe-horned into these fields. It's an ugly solution that creates a vulnerability to failure in the system.
 
In industrial software controls the machine control software (due to capital investment costs) is very often much more ancient than than ERP and web portal software and so there are many complex adaptions that have to be made.
 
aggle-rithm said:
Hello,

I'm writing an article where I'm discussing the dangers of shearing layers in software development, but I can't think of any high-profile concrete examples. (For those of you unfamiliar with the term, "shearing layers" is borrowed from architecture and describes different parts of a system that change at different rates. The point where they interact with each other is a potential weakness.)
Click to expand...

Sounds like the definition of DLL hell, or dependency hell in a more general sense.

Any sort of dependency, whether its has to do with raw code, or more abstract dependencies like requirements, can cause slippage and bugs. Duke Nukem Forever is probably the standard that all other failed or late projects should be measured against, many issues are directly related to shearing layers, in short:

- volatile and rapidly changing requirements resulted in previous developed code to be ripped out and re-written. Scope creep, feature creep.

- the game actually took so long to develop that, with advances in graphics setting the bar higher for top-tier games, developers made the decision to incorporate the latest technology before their product was close to completion. It made the switch from Quake Engine II to Unreal Engine in 1998, forcing a total reboot of the project. It switched to a modified physics engine in 2004, causing more delays.
 
Last edited:
Dessi said:
Sounds like the definition of DLL hell, or dependency hell in a more general sense.

Any sort of dependency, whether its has to do with raw code, or more abstract dependencies like requirements, can cause slippage and bugs. Duke Nukem Forever is probably the standard that all other failed or late projects should be measured against, many issues are directly related to shearing layers, in short:

- volatile and rapidly changing requirements resulted in previous developed code to be ripped out and re-written. Scope creep, feature creep.

- the game actually took so long to develop that, with advances in graphics setting the bar higher for top-tier games, developers made the decision to incorporate the latest technology before their product was close to completion. It made the switch from Quake Engine II to Unreal Engine in 1998, forcing a total reboot of the project. It switched to a modified physics engine in 2004, causing more delays.
Click to expand...

Thanks, I'll look into that.
 
Sometimes, when revising software, you want to - or need to - make fundamental changes to behaviour and/or interfaces. This can often be hidden by providing the changed parts via completely new connections, but sometimes this is difficult or infeasible.

Further, by keeping the old baggage around you end up with a complex, large, and often difficult to maintain and debug mess.

So, per se, making new versions of libraries incompatible with the old can be desirable.

Where the Microsoft model erred is that it provided no (automatic) way to have multiple versions of the shared library (DLL) present, with programs automatically directed to the appropriate version. This was an issue that had already been solved in Unix, but for whatever reason they overlooked or omitted this solution.

They have provided a mechanism for .Net assemblies; there, you can (and often will) have multiple versions of a file present.

The solution, by the way, in generic terms is to make version numbers part of the library name. On a Unix, Linux, or Mac OS X system, if you look in /usr/lib, you'll find typically at least two files for any given library:
- libname.so or libname.major-version.so
- libname.full-version.so
e.g. libstdc++.so and libstdc++.6.0.9.so.

Sometimes there'll be three: without a version, major-version, and full-version.

Note: A shared library is a .so on Linux and most Unix systems, a .dylib on OS X (and probably BSD, although I don't have access to such a system) and of course a .dll on Microsoft Windows.
 
I would say SOA architecture and Enterprise Service Buses suffer from this effect. Often the contract between the systems is kept the same or non-breaking. This has the effect of having systems talking through some old interfaces where they re-purpose fields to do something else since changing enterprise contracts is a big deal.

Another issue is that to solve the above problem, some contracts leave in free text fields where people usually evolve a different protocol within that field which only applies to certain systems but not understood by all.

I hope this is of help.
 
You must log in or register to reply here.

Back
Top Bottom