There's a difference between "feature creep", "mission creep", and "organic growth", but sometimes it's hard to tell the difference.
Mission Creep: The goals change as you get further along in development. Developers hate this, and it happens so often in a second version of an application that it has its' own name -Second System Effect. Basically, the second version of the system gets loaded with all sorts of extra bells and whistles unrelated to the core. Hence "Every system evolves until it can do email."
Of course, it's not just the second iteration that can be so cursed. Mission creep can happen to anyone, because it "seemed like a good idea at the time" to someone who you can't say no to. Or the seductive song of "it can't be THAT hard to also cover this market ..."
Feature Creep: Even in first iterations (especially in first systems), feature creep is a problem. Why "especially"? Because until you're actually working with the system as it develops, there are probably going to be features that seem to be "must-haves", that aren't - and nobody wants to kill half (or more) of their code to eliminate a feature that now seems to be not so hot ... after all, maybe it will turn out to really be needed, or maybe it can be adapted ... or maybe cows can fly.
Of course, in the real world, you have two choices - either enter into anything realizing that the only way to make something different is to go in knowing that you're going to knife more than 95% of all the code you wrote - and be happy every time you find something that you can eliminate, because now you've made the end users' job easier 9 times out of 10 (and yours down the road as well, because code that isn't in the product doesn't have bugs :-p) or be angry because of the delays.
Organic growth: Unlike the first two, organic growth is one of those "Good Things" that, like Justice Potter Stewart said about porn, "we might not be able to define it, but we know it when we see it." A feature needs to be added, dropped, or modified to better support the original mission. You "eat your own dogfood" and realize that something - a process, a functionality, an interface feature, whatever - can be simplified, eliminated, automated, or otherwise improved.
Or you take a break and realize that there might be a better way to meet the original goals, so you code it up and test it ... and even if it fails to meet your demands, the additional insight can still enhance the final product.
So ...
Last week, despite the problems with my left eye, I was pretty much completed stage one. It was already "good enough" (and has been for a while, according to a few people) to put out into limited testing ... but one little part was a bit awkward ... and fixing it took less than an hour, worked as expected the first time (always a good sign), and really makes such a difference in ease of use that there's no way I'd consider dropping it.
So that leads into a problem ... there were parts that I was going to implement later on, that are now crying out to be included, because the screen real estate is already "claimed" for both the feature I just added, and the next part, and a lot of the core functionality to enable it is already present.
So, take a day to experiment, implement the back-end, try a few things, and it works ... and it looks REALLY snazzy ... but it's not quite what's needed. And doing it right will (I estimate) take another week. And there's the question of whether I can use any of the "SNAZZY 101" stuff ...
I "think" I can. I "want" to. But is it right? The only way to tell is to develop both, and see which works best, or whether I need to create a third alternative. And in the meantime, another week is lost, pushing out initial deployment to 2 weeks from now, barring any problems (because there's still a week of prep after it's "good enough to try").
The good news?
If I were doing this for a customer, there would be hell to pay because of the "it meets the original goals, just push it out" mentality. The same mentality that has reduced coding from an art form and a means of expression to a crap job with generally horrible working conditions in the first place.
Not having to listen to that sort of random noise is a Good Thing (TM). Not that it's likely anyone would hire someone who can't say, on a day-to-day basis, whether they can code or not because they might need a day or two at random to rest their eyes on top of the time off going to regular doctors appointments, blood tests, exams, treatments, etc.
Since this looks like "enforced entrepreneurship" will be the "future of work" for many of us, maybe it's time we took this as a positive, and not a negative. After all, to succeed, you only need to generate enough revenue to support yourself - not yourself, your boss, your co-workers, and everyone else in the food chain. It's risky as all heck, but if you're happier, isn't that what counts more, and will ultimately make you more productive anyway ...
... as well as the proven benefits of reducing the risk of mental deterioration as you age ... after all, what point is it to live to be SOME_OLD_AGE if you can't function mentally anywhere near your peak? If there's one thing we're pretty sure about senescence, it's that if you don't have the genes for mental deterioration* as you age, you CAN stave it off by continued mental work. It might take you a bit longer to recall individual items as your store of data grows, but that should be the only sign.
* simple marker - when you were a young'un in early grade school, did you write with short sentences (See Dick Run. See Spot Run. Sally spots Dick. See Sally Run. Dick is a Dick.), or long sentences (Dick was being a dick again, which is why Sally was running, and Spot was blah blah blah). If it was long run-on sentences, you almost definitely are safe as long as you continue to "work out" mentally. This was the ONLY predictor that was 100% accurate.