How to make a mess of a modernization project?

Question

If your goal were to botch a legacy application modernization project, how would you set about it? What are the worst strategies and practices to adopt?

Answer 1

Another aspect of bad practice is when people are mixing their front-end project with both .scss, .css, .ts and .js because they sometimes just don't find a solution of some case in TypeScript they implement JavaScript files in the same project. Then there are many cases where people implement poor JavaScript libraries in TypeScript projects that do not support TypeScript and will break the application now or later.

Some other bad practice is to not organize your .js files and write more and more code in a single .js file that will reach 1000 rows then 2000 rows etc.. and after a while, there is no point updating anything in that file because its impossible to get the whole picture.

Answer 2

Port it to node.js and bury it deep in dependencies on single-maintainer abandoned packages, many layers deep and interconnected, so that it'll be essentially a total re-write to get rid of those dependencies 2-3 years down the road when some update to some tiny package somewhere at the end of a long dependency chain breaks everything and introduces impossible version requirements (aka package A wants the new version of package X, but package B is locked to the old version, while package C is fine with the old and newer versions, but not the newest. It has announced to drop compatability with the old version in the next update...)

There's a few other languages where that would probably work as well.

The strategy behind that is to use fragmentation as a weapon against the poor sod who'll have to maintain and update that monster. If you make the dependency graph silly enough, sooner or later something will break in terrible ways.