The Forces of Software Development Nature

How to get No-code with No-curve

The core mission of Appmancy is to produce well-modeled web applications as painlessly as possible without specialist knowledge beyond the application domain. For example, programming and software development methodologies should not be a prerequisite. Design and architecture are characterized by trade-offs, which is one of the compelling reasons for developing an application in-house to maximize control and flexibility.

We can all probably agree that user experience is the most fundamental criterion for a successful web application. If users don’t love an application, continued use will be an uphill battle, and it won’t matter how well an application has been architected. By carefully considering the User Experience up-front, an optimal architecture and design becomes much more probable. Of course, features are not static, and new features will pose problems. The more features involved increases the likelihood of interference in a non-linear fashion, and trade-offs begin to resemble whack-a-mole. Technical debt, which may have begun minimally, will escalate as the application matures beyond the MVP.

At this point, one aware of the building tensions will want to step back and try to brace against these forces of software development nature. It is too late, but the battle is certain to be interesting, and some efforts will be wonderfully heroic. When we step back from any implementation disaster, we will want to reconsider first principles. Without too much effort, we can see that the well-architected application was based on a specific, and essentially static initial set of use cases that subsequently evolved with the natural accumulation of new features. Is there an alternative we should ask?

One thing that domain-driven design has borne out over its history of adoption is that nailing the application domain down up front, before considering implementation, is going to inform those subsequent implementations and give a fuller picture of the trade-offs. Though application features will always change, the application domain typically does not change. When there is change, it tends to be the introduction of additional aspects of the domain as opposed to material revisions.

Therefore, because applications will continue to change, and users will continue to desire changes, the best way to satisfy User Experience is to initially defer it and model the underlying domain as faithfully as possible because this more complete model will be a more faithful mapping upon which to overlay User Experience.

For this reason, Appmancy focuses first on the application domain, while keeping in view an additional goal of iterative refinement so that the model can be as consistent and as complete as possible. At the same time, in the service of no-code and democratization, the learning curve should be kept minimal without requiring any such awareness on behalf of the user. There is still a great deal of work to do there as the tool matures from its initial state, and so these chronicles will continue.

You can follow the developments here as well on the site (www.appmancy.com) and LinkedIn.