Grrrrr

[d000hg]

Trying to port code from version X of a proprietary library to version Y, and finding the improvements to version Y mean some of our functionality is potentially not possible at all.

[suityou01]

Trying to port code from version X of a proprietary library to version Y, and finding the improvements to version Y mean some of our functionality is potentially not possible at all.

Borrow MS's book on design patterns. "Decorator" is the one you need.

HTH

[suityou01]

What's the business case for "upgrading" to an inferior product?

[d000hg]

Borrow MS's book on design patterns. "Decorator" is the one you need.

HTH

That only works if the same functionality exists or can be implemented in both.


Version Y is newer so the business case is to remain under support Actually it is better but some things were removed and we happen to rely on one of those things

[oscarose]

try a 'dummies' book

[suityou01]

That only works if the same functionality exists or can be implemented in both.


Version Y is newer so the business case is to remain under support Actually it is better but some things were removed and we happen to rely on one of those things

The decorator pattern I was talking about was the one where you decorate the library with the missing functionality to make a new library that is fit for purpose.

The business case is "cos it's newer"?

[d000hg]

The decorator pattern I was talking about was the one where you decorate the library with the missing functionality to make a new library that is fit for purpose.

Only if the library exposes the data/low-level functionality you require.

The business case is "cos it's newer"?

Yes, in the same way businesses and governments are upgrading from WinXP to W7 because it's newer. Go back and read what I wrote.



It's a lovely insight into what working with SY01 must be like, this Should I demand to see the requirements matrix?

[original PM]

you do understandy Suity that most software has a certain lifespan after which the product goes out of support.

This means that whilst you may still find people who will support it for you the actual software company who created it will not fix and bugs which are found.

Not normally a problem as by then the product is mature and it is unlikely that new bugs will be found unless you start to push the boundaries of its functionality.

And so there becomes a risk/cost decision based on increased cost to support and also the risk of using a product which is out of support fy the creator.

And thus you have to do software upgrades which can often add little to no new functionality but do require full regression testing.

[oscarose]

you do understandy Suity that most software has a certain lifespan after which the product goes out of support.

This means that whilst you may still find people who will support it for you the actual software company who created it will not fix and bugs which are found.

Not normally a problem as by then the product is mature and it is unlikely that new bugs will be found unless you start to push the boundaries of its functionality.

And so there becomes a risk/cost decision based on increased cost to support and also the risk of using a product which is out of support fy the creator.

And thus you have to do software upgrades which can often add little to no new functionality but do require full regression testing.

++1