Had an interesting experience yesterday – I’ve opened LiveUI project after 3 month's pause. (Project is dead frozen since January). And there are several lessons I’ve learned. First one is: It is difficult to develop a framework and have a fresh look at the same time. Now I see many mistakes I did not notice earlier. The biggest one is that it solves too many problems. For example, LiveUI provides special infrastructure to make sure client side objects are disposed correctly. Now it is obvious to me that 99.99% of ASP.NET developers do not care about memory leaks at client side and therefore feature development was not cost effective.
So, how could features like mentioned one be implemented at all? The reason is that applications we developed using LiveUI needed these features and it seemed natural to include them in a framework. (we developed LiveUI and used it in parallel). Unconsciously I followed the pattern – If feature has nothing to do with specific business logic and can be implemented as a part of a framework then it should be implemented as a part of framework. It was foolish and that’s why. When you implement a product for some customer then cost of feature is just cost of its implementation but when you develop a framework it is much more expensive. Firstly, because API reviews, documentation and samples take time, secondly, because it makes framework more difficult to learn. Every public class and every public method kills simplicity which is precious resource. Once it is written it seems obvious, but, unfortunately, it was not.
So there is the second lesson I learned. What I had to do was to split projects in groups like these:
But our project structure was
As a result, framework included too many features and was not finished in time. May be, in the future I’ll find time to throw away 60% of LiveUI which would make it finished at once :)
0 коммент.:
Отправить комментарий