|
> A finished project is a dead project. If it isn't improving, it's dying. Define 'improving', because there have been quite a few major projects that have been getting 'worse' (slower, buggier, less secure, more bloated, breaking changes, feature creep, inconsistent documentation) as time goes on. So what exactly are we prioritizing? Wintel conquered the world by maintaining backwards compatibility. These days the majority of 'improving' seems to be for getting around breaking changes introduced by others and making unnecessary UI changes. Reliability and consistency is not a priority anymore. Instead no software can ever truly be finished because the assumptions under which it operates change unpredictably and inconsistently. I mean really, once you finish something like a file renaming utility, what else is there to do? If it stops working due to changes made by someone else, then it needs to be updated, but that isn't improvement. If on the other hand it's working as intended, then the only way to further improve it is by changing priorities. Engineering is all about tradeoffs, but priorities are now being driven almost entirely by cultural forces, and I've seen this render working software inoperable for no other reason than it didn't fit the fashion of the time. Reality doesn't change to the point that a chair, or even a microprocessor, stops working. Software on the other hand does, and if the platform you're targeting isn't stable, then you can never finish a project, let alone improve it. And this 'no updates' = 'dying project' philosophy is a big part of the problem, because it forces developers to unnecessarily update a project just so people believe it's relevant, while the only metric we should be using is that the software is fit for the purpose we use it for. |