I have problems developing my personal projects because I don't have deadlines, so I rarely find time to pursue them and when I finally find some time I usually find myself "perfecting" the code instead of adding more meat.
In contrast, my for-pay projects are less than perfect but work to the customer's satisfaction, earn my pay and are reasonably maintainable.
So the question is, can software be developed without deadlines? And if not how do you set deadlines ("artificial" ones).
In job ads I have seen this term "self motivated", and I guess most of us are enough self motivated to complete our jobs unless pushed.
You can develop without deadlines. But not many customers will like that.
Besides, if you don't have a deadline, you don't need to apply priorities. And then it is al to easy to lose lots of time adding fun features that are not really required.
Good deadlines keep you sharp and focussed, Bad deadlines make you stressed and frustrated.
For good commercial software - NO, you need deadlines. Even if you will develope super high quality softare without deadlines, your competitors will be a far way ahead; even with a better quality you just won't be able to compete with them. No deadlines means a very deferred release date.
Depends on the outcome you're expecting to get. Maybe you're working on your own project and get satisfaction doing just coding work and don't care about release date, then why not? :-) Why you need all that stress in this scenario? Nobody prevents you from setting priorities even without deadlines.
BTW, are there any strict deadlines in majority of OSS projects? I don't think so
If there is no pressure, there is less likely you'll have a result. If you work alone on a pet project and you have no deadline, it is still possible, if you are disciplined enough to "fool" yourself with an artificial deadline. If there is a team that knows there is no deadline, the chances to complete the project decrease dramatically, because the developer's tendency to make the code beautiful, more "elegant", etc. And because of the "student" syndrome.
One good technique is to use time-boxing. This means that you release your project at the end of a fixed length time-box, e.g. of 1 month. Within this time-box you do everything that is required to release a project, i.e. design the features, implement them, test, document. If you have too many features that will not fit into a time-box you simply skip them and do them in the next time-box.
Why do you develop personal project? Certainly you have a need to satisfy. The deadline for this need may guide you to fix a deadline to the software project.
Another advice would be to make your projects public, so you have a community waiting for the latest improvements.
You shouldn't destroy your valuable personal time to stay on the computer longer, and that's probably why you're not progressing. I know that my personal projects aren't progressing very fast, and right now I'm blaming it on not having a 24" monitor (yes, I know it's a poor excuse, but my midweek situation leaves me with a 12" iBook in the evenings) and beer.
However if you set yourself goalposts to achieve, rather than shorter term deadlines, and don't beat yourself up if you don't get so far, then I think you can move along. Or maybe your personal project isn't actually keeping you as engrossed as you thought it would.
You do not necessarily need deadlines, but at least reasonable goals. If your next milestone is to release the perfect application, be sure that it will never be released. If you aim for "feature A and first part of feature B to be done in 4 weeks", you have your chances :)
There's some interesting discussion around deadlines and Agile development in this article by a Google guy.
Longish, but worth a read.
Obviously what works for Google won't work for everyone. But there's a point to be made that one can be disciplined without deadlines - lack of deadlines isn't an excuse not to push to deliver.
Realistically no, because no client (independant or internal) would ever accept that. The first step in management is risk, which is inextricably bound to timelines.
A better way forward is to start working to an agile schedule (actual flavour of agile is up to you). As a massive generalisation, agile is about iterative development. Actual end-points become less important relative to small, next-step milestones. You should find that a natural step forward from where you are now.
I think they can, as long as:
Money is not a problem. Which is almost never.
You don't have to fill some gap in today's market before a competitor does it (in case of some in-house product)
Personally, my experiences are the other way around. The last stretches of a project are usually the hardest, as deadlines approach. During this time, often (not always) your code becomes slightly less maintainable / readable, you get the idea.
For my personal projects, I do see some of the things you encounter. You just don't feel like working on them since you already worked 40+ hours that week, and if you do, you are distracted to "perfect" some code that in the end, hardly mattered.
Though I think the latter usually comes down to discipline and good planning.
Of course! Just look at Duke Nukem Forever...
If I where to give a more serious advice I would recommend trying to follow the "release early, release often" mantra used by many. Read Getting Real (free online) and you will probably learn how to get yourself to do this as well.
The problem with having no deadlines is that essentially you remove any 'cost' from development. If my boss asks me to incude an extra feature I can push back by saying 'well, you can have it, but it meansthe release will slip a week'. Without deadlines you lose that ability, so development esesntially becomes endless. The horror....
Depends. The problem if there is no deadline is that your project may be prone to feature creep, aka. infinite rifinery, aka. perfectionism. Hey, let's adda fancy icon there, and a gloss effect here, and I think that these 23 Options should be customizable through the config file, and through the GUI. And why can't it read e-mail? POP3 is simple, so let's add this feature as well, along with an RSS Aggregator!
With a deadline, you are often forced to ship, which can be good. I also found that in crunch mode, there is a lot more focus to get the existing functionality bug-free (as much as possible) and to finally get the product out of the door, instead of infinitely iterating over it.
If you got the discipline, then deadlines may not needed. But in many cases, deadlines also serve as the light at the end of the tunnel.
Yes. Agile projects, and Scrum in particular do exactly that. There's an periodic "end of sprint" moment, when the software should be stable again. This happens typically every few weeks. The goal is to have as many new features in at the end of the sprint. This works in commercial environments, too: your client can pay per new feature, and at the end of each sprint he has a working product. Clients are generally happy with the knowledge that they reaslistaclly can terminate the development project early without writing off all investments.
It has nothing to do with deadlines. It's all about time.
If you switch and develop your personal project during your working hours and all customer projects in the evening you will find that you will not be able to finish customer projects even with deadlines set.
Time == money.
Literally. Most developers get paid a salary, so the cost of developing software is directly proportional to the amount of time and number of developers working on the product. The longer a project takes to complete, the more it costs. This changes the potential profitibality of your product.
The later you ship, the more successful your product has to be.
Shipping later means greater development cost, which means your product has to bring in more revenue in order to achieve the same level of profit margin. If you are confident in your developers, development process, product, and market this can be a worthwhile proposition. This is what Blizzard and Valve do with regard to game development. They wait to ship games until they feel they are ready, not on some fixed schedule. But they are also extremely disciplined and expert at development and are able to bring high-quality, top-tier products to market on reasonable schedules. Their seeming schedule laxity is not much of an issue for them because they are able to deliver enormously successful products that more than make up for the extra development cost in extra revenue. But not all companies have the talent to operate this way.
Will you ever ship?
One of the major risks of allowing schedule laxity is that it can balloon into sheer laziness where product development stalls and the ship date falls off into the hazy, indeterminate future. It requires a good development process, solid leadership, and continually making progress and hitting development milestones in order to put out a solid release, even when you may have a great degree of laxity on when you hit various milestones and when you ship. If you have a flexibly ship date then that allows you to take the time to do things like rework fundamental designs, or fix key defects, or pay down technical debt the right way rather than slapping together kludges in order to get a release out the door. But the boat still needs to be going from horizon to horizon every day of the release cycle, otherwise it'll just stay at sea forever.
theres a wonderful book which covers this topic: Deadline
nice to read too
I have done this in the past but I used to divide my development into cycles and keep a monthly or weekly or biweekly cycle and then segregate the items that I need based on achievability but would plan to achieve all of them towards the end of the yearly / bi yearly project.. .try this approach... this might work for you.. Andy
If I were you I would just setup a TDD environment, do all the tests that match the requirements that you need to fulfill, that way when all tests pass you are done. This way instead of having a deadline that is driving you, you will have a fixed set of goals that determine when you are done.
Of course software can be developed without deadlines, in fact I reckon the best software comes from developers who choose when to deliver. An external deadline is rarely more than a line in the sand which the dev team is coerced to meet with a release of some kind. That probably doesn't make for good software, and certainly doesn't make great software. The key is getting customers, managers, and owners to buy into giving the dev team control.
You develop your personal projects for fun so keep it that way, you don't need deadlines.
Deadlines depends on the people, I hate deadlines they make me nervous and I actually work better when I don't have deadlines. You can be someone like me, therefore just ignore everything about the time. But still keep a todo list obviously and have list of things that you are going to do.
Obviously to keep the fun and joy of development rearrange your todo list whenever you feel like it.
Yes, you don't need deadlines. You do need goals, and to keep focus on those. That's really hard to achieve if the goals are big. To keep focus, you need to understand what's most important at the moment.
Using time boxing with more specific goals helps with this, as you need to understand on what you will be focusing in the next time block. These are not deadlines as you don't have to meet all those mini goals, but its where all the effort needs to go into. As I said, its a matter of focus.
I do weekly sprints. While in some projects/clients we need to have an overall picture, there are some cases where we just go on with the sprints, based on: what is the very next we need to build/release.
I focus all my efforts in the current goals. Now, that doesn't mean trying to go faster by skipping stuff, and going slower at the end. It does however, means being practical about how you are developing.
I think the issue you have with those projects is probably more a combination of:
Update: As was pointed in John's answer, Duke Nukem Forever is a good example. It actually went in both approaches, at some time it had a supposed deadline, and during another very long period of time didn't have a deadline anymore. Regardless, it hasn't been released after many years.
It reminds you that you can fail in both cases, using deadlines or not. If you have something too big in your hands, break it into pieces you can release independently. That may not be possible in all scenarios, but in that case you have to ask yourself if you have the time/money to invest in such a long project.
Update 2: As I mentioned in comment on Alphaneo's answer:
The presence of a deadline alone won't guarantee that you get a team continually focused. Consider if you grab untrained devs and put them all together on a big project (as in long in time) and set a deadline. They will get on it, and at some point in time will loose focus. Later on the deadline is coming, and they will rush.
Now grab the same team, and every 2 weeks set some goals with clear priorities. You don't have to make them deadlines, some goals that we want to achieve, but some of which might be missed. Review what have been achieved, give feedback, question why something wasn't met, give congrats successes.
Which one of both approaches above do you think will give better results?
Small, tangible goals are much more important than deadlines for personal projects. Each time you sit down to program, make a decision whether tonight is going to be dedicated to adding a specific feature, refactoring a specific portion of the code, documenting some aspect of the system, or achieving some other specific goal.
If, by the end of the night, you haven't achieved your goal, it may be that your goal was too lofty. Try breaking it up into 2 or more smaller goals before you call it a night. That way, you can still say you accomplished something, and you've set yourself up to succeed.
Once you accomplish your goal, write it down in a log or as a repository comment: this will give you a way to look back at your achievements and smile. :)
This happen with me also.
When you write your own projects, you feel free, to complete them when you want. you also look for better quality, after all you are doing it for yourself. However when you work for some one, you are more interested for the money than the project itself.
But if you won't make strict deadlines, you may finish but not finishing anything. Then Deadlines are a must, perfecting your code and design can be done after a final release.
I think it's ill-advised to develop without deadlines. Most exemplary projects without deadlines are video games, and they're a unique mix of art and science, where some perfectionism is expected and sometimes beneficial -- but the actual benefit derived from the aimless development cycle is debatable; there are both positive and negative examples.
In my experience, this doesn't work very well for enterprise software or other types of projects. Developers are usually much less enthusiastic and deeply invested in non-video-games. When your project straddles the boundaries and serves as a hybrid of science and art, you generally get a lot of ardent proponents and dedicated craftsmen; when your project runs your client's storefront, it's a little harder to motivate people, and you usually have a whole different cross-section of background, motivations, and temperaments.
So, on projects with the right kind of staff, this is possible, but it's benefits are dubious and in most cases you won't be able to keep it up. It's far advisable to use real-life, solid deadlines and stick to the timeline.
I've just found this interesting note from a famous developer; John Carmack of id Software : http://en.wikipedia.org/wiki/John_D._Carmack
Professional philosophy
As a game developer, Carmack stands apart from many of his contemporaries by avoiding commitment to a final release date for any game he is developing. Instead, when asked for a release date on a new title, Carmack will usually reply that the game will be released "when it's done."[5] Employees at Apogee, in their past years the publishers of games by id Software, adopted this business practice as well.[6]
Open source projects rarely have deadlines, and many of them are of the highest quality. So yes, (good) software can be developed without deadlines. For personal projects, even if you set your own deadline it may not help, since there are no consequences for not meeting the deadline. You may need to creatively come up with some other (external) motivators, or just accept that you'll never be all that productive on your personal projects.