Hacker News Reader

Comment by angarg12 | Hacker News Reader

I think the whole premise of this article is wrong.

If a project is successful, it isn't 99% done; essentially it will never be done so long it is alive, supported, and/or used by anyone (I won't get into semantics here).

As others have pointed out, many of those things should be done way earlier as part of the development, AND as part of the ongoing development/maintenance after launch.

On another note I'm also skeptical that a project should ever be 100% done even if that was possible. I had the privilege of working on a project during the whole lifecycle, including when it was deprecated and eventually decommissioned. It was very pleasant to go through all of the open Jira tickets for this product and close them as Won't Fix forever. All of those features, bugfixes and enhancements were never implemented. The project launched, lived, and died without them, and it was fine.

View on HN

I think where the semantics become relevant is that people say "project" to mean "product". When it's a product, it might never be 100% done, and it might be a poor idea to try to frame it as if it could be. But some projects aren't products, and don't have perpetual stakeholders, and for some of those it can be possible to set realistic 100% done targets and reach them.

I think this is the difference between products and projects. Projects definitely have an end. Products do not.

Good call.

Software is a living organism, or it is dying. Just as a practical observed matter of how it actually works out.

There are a few exceptions, but few indeed.

In todays age sure, But just looking back at games pre monetization / MBA era, they still work. Sure there are some bugs/ glitches/ but not much that breaks the game.

You can pretty much play any game pre PS3 era still enjoy it to it's fullest.

Similarly there’s the feeling of DONE for games of that era. Burn that Gold Master, or mask those cartridge ROMs, and it’s done. Fini.

Whatever shenanigans were done late in the project, if it passed QA, that code base was effectively read only, with little concern for ongoing maintenance.

On to the next one.

Kind of? But only because of forced upgrades.

The best code I've written is the code that's still running 15+ years later and no one even thinks about.

Firmware is also software and as far as I can estimate it never got updated after release in the vast majority of cases up until like a decade ago.

Think BIOS/vacuum cleaner/shaver/toothbrush/alarm clock/dumbphone/non-smart TV/airplane kitchen equipment/medical diagnostics devices/PLC's that control most of the entire world's infrastructure and so on.

It's entirely possible and very common to have an actual "final" software release and be just fine (at least up until recently before the whole "everything needs to have internet for telemetry" hype).

And that's a problem. Often there are full of issues which eventually are all known but never fixed.

Updateability is the defining advantage of software over pure hardware solutions. If you don't use the advantage then you are stuck with just all the disadvantages.

Nice theory, but it is overfitted to a broad category of all software and a product that is thriving shouldn't be conflated with a product that is improving.

Some products with software continue to "live on" successfully and thrive, without updates. Think of a digital alarm clock who's goal was to help typical users to wake up on time most of the time. If you ship a product that does that and it isn't being updated, is the product really dying or doomed to failure?

No alarm clock will ever wake everyone up on time, but we can always strive to get closer to that goal if we chose to set that goal. An unreasonable goal could cause unnecessary bike shedding, etc.

But a simple pacemaker for the heart, the goal is closer to the idea of helping as many people as possible, rather than most. Hopefully we write good software and we go 15 years without needing an update. I think that is better than bad software that has to receive more updates. Which software is more "alive" and "thriving". Is the good software with no updates for 15 years really "dying" since it isn't "improving"? Again, thriving and improving shouldn't be conflated.

So, a product setting appropriate goals helps determine how much maintenance is actually necessary and some goals can be met without requiring any future maintenance. Other goals may benefit from frequent maintenance. Some products can thrive without improving. A product's goals determine's the importance of improvements.

While that's true, there are also projects that can live and die with very few code changes for years. And as long as those projects are continuing to provide value for their lifetime, I'd call that a successful project.

On the other hand, I've seen projects get to 99% and they provide value for a few months and then because they never get to 100%, every time there's an issue no matter how small, it's very difficult to debug and the original owner has moved on to a new project or left the company so users are left holding the bag or they just end up deciding to stop using the product or build a new one.

Another way of looking at it: Nothing is ever 100% done when it launches. Nor should you wait for it to be, if it's been tested to your own complete satisfaction. I frequently launch things over 3-4 different beta phases to increasingly large swaths of customers, while documentation is still being hashed out by staff who are coming up to speed on the feature themselves. My goal is that at the 1-year mark, more or less, there are almost no bugs, by which time I've forgotten the nuts and bolts of the code. Meanwhile there are other features and pieces of software that need building.

Reply on news.ycombinator.com