Longest Development Project

[A Scottish moose]

Currently working on the last few features of a tester and had an idea to ask about projects that either took way longer than they should have or when you reached burnout and still had tons of implementation and testing work to be completed.

 

What's the longest project you've worked on or projects where you hit burnout way before the end.  How did you keep up motivation and keep slogging through it to completion?

 

Might be interesting to hear peoples thoughts on getting through those long projects or the last few weeks/months of a project when things seem to take forever.

 

Cheers,

 

Tim

[ShaunR]

This isn't really an issue with agile development-a project can last decades as long as the Product Owner keeps feeding the loop. It used to happen a lot with linear (e.g. waterfall) style projects but agile, with iterative development!, means you get concrete and tested software regularly throughout the life-cycle. That's good for merging changing requirements which keeps things fresh and interesting as well as no "oh god I hope it passes acceptance because there is only two weeks left" after months of work.

I haven't used linear development for over a decade.

Edited July 8, 2017 by ShaunR

[A Scottish moose]

This is an interesting point.  I haven't worked in an agile environment yet.  As I've started to get some projects under my belt I can see how it would be valuable and how it would help to avoid some of those traditional pitfalls.  Agile also forces an interaction more often (than a waterfall or gated model) between developer and customer and reduces the 'please let this work so I don't look like an idiot' situations.  Or perhaps it just makes them lower stakes?  Either way I think it makes the process better for all parties involved.

Thanks for the thought!

[hooovahh]

I definitely get what you mean by burning out.  Even on project that is long, it is easy for me to lose interest.  With LabVIEW it always feels like getting 90% complete is pretty easy, quick, and there are plenty of results to see.  That last 10% seems to take so long to wrap up, and so much work that I find myself just putting it off and doing other work instead.  Of course when timelines are involved, and you need to actually work on it, it is hard to stay motivated.  Maybe its hard because I enjoy doing LabVIEW and it doesn't feel like work when its fun, but when it isn't fun it is a drag.

For large multi member projects it gets a little better since you can all share in the accomplishments of everyone, so staying motivated is easier.  From a program management stand point I've seen plenty of projects eat up 8 or more developers full time for months (years?) more than originally planned due to poor management, and unclear requirements.  Those are pretty bad sometimes too because the moral of the team is poor.  Constantly getting beat up, while working hard can make good people want to quit.

[ShaunR]

3 hours ago, hooovahh said:

I definitely get what you mean by burning out.  Even on project that is long, it is easy for me to lose interest.  With LabVIEW it always feels like getting 90% complete is pretty easy, quick, and there are plenty of results to see.  That last 10% seems to take so long to wrap up, and so much work that I find myself just putting it off and doing other work instead.

I don't have a problem with that (the old saying the last 10% of a project is 90% of the work ). I just treat it as refactoring and optimization.

It's the documentation that grinds me down -  Help files,user manuals, application notes et.al.I'd rather have one Technical Author on a project than 2 extra programmers.

[A Scottish moose]

2 hours ago, ShaunR said:

I don't have a problem with that (the old saying the last 10% of a project is 90% of the work ). I just treat it as refactoring and optimization.

It's the documentation that grinds me down -  Help files,user manuals, application notes et.al.I'd rather have one Technical Author on a project than 2 extra programmers.

what is this 'user manual' you speak of?

[hooovahh]

I usually try to call it a Quick Start Guide, to help set expectations low.  Then if things are missing the user just shrugs it off and figures there is a more detailed manual (which there will be when I finish it).  I do a decent amount of documentation as I go, which probably isn't efficient since I'm often updating how things actually are.  I don't really find the documentation part dragging on.  Oh and I've been asked how long it will take to get a program up and running, and they will sometimes qualify it with.  "How long will it take to get 90% of the program done" and I'll say something like "In two weeks I can get the first 90% of the program done, and then all that's left is to do the last 90%."

[ShaunR]

38 minutes ago, A Scottish moose said:

what is this 'user manual' you speak of?

It's the thing you point to when someone says they've  found a bug

[smithd]

17 hours ago, hooovahh said:

I usually try to call it a Quick Start Guide, to help set expectations low.  Then if things are missing the user just shrugs it off and figures there is a more detailed manual (which there will be when I finish it). 

Interesting, you have users who bother to read your documentation? Most documentation i write is for the purpose of checking a box on someones checklist. 

19 hours ago, ShaunR said:

It's the documentation that grinds me down -  Help files,user manuals, application notes et.al.I'd rather have one Technical Author on a project than 2 extra programmers.

And I think this is the problem. Its hard to write useful documentation for something you're actively working on. The right answer is another programmer, but since everyone hates making documentation you can't do that. Unless you have a fairly big organization behind you, I imagine its difficult to get a tech writer and my experience with tech writers has been that they are not tech enough anyway. So you end up writing something that only makes sense to you.

 

To answer the original question, most projects I work on or either short or never end. It does help to break things down into milestones and deliverables and all that...and the reality is that there are some weeks where I don't do a ton because i just feel blegh about the project, so I work on something else or pick off old minor issues to feel like I'm accomplishing something.

Edited July 15, 2017 by smithd

[Tim_S]

On 7/14/2017 at 5:29 PM, smithd said:

Interesting, you have users who bother to read your documentation? Most documentation i write is for the purpose of checking a box on someones checklist. 

My customers in China require the translated manuals before we do training so they can read them in entirety. Maintenance tends to keep a copy for their tasks (some related to software). Otherwise we do a lot of 'well, let's look at the manual... ah here on page...' to discover the dead-tree manuals are long ago lost/recycled.