Creating New Program Versions
toolbar-separator.png This article is part of the refreshing stage of the development cycle.

After you’ve published the first version of your program, your next consideration should be whether to embark on a different project or continue with your newly finished program. You need to decide whether your program is worth the updating, or it should be allowed to remain dormant. If you think you should update your program, you need to decide what should change about the program. What features you should, add what you should remove. This tutorial will help you in your considerations about this dilemma.

Making the Decision

After you make a program, give it some time to brew in the community, people need to be able to see a piece of software and work with it before they can handle another. If you barrage people with a new version every week, so that it is practically impossible to see the program before it is obsolete. The amount of time that you give to update will help you gauge whether or not updating is a good idea. The more time you wait you will receive emails with bug reports and suggestions, the download count will go up, and perhaps even reviews will be made of your program.
These can all be indicators that you should update your program. But the decision could be hard and here is a list of suggestions of what to think about when deciding to update:

  • Is your program being downloaded? There are two answers to this and two main ways of thinking about each. If it is not being downloaded, perhaps it was an effort that was futile and won’t work, or if you create a new version, the downloads will go up. If it is receiving downloads, then that is a sign that it is doing well and it is fine how it is, or you might think that the downloads might spike even more with an update.
  • Have you received emails about your program? Positive or negative, these are a good sign. If you have received them that means that the community cares about your project and finds interest in its development. This is usually a good factor in your decision.
  • Will your program benefit from and update? Think about your program, it’s speed, size, features, etc. Could you expand upon these? Did you have plans for features of your program that you never got around to implementing in the first version? If you believe could improve significantly from an update, then it is probably a good sign that you should update your program.
  • Will you benefit from updating your program? Let’s face it. You’re programming on a graphing calculator, your program is not going to be used for any truly serious purpose. That’s what computer programming is for. So the last question you should be asking yourself is whether you as the programmer will benefit and learn and expand from the new version. Will it challenge you and push your limits? If yes, than that is the last straw, updating is almost definitely a good idea. If not, don’t worry, find a different project that will incite your interest and push you to new heights.

After asking yourself these questions, time to make a decision. The last two questions are probably the most important in your decision. Even if your answer to the first two is no, it might just be because your program doesn’t have what it takes to make the limelight. It would then benefit from an update, making the answer to number three, a yes. Then you have to decide if number four is a yes. Whether four is important to you or not is your decision, but if it is it should be a large part of your decision.

How to Update

When you update your program there are several factors you need to consider about your updated program. What features you should add, and what to remove. What parts of the program run slower than you would like and how to remedy this.
Updating is difficult and to add onto that difficulty, often times large chunks of your code or even your whole program itself may have to be rewritten. But don’t despair, even if you do have to do rewrites, you have done similar coding before and can make it work better. Rewrites are recommended because the editing of current code has many downsides. Namely, it is difficult to do, and the end result tends to produce more bulky and poorly written code, than if the code was written from scratch and thought out from the beginning. Don’t worry if you have to start planning parts or even all of your program again, this is entirely natural. The better you make it, the easier it will be to update to future versions.
Time to decide what to keep and to remove.

Deciding on Features

Here are some tips on adding and removing features that the community will appreciate.

  • Listen to what people have told you and take it to heart. They are the community after all.
  • Remove features that are really glitzy and don’t add a whole lot to the program. Aesthetics are fine but don’t go too far. (e.g. People love good graphics, but grayscale is slow, unnecessary, and doesn’t look good in basic.)
  • Add features that are truly innovative and haven’t been done before. These are difficult to think of, but make the true selling point for your program.
  • Add the best features of other programs that are similar to your program. Idea sharing is perfectly legal, and most ideas are in the public domain anyways and can’t be claimed by any particular party.
  • Don’t add features that are going to weigh down your program. It’s not worth it.
  • Think about who you want to market this to, this will help you think about the portability of your program.
  • Above all, add features that are user-friendly. Usability is arguably the most important part of your program. Think carefully about your audience. Is it the average user who only knows how to send the program to their calculator? Is it an advanced programmer, using it to develop their own programs? This will help you gauge what your user-friendliness needs to be.

Think about these points and then write down a list of them, or whatever helps you remember and keep them catalogued. If you didn’t do this for the last version, do it now and draw some sort of chart, a flow chart for example, of how all the features of your program will link together and work together. Then you can start to really understand how it will work. You have essentially finished the planning stage. You can continue with more tips from the planning tutorial, but you can start to code.

After this, you are mostly done with the refreshing process. Now you can continue back through the development cycle and produce another version and then come right back to this article which will still apply. (You can most likely skip the planning stage, but it might not be a bad idea to look at.) This stage and decision whether or not to continue ends each loop of the development cycle.

<< Releasing Your Program Overview Planning >>


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License