The project has been put on hold for now. We got stuck early in January when we couldn't get past a deeply entrenched component from a third party vendor that had gone belly up. With no access to source code (and we did try to find a way of getting it) - there was no option but looking at replacing the component. Unfortunately, the effort required to migrate to a new component have been estimated to be so comprehensive that a complete refactoring may turn out to be a better alternative.
It just goes to show the importance of ALWAYS, and I do mean ALWAYS getting ALL components with source code. Another repeat observation is the importance of decoupling your GUI from your datamodel and business logic. Keep your GUI stupid.
I'll post some generic observations about code changes at a later point in time - but right now I am sunk in other tasks.
Subscribe to:
Post Comments (Atom)
Programming Related Blogs
-
-
-
-
I Fight For The Users11 months ago
-
-
IceFest in Pennsylvania4 years ago
-
-
Aaron Swartz11 years ago
-
Setup IIS for Episerver CMS8 years ago
-
-
Never Defragment an SSD13 years ago
-
Welcome to BlogEngine.NET6 years ago
-
-
Somasegar's blog - Site Home - MSDN Blogs8 years ago
-
-
-
The 2020 Developer Survey is now open!4 years ago
-
CodeSOD: Contact Us9 hours ago
-
Agreed. Even then, it's no golden guarantee, you still may have to change the component to get it to compile (and it might require considerable work), but you're improving your odds considerably this way. Sometimes you get lucky and others have gone through the modifications already and you can find the changes on the Internet.
ReplyDeleteTwo other factors I take into account are: How likely is it that the components will be around in a few years' time, and can I design the code around it or encapsulate the interface to the component so that it will be easier to switch the component for another.
I hope you continue to keep us posted about the project!
ReplyDelete