4 ms·
Maybe not a surprise, but definitely unexpected, was the number of systems where, over time, the incremental features had overtaken the original architecture, b
by squonk 14y ago
Maybe not a surprise, but definitely unexpected, was the number of systems where, over time, the incremental features had overtaken the original architecture, but the vendor would not fund a new implementation. I've seen 15 year-old systems that were so byzantine, every feature change broke two others, and attempts at improvement caused entropy. It was both a huge time sink and customer satisfaction debacle.
Here is an idea for CSCI 344: Identifying When to Throw that Shit Out
- lttlrck 14y agoMaybe they read this: "Things You Should Never Do, Part I" http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- tomjen3 14y agoAh, but doing that was what allowed them to kill IE and restart the browser wars. Seems like Joel should retract that article.
- yuhong 14y agoAnother favorite example for me BTW is the MS OS/2 2.0 fiasco that IMO is much worse, involving MS using unethical tactics to attack OS/2 later on. And Joel happens to be a former MS employee.
- Confusion 14y agoAs the link by lttlrck also advocates: throwing shit out can easily be a mistake. More usually, http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea... + http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/ http://www.amazon.com/Refactoring-Improving-Design-Existing-... can get you further, faster. Stuff keeps working while you incrementally improve it.