An Agglomeration Around a Broken Core

Sometimes I find myself working with a set of software that is essentially an agglomeration around a broken core. The architecture is inadequate to sustain expansion, improvement, or long term survival into the future. For whatever reason the initial system – its initial core architecture is not right.

Various things get added to the broken core to handle specific problems with it and expand it a little into new functionality. These things agglomerate over time around the core system. so their systems end up being agglomerations around a broken core. This seems like some sort of anti-pattern. Perhaps there is and anti-pattern called “Agglomeration around a broken core”.

Software development has become an agglomeration around a broken core.

Computer science itself seems to be an agglomeration around a broken core. The symptoms are more and more systems to handle the complexities of software including lots of SOAP and services, and interfaces and contracts, frameworks and patterns and mounds of code to handle fields/members. This is a nice list of agglomerations.

These agglomerations are mostly ways to try to deal with the broken core of computer science. Not to say that they are useless. They do have appropriate uses. Mostly they are to wrap the broken core so programs work better.

The Ultimate Cause of the Problem

The broken core is that we are handling fields in a way that is not always correct. Sometimes we want hard coded fields for performance and precision reasons. Sometimes it is better to have soft coded fields, however computer science has fallen down terribly in the area of supplying technology support, tools and theoretical basis for soft coded fields.

The Solution to the Problem is in Level 3

The solution is to build level 3 so that it handles fields in a soft way.
Level 2 will always be better written with the hard coded fields.
Now we need to develop level 3. We can use endeme powered soft coded fields with each field identified by and endeme rather than entirely identified by the class or structure or interface that it is in.

Because computer science is not a single system, different technologies can displace others over time by being implemented in a few and then more and more places over time. Eventually the broken core can be replaced through the life/death cycle of individual projects and systems.

As long as the languages we have allow me to do this I can contribute to this. But I have to get my working core working first, which means getting the soft code fields of level 3 to work properly and then start implementing systems using this. That is my solution.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s