17

Some time ago I wrote a very small python script that periodically checked an xml feed for new entries, and alerted the user to new entries when present. I wrote this for myself, so it was essentially a console based program that anyone comfortable with a console interface could have used.

After a while I decided it could be of more use to other people and began to tidy it up, sanitize inputs, remove bugs. It occurred to me that because I'd written the script I knew how to use it efficiently, accurately etc. Others might not, so I started adding a GUI. This started out as a simple menu, and then expanded to a more full GUI with both an interface and options menu. I then added stored user preferences and also storage for previously searched xml feeds to speed up repeat searches.

I added logging to help debug the application in case things go wrong, brought the application up to the latest available stable python codebase for my chosen platform and improved dialog features.

I've bugfixed and commented my code clearly, and yet I still have things I think can be done to improve the app before I make it available to alpha testers. It's a far far cry from my original 20-30 line script. What I anticipated would take me just an hour or two to go from proof of concept to an acceptable use program has taken 10-20 times that. (I'm still a noob, and stuff takes me a long time, but still....)

How do you know when to stop adding/tweaking/fixing stuff and let your baby crawl out in the open?

Improve this question
0

9 Answers 9

Reset to default
8

When you hit the deadline.

If you have no deadline, this is your problem...

Here is how I work:

  1. I add new features/bugs in my product backlog.
  2. I prioritize the whole product backlog on business value and estimated (the last is optional in case of personnal project).
  3. I allocate work time to myself. The release date is the end of that time.
  4. I start with the very first in the list. I work on a feature a time. To be completed, a feature must be really complete including documentation (at the end of a feature, I can potentially ship the product).
  5. I take the next one until my allocated time is consumed.
  6. If the time is consumed when I'm building a feature, I discard it temporaly.
  7. When the allocated time is consumed, I take the latest build and make a release with it.
  8. I repeat the process from point 1.
Improve this answer
6
  • Hmm I like the workflow here a lot. This is a hobby project, I'm not sure I'll try to monetise it, it's more likely to be offered free or made open source.
    – fearoffours
    Oct 18, 2010 at 9:45
  • 5
    Value doesn't mean money in the suggest workflow above. You decide what is the value.
    – user2567
    Oct 18, 2010 at 9:48
  • OK this is awesome. I've been applying this since I saw the post earlier today. My deadline is Wednesday 3pm, and things are going well! I feel more confident about where stuff is going and what Im working on. I've prioritised (in comments at the top of the script) stuff to be done prior to this release, and stuff that can be left till later. And I'm writing down the feature I'm currently working on to ensure I remain focussed on a task at a time. Thanks!
    – fearoffours
    Oct 18, 2010 at 16:12
  • 3. I allocate work time to myself. The release date is the end of that time. @Pierre 303, When you said time did you mean by hours i.e. nightly builds? or time like a full sprint?
    – Ken D
    Mar 3, 2011 at 8:32
  • @LordCover: For example I assign me 3 weeks (5 days a week 8h a day) to work on the product. I ship at the end of the 3 weeks.
    – user2567
    Mar 3, 2011 at 10:20
3

Make a SRS then code according to the requirements. When you've achieved all the goals mentioned in the SRS it's time to stop and test your product.

Improve this answer
3
  • Hm good point. I have nothing written down about it's purpose at the moment.
    – fearoffours
    Oct 18, 2010 at 9:46
  • SRS are good but for a single man team on a personal project a bit overkill. Documentation is good but for this type of project I do not think all of an SRS is needed just yet.
    – Chris
    Oct 18, 2010 at 10:27
  • @Chris - An SRS is always a good thing. What is a personal project and released for free today, is still a free peice of software and written by dozens of people. A great example of why documentation is important Facebook, it was fair easier to write the documentation in the early stages and update that documentation then it would be to write it today. If you cannot write down your design, explain the design, documentation how the the feature works then how can you code it?
    – Ramhound
    Feb 25, 2011 at 20:09
2

In the short term, when you have something that works reliably and doesn't crash out. Even if it doesn't do everything it could do if you worked on it indefinitely. Shipping as the saying goes is a feature. Reliability and restricted feature set gives you an opportunity for the core functionality to be tested by real people in the real world, who will find things that you never thought of that break your code in ways that would never cross your mind. The less features you have, at this point, the easier it will be to fix those early problems. As the core functionality works more reliably you can start implementing the other "nice to have" stuff with the knowledge that your most important and central code still works well.

In the long term: When you have completed and documented the plug-in system that will allow your users ( and of course you ) to implement new features quickly and easily if you need them. That should be the last feature you need to add- after that it's all plug-ins.

Improve this answer
1

When you are sure about the stability of your software go for a release though there can be pending features. Stability is more important than features. Get the feedback, incorporate with existing features and decide on what has to be delivered next and when!

Improve this answer
1

You can always nurse a project for ever and ever.

A very good rule is that you should never add things that are not in an approved use case. This ensures that you don't end up with a lot of things that would be nice to have, but which nobody uses. Approving ensures that others than you agree that this is needed in your project.

Improve this answer
1

It depends on why you're adding features. Are project owners asking for it? users? QA?programmers?

  • Add the features you have to.
  • Sift through features that are important.
  • Ignore features that are nice to have.

Focus on the program's purpose, and make its purpose focused. Feature requests that extend its purpose should be questioned thoroughly before it becomes a swiss army knife.

Improve this answer
3
  • I like the idea of keeping a product focussed. I am trying to do that, and still find ways to occupy myself!
    – fearoffours
    Oct 18, 2010 at 9:44
  • 2
    @fearoffours, You can always find ways to make your own work better. The point is to find out from the users how to make it work better for them. Solve real obstacles. Smooth real rough spots.
    – Huperniketes
    Oct 18, 2010 at 9:47
  • nice advice in that comment, (+1) thanks!
    – fearoffours
    Oct 18, 2010 at 10:23
0

I dont stop adding features anymore. I just try to get the app out there ASAP and write txt files if i need to. Then i can decide when to stop and when to work on something different

It also helps that i like doing the min possible to get something done (without resorting to hacking).

Improve this answer
0

I'd suggest you timebox it. Give yourself a say week. Create a list of work to complete during that week, and make sure if you have a feature you can't complete you can back it out.

At the end of the week release it. Release early, release often.

Improve this answer
1
  • but what to do when some features have dependency on each other?
    – Ken D
    Mar 3, 2011 at 8:38
0

When you've got something reliable and useful, release. You don't have to stop adding features, but if anybody's using what you've got out there you'll get a much better idea of what features are wanted. Currently, you're guessing.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.