At the start of your project you have to make a list of things that your application framework has to support. Some examples:
- CRUD functionality (Create, Read, Update, Delete)
- Menu and security features
- Use and storage of application configuration data
- Special user interface requirements
When you have built your framework, build a small part of your application. This is to verify that your framework actually works.
After that you can build the rest of your application quickly and without worries. Integrating framework-like aspects into an existing application requires a lot of refactoring, which is much more expensive than getting the framework right first. And starting full scale application development when your framework is not finished yet requires temporary stubs that need to be replaced be the real thing later, again making it much more expensive than getting the framework right first.
This is not just my opinion, it is a simple extension of all the studies that say that fixing defects becomes more expensive when done in a later phase of the project. Some people think that “First things first” only fits a waterfall approach to software development, but I disagree. In, for example, a SCRUM project the “First things” can be assigned a high priority so they will be done in the first sprints.
And I know there are many differences between building a house and building software, but would you lay the carpet before installing the plumbing?
I agree but we should also point out that there may well be some functionality that you must at least prototype, to see whether it is at all feasible within, for example, performance constraints: Checking, perhaps, that you can get the carpet up the stairs and into the room. Spending time on framework to find that the core functionality isn't going to work is even more futile.
BeantwoordenVerwijderenIn my humple opinion you should add some other basic requirements as well which are forgotten most of the time but stumpled upon during deployment: standard logging and error handling that suits the IT Operations department's needs. This should be standardized in your framework and is basically not complex but from my experience a hell of a job to add afterwards. In that perspective: it's nice to have your carpets upstairs but if the color isn't right, the dimensions aren't correct or the carpets are in the wrong room this move doesn't help you a lot. Think ahead about the most important requirements but don't loose the less important ones out of sight.
BeantwoordenVerwijderenDeze reactie is verwijderd door de auteur.
BeantwoordenVerwijderenPS: I was thinking of Uniface Web applications when I wrote this. It still is relevant for Uniface Client/Server applications but they require less plumbing.
BeantwoordenVerwijderenIf I may also comment, as part of the 'first things first', I would also make an important point to build an incoming interface into your application (whether it be synchronous or asynchronous) from external applications / third party components.
BeantwoordenVerwijderenDoing this first up will give credibility and a sense of strict guidelines to your integration projects, whilst keeping your framework intact at every tier of your application.