Don't Pollute Your Domains

Good software tries to model and implement the various needs of a system or application apart from each other.  This is called "separation of concerns".  A concern can be many things, but in general, it is a concept.  In AOP, Aspect Oriented Programming, there is an ability to actually code a concern that crosscuts many locations in an application as a single entity.
This capability allows a developer to write code that does not have duplication (DRY, don't repeat yourself).  It is likely that requirements for your system are written by a business analyst, not a computer scientist.  This means the person may likely know many things from software development such as terminology from security.  The gravity of an agile world encourages us to "keep it simple".  This means a requirement will be written in an allegedly simple way, incorporating security features into a business operating feature.  This attempt at simplifying things by uniting security concepts with application concepts, leads to "domain pollution".  That is the domain of the business is all that the SME (Subject Matter Expert) writes.  Well, this leads to domains that are abominations.  Animals aren't just created by declaring this dear needs to have wings because it may run out of food sources, so we need it to be able to get to this other area for food.
You, the developer will have to untangle the real security concern from the business concern.  If the requirements can be expressed in a way that utilizes terminology form different specific domains, then this blending can be stopped.  And we will reduce the needless smashing and untangling of concepts all because it was thought to be simpler.

When Metaphors Go Bad

I have a problem, sometimes I think too much, but I don't ever accuse you of thinking too much or "over"engineering or "thinking" too early. But, I have been wondering about these new ways software is recommended to be developed. This installment of this series will analyze the consequences of the use of the term "grow" as applied to creating software.

The reason a certain term is chosen must be because it is meaningful to the audience. So certainly the agricultural software development community must be what is intended. But what does it mean to grow software?

1. mold grows

2. flowers grow

3. a crop grows

4. a tree grows

If I missed the intended grow item, can you let me know?

Mold? well, I don't really think that is desirable in any way whatsoever?

Flowers? Ok, flowers can be really pretty, but they don't serve much use except for making seeds, are seeds really the nuggets we desire?

A crop? Well, maybe that is it, we raise a crop of software so we can sell it and make lots of money?

A tree? Well, a tree is a beautiful creation of nature, it converts carbon dioxide into oxygen, we create houses and fire out of the wood, hmmm.

I don't think any of that was really planned.

But we might think of building software, like a building, but how can we apply agile principles to growing a building? it will just get bigger, that is how building grow, um, wait a minute, I will save "build" as my next installment.