(This is the second installment in a series of posts that explains what we think is wrong with the current state of affairs in the mainstream business application development industry, and how we plan to fix it. If you haven’t done it yet, read the first post first)

We finished the first post of this series by stating it was essential to acknowledge the fact that concerns belong to one of two primary dimensions, namely the problem domain dimension or the implementation technology dimension.

The reason for that is that these dimensions impose a set of common characteristics shared by all concerns they are home to. That suggests that we should need different tools when addressing concerns in different dimensions.

Point #4: when addressing a concern, we should use tools that are appropriate for concerns in its dimension.

But is that true? And what are tools appropriate for concerns in the problem domain dimension, or for concerns in the technology dimension? To answer these questions, we need to look deeper to understand the differences between the two primary dimensions.

• change rate: concerns in the problem domain dimension change as often as the business requirements change, and that depends on the application and the problem domain. Concerns in the implementation technology dimension change only when a new target platform is to be supported, or a new kind of implementation artifact must be created, or a new implementation strategy (for the technology in use) is chosen. Comparatively, concerns in this dimension are more stable than concerns in the problem domain dimension.
• abstraction level: since concerns in the problem domain dimension can be addressed in a way that is completely independent from implementation details, they can be dealt with at a high abstraction level. Conversely, concerns in the implementation technology dimension are closely tied to the implementation platform and thus have a lower level of abstraction. Trying to address concerns on those two dimensions using the same abstraction level (for instance, by using the same programming language) is less than optimal, and it is bound to favor one dimension at expense of the other (think of an accounting application in C or an operating system in COBOL).
• reusability: artifacts created to address concerns in the problem domain dimension are reusable across target platforms and implementation strategies. Artifacts addressing implementation-related concerns are reusable across problem domains. Thus, the languages and methods for addressing concerns in the problem domain dimension should be technology obsolescence-proof, whereas languages and methods for addressing implementation technology concerns are free to harness the power of the technologies they are related to, while remaining agnostic to problem domains.
• skills required: developers addressing implementation technology concerns must be deeply familiar with the target platform and must know the best practices for the particular set of technologies chosen, no knowledge of the problem domain being required. On the other hand, people addressing concerns in the problem domain dimension must have good analysis skills and understand the problem domain they are working on – little to no knowledge of the implementation platform is required. They are not exempt though of having good object orientation design skills and a decent proficiency on specifying algorithms using imperative programming. It is seldom the case that a person that is knowledgeable on the problem domain is also an expert at some target platform, so being able to address concerns in different dimensions in a compartmentalized way opens great opportunities for work specialization.

Point #5: Concerns in the problem domain and implementation technology dimensions differ in many fundamental aspects, and thus you need different languages, methods and skills to address them.

It should be needless to say that this is the model of software development in what we believe. Languages and methods with the appropriate abstraction level for higher expressiveness and power. Problem domain related artifacts that are obsolescence-proof. Reuse nirvana by completely separating concerns across dimensions. Optimal productivity and job satisfaction through specialization of work across concern dimensions.

All this will be possible only if you can truly address problem domain and implementation related concerns completely independently from one another.

We are building the tools that will allow you to do that. Want to know how? Stay tuned for the next installment in this series of posts. Want to see it with your own eyes and help us make a great product? Send us an e-mail, introduce yourself and tell us how you would like to help.