Problems with software development nowadays part 3

In my previous post I ended by saying that defining only the 'what' of an application is very efficient in terms of size and thus maintenance. But are there any other advantages?


One other advantage I can think of is the ability to change implementation. An abstractly defined application can in theory be executed on every platform, every operating system, every user interface technology, as long as somebody provides an runtime implementation. This is actually a way to fight technological decay (see part 1)


Another benefit of abstract definition is it can help with attaining a noble goal: don't repeat yourself. The don't repeat yourself principle is well known in software engineering but rarely reached. Take a simple validation rule like: the country name field in the country table must be unique. You want to define this rule only once in your application. You want the rule to be checked at least in two tiers: in the client before saving a new country record with feedback in the UI when the rule fails and in the database by using a unique index or a trigger. One can think of these as two implementations of the same rule. Business applications are filled with this kind of validation rules, simple and complex. It is a very common pattern in business apps. In current development you will have to implement the same rules twice, mainly because they are expressed in different languages, like C# and SQL. This introduces all kinds of problems. How to keep both implementations in sync? How to be sure both rules check the same thing? Often the rule is only implemented once leading to problems with dataconsistency when the check is only implemented in the client tier or incomprehensible feedback when the checks is only implemented in the database.


Yet another benefit of abstract definition is standardisation. Standisation in the way an application behaves and looks. This is because when abstracting a business application you try to generalize components of the app, striving for generic solutions instead of specific ones.


In my first post I talked about how to keep documentation up-to-date? I think that we should make documentation part of the development process. On various development platforms this is already partly done for technical documentation by documenting classes, properties and methods. So why not for more functional information? Documentation should be like creating classes. That way it stands a better chance of being adapted and maintained while changing code. The documentation can then be extracted from the application and can be presented in various forms like Word, Visio or whatever format is desireable.


Today I've tried to show some big benefits of defining a business application abstractly. The big question remaining is how to do that? In my next post I'll reveal parts of the solution we are building at Abstract IT.