When we start a new project we know very little about the actual solution, some design will have been done, collection of features to implement etc. But the actual code we will write is as yet unknown.
The initial version is quick to develop and contains the best code we could write at the time, with the knowledge we had, but over time as we add features the application its structure begins to degrade and change becomes difficult
So eventually even the most well designed and developed application will have to be rewritten from scratch, this decay is well known within software design, called “Technical Debt” it describes the decay of code as features are added, by paying down this debt we can extend the life of a project, but according to this premise the application will have to be rewritten at some point in the future, when adding a feature becomes too expensive.
Hindsight is a wonderful thing, how many times have you finished an application and thought if I was to start this again I do do ‘x’ or use framework ‘y’.
When we finish the application, we have actually learnt how to do it, and probably have a whole host of ideas on how to do it better, if only there was a next time!
So what if every time a new feature is added, the application is rewritten from scratch!
Because with every rewrite we are learning to write the application better, the productivity improves and the structure of the application improves, we write better code and because each new feature is a rewrite, the application can essentially live forever, with no technical debt.
Enough of the utopia, we can’t rewrite an Amazon or Google from the ground up every time we want to add a feature, even if the next version would be better, no business can stand that sort of development, but I do think there is something here which could improve the development process.
This is all conjecture, but I thinking along these lines:
Version one of the application will be written including of cause all the usual features and specifications.
Version two uses the features and specifications from version one, and the knowledge gained to create a new ground up rewrite. I think at this point the beginnings of an application specific framework will begin to develop, because we will be learning form each version the knowledge can be pushed into this framework, this framework over time is the bit that is shaped by the knowledge gained in each future version, it may not be rewritten from the ground up, but because its application specific it can be easily moulded into the best solution known at that point in time.
Version three rewrite uses the features from version one and two, and includes the framework developed from version two, this micro framework unlike other frameworks is not written in stone, because we are rewriting the application each time, it allows us to shape the framework using the latest knowledge
Using this sort of aggressive rewriting and refactoring, the actual time taken to do a rewrite should decrease as the quality of the code within the application increases. The micro application framework should also be able to absorb new features without huge adjustment as the versions increase, the aggressive refactoring and rewriting should have created a structure that is the best for this specific application. The micro framework becomes the resource for the knowledge gained through each iteration.