Why is it so tempting to start a new project instead of finishing previous one?

[RoGeorge]

Why?!

[joeqsmith]

Lack of maturity? 
ADD?

Hard to say really. If it's causing a problem in your life, you could seek out professional help. 

[daqq]

Because starting something new is exciting, can involve lots of hacking, learning, interesting stuff.

Finishing involves far more boring stuff - writing (user) documentation, certification, fiddly debugging, testing... basically stuff that's not half as much fun as the rest. Also, it's natural to be excited more by new stuff rather than doing the same for a lot of time.

[EEVblog]

Why?!

Because starting isthe fun part, finishing is the tedious boring part.

[GlennSprigg]

I think that, (I for one), have too many ideas going at once. We create such 'projects'
in our head, but often forget about the amount of varied technology to bring it to fruition.
Software / Hardware / personal availability of parts / fabrication / usefulness / interest for others...
We 'Jump-In' at first with such enthusiasm, and find a few stumbling blocks, and 'we' put it on
the 'Back-Burner'... but in being truthful to one's self you 'know' we will not pursue it, at this time.

It's the 'excitement' of what is 'new' in our heads at the time.... I've spent 'many' a time at this
mental 'CrossRoad', and have long decided that I will continue IMMEDIATELY, even if the only
person I will 'Impress' is myself... WHY!!... Because I realize every day that I have learnt and
applied something new. 'MY' 'audience' is usually just myself. If I help others, then fine........

[harnon]

Because starting something new is exciting, can involve lots of hacking, learning, interesting stuff.

Finishing involves far more boring stuff - writing (user) documentation, certification, fiddly debugging, testing... basically stuff that's not half as much fun as the rest. Also, it's natural to be excited more by new stuff rather than doing the same for a lot of time.

Pretty much this ^^  At first you are solving problems left right and centre, getting stuff done and generally having a ball. You do all the fun bits until eventually all you are left with is the time consuming, fiddly, less interesting bits that need to be done to finish off a project. Sometimes I find (especially with software projects where you can tweak endlessly) that there isn't really a finishing line - I can just keep adding features for ever and the thing is usable but never actually gets "done".

I find that promising somebody else I'll make / do something for them is a great way to motivate me to finish.

[Tomorokoshi]

This is a variation of several classic project management issues, such as time, budget, and resource estimation and allocation. Lots of lessons have been learned over the years, which are then routinely ignored, forgotten, and relearned.

I like to recommend Mr. Brooks' work, "The Mythical Man-Month", which generally goes unread by the various managers and engineers I give it to. The same is true for some other works.

I'm grinding through "The Principles of Product Development Flow: Second Generation Lean Product Development" by Reinertsen now. Even though it's aimed towards a lot of that new-age Agile stuff, it does eventually get to some good points about cost/time trade-offs, workflow, backlogs, queues, etc. The main takeaway is how much of engineering management is at conflict with optimal engineering resource allocation.

In the case of projects stalling out, from the point of view of Reinertsen (not necessarily mine) you are hitting that part of the project where the cost of an improvement is more than the value of the improvement. I have my own backlog of projects in this state.

As time goes by the projects get re-evaluated based on what changed. Do I have access to better technology that makes the solution easier? Do I have more experience now to make the solution easier? Have things changed such that I'm better off abandoning the project?

One perspective from Reinertsen is that the optimal failure rate in the test and development phase of a project is 50%. Think of it as an optimal binary search for the ideal design. 0% failure during development gives no information, and 100% failure gives no information. Translation: learn from your mistakes, and roll that into the next part of the project, or into another project.

[schmitt trigger]

In addition to the wise words of others, this is my take on this one:
Many, or I would say most, projects do not work EXACTLY as intended the first time....or perhaps not work at all.
In some instances, even the magic smoke may be let out, copious amount of it.

You have two choices:
-The first and simpler impulse would be to simply scrap the non-functional stuff away, and to start yet another exciting project.
-The better but harder behavior, is to lick your wounds, fight the initial disappointment, and start troubleshooting the circuit, and rebuild whatever requires rebuilding.

Of course, if you follow the first impulse, then you have truly wasted time, effort and money.
But if you troubleshoot and rebuild, and this time you succeed in making the project work, I can assure you that you will have acquired additional knowledge and experience which previously you did not have.

A very pragmatic mentor, once told me that the hard-learned experience is the one that you will never forget. The wisdom that you acquire with failure, cannot be read from textbooks or by attending lectures.

Having said this...nobody likes failure. Its hard. Its disappointing. It hurts your pride.

[Fred27]

Are you creating these projects for work, or are they just a fun hobby? This makes a lot of difference as to the real goal of the project.

Obviously, if it's your job then failing to complete things is indeed a failure. If it's a hobby then you can argue that the end goal of the project is to spent your time in an enjoyable way and perhaps to learn something along the way. Did you achieve that? If you did, then the project is a success. You need not feel bad about moving on to a project if you have achieved what you wanted to.

Having said that, it is nice to complete some of your projects! Personally, I find that I get some good motivation out of contests and competitions such as those on Instrutables. It give you a target completion date and a need to get things into a state where it's ready to be shown to the world. Project14 over on element14 also has the benefit that you announce the project up front, so there's less chance of abandoning it. (I'm in the middle of my first Project 14 entry right now if you're interested.)

[jaromir]

Why?!

For me, hobby projects are means of fighting some interesting problems I set up for myself. As for every fight, basic fighter etiquette applies.
Once the problem is knocked to ground (the circuit somehow works on breadboard, crap quality level code is barely running) I just stop fighting. It's called fair game.

[German_EE]

I was guilty of this but now I have an easy system to beat it.

One project in the finishing off / debugging stage but usable in its present state with a proper front panel.

One project being built and ONLY one. This bit takes some willpower.

Any number of projects in the design stage. Existing components may be put aside here but no components are purchased and each project has its own box containing paperwork and components that have been set aside until the build stage.

[SiliconWizard]

Yes, I think most of us are essentially problem solvers. Once the problem is solved, your drive plummets. You can discipline yourself to finish a project, but I don't think there is much you can do about your drive/interest itself if you are in that category.

Of course in a professional setting, this is a problem. For hobby projects, it's up to you to decide whether it is. You essentially need an additional motivator: in your job, the motivator is usually obvious (feeling part of a team, but also fear of getting a bad rep, losing your job, ...) For hobby stuff, you may find an external motivator if you (or better yet, a relative) will make use of what you designed. This is what works in my experience.

[james_s]

I find that once I get something working, my interest in it drops, and I've always got ideas for other new and interesting projects flying around in my head. I do regularly finish my hobby projects but often I set them aside to work on some other project then eventually pull it back out some years later and wrap it up. Frequently I delay the mounting everything in a nice box with a proper front panel part because it's tedious and messy compared to debugging and soldering.

[German_EE]

A P.S.

I know of one local hobbyist who is terrible at finishing projects. Two or three of his devices have boxes, nice front panels, and the original solderless breadboard inside fixed to the case with silicone.

[ebastler]

Because starting is the fun part, finishing is the tedious boring part.

It's a corollary of the 90/90 rule. (You know: "The first 90% of a project take 90% of the time. The remaining 10% take the other 90% of the time.")

Slogging through all the details of actually finishing and polishing a project, when you feel that it should be long done by now, is not fun...

[schmitt trigger]

I hadn't previously heard the 90/90 rule, but it is very true.

Have added it to my engineering lexicon...

[james_s]

I should also mention that sometimes a project doesn't work because it turns out I just don't yet have the knowledge required to finish it, these I sometimes set aside and return to later when I'm older, wiser and more experienced.

Other times projects get placed on hold while I look for the parts I need. I have several right now awaiting the perfect enclosure, that can be a tricky one.

[NorthGuy]

I don't feel that way.

I have several unfinished projects and I can't wait until I get time to finish them.

[bsfeechannel]

Why?!

'Cause projects are recursive. Like Inception (the film). You start a project, and inside a project you suddenly find other projects, which can contain projects. Then you give up  and start a new project, which will contain other projects, and so on and so forth.

I decided to design and build an analog scope with a NOS CRT I have. I bought many of the things to start the project. But before I even started this project, I decided to build an old school signal generator to go with it. The oscillator is working OK, except that to go from 100KHz, to 100MHz, it needs a special wafer band switch that, at the same time it selects a coil, it shorts out all the others. So I decided to convert one of the wafer switches I have into the band switch I need, and that's become a project.

[Tomorokoshi]

Why?!

'Cause projects are recursive. Like Inception (the film).
...

Kind of like this!
https://en.wikipedia.org/wiki/One_Cut_of_the_Dead

Definitely recommended.

[legacy]

I don't feel that way.
I have several unfinished projects and I can't wait until I get time to finish them.

me too.

for example, I have been working to the arise-v2 softcore & its ecosystem for 5 years and split it into submodules, all still work in progress and far from being completed yet.

I feel it's a natural process, especially if you schedule them during your weekends, which implies you have other things to do, so you have to freeze and resume, freeze and resume, and this adds overhead.

[legacy]

'Cause projects are recursive. Like Inception (the film). You start a project, and inside a project you suddenly find other projects, which can contain projects. Then you give up  and start a new project, which will contain other projects, and so on and so forth.

exactly my case

[sleemanj]

For me it's because the project I've been working on has got sufficiently far enough that "I know how to do it all from here on out and know it will work", once I know how to do it, the interest wains, the next project I don't know how to do it all so that's more interesting, there is a puzzle to be solved, thinking to be done, experimenting, testing...

Same with programming, hardware, whatever, once I've got it to the stage where it's all laid out in my head in sequence of what must be done and I know it will work... I lose motivation to actually do it, eventually it winds up in a plastic container on a shelf.

[emece67]

.

[GlennSprigg]

I've always (jokingly!) liked the amended 'adage'......
"If first you don't succeed...   Then remove all evidence that you tried!!"   

When 'programming' though, I always use the 'Top-Down' approach, to keep interest/feedback.
What I mean, is that most of my 'coding' is greatly associated with a Graphical  /  I/O  interfaces
.
So if I KNOW that what I write will work, (eventually!), then I start with the graphics & visual layout.
I get self-gratifying 'feedback', by constantly referencing a 'working' result, & giving me new ideas.
Then, in vastly simplified 'blocks', I create a (obviously) 'WorkFlow' diagram, breaking it down to very
simplified blocks of code, handling even 'dummy' I/O calls, to test the 'Output'.... "Yea... looks good!".
And only getting into the REAL, 'heavy' SubRoutines/Blocks of real 'coding' in the final stages !!

Otherwise, I get bogged down with the technical semantics, which while 'important', leaves too big
a gap to any sort of visual/mental reward!!!  Like someone working on a production line making some
little parts, and not seeing the end manufactured Machine, in use, and feeling important !!
So my 'coding' ALWAYS works, with results, at any stage. It just gets 'better'