Commercial And Professional Development Part Seven


Part Seven - Project Maintenance And Future


Welcome to the seventh and final part of the series on commercial and professional software development. As I introduced in the sixth part of the series, this final part will essentially be about software maintenance and the future of of software projects. As I said, a programming project, whether it's a game or an application is never quite finished. It seems there's always that one last thing you want to add, that one last little thing. Problem is often, you get another idea after that last thing you had before and the list just keeps getting longer.

One of the biggest questions when you're creating your own game or application project is essentially where to draw the line. You often find yourself adding to your list and that can often bring you to a place where you'll never see version 1.0 of your project out because you'll always be adding to your program. This seventh part will try to give you some tips and tricks in order to split features and fixes into versions and sub versions so you can get a grip on how to "logically" stop the development of a version and leave everything else to future versions. In other words, you'll learn where to draw the infamous version number lines. We'll also look at what maintenance is all about when it comes to software development. So let's start by looking at the maintenance of a project and then we'll look at the future of current projects.


The first thing I can tell you here is that main starts when you fix the first bug in your program. And that typically happens even before version 1.0 is out. The maintenance of a project is just that, fixing bugs, adding features when you or the users think of them. Project maintenance is an ongoing cycle that servers the purpose to keep the program running smoothly and/or updated when needed. Programs like payrolls and inventory might need constant maintenance to update tax rate tables or prices and so forth. In part five of the series I explained the different types of bugs and presented some software that were designed to help keep track of the bugs These systems, because of the way they are designed to handle bugs, often offer a great way to keep track of feature requests. The main reason for this is because they typically holds all the information you need to document a feature as well as you'd document a bug so it's a great way to organize features. Much like the bugs, features can also have levels of priorities attached to them. Some features can be critical to the operation at hand. Others can be almost insignificant but be important to the user that suggested it. hence, here is a great way to classify feature requests.

  • Essential Features: When you make a specific program, how good it is depends on exactly what you know of the program you're making. It's very possible that you skipped something that really should have been there in the first place. It all depends on who's giving you the information and if that information is complete. Hence people that know the business very well are the best type of people to tell you how your program should work. If they tell you that you forgot a whole set of steps to do this or that chances are you did forget it. Some will tell you perhaps more abruptly than others, don't take it as critic per se. Just make it like it's supposed to be.
  • Popular Features: Again, This all depends on where you got your initial information about the type of program you are doing. There is such a thing as a set of highly in demand features I like to call them. If you got your information right the first time, chances are you probably have alot of (maybe even most of) these popular features. But some of these popular features can be very specific and sometimes unexpectedly useful. So when you get them, they definitely deserve the 2nd most important level of priority since we can assume you made this program so your users would love to use it.
  • Design Features: These types of features are known as alternatives. This typically means that you've thought about the feature, it exists in your program but perhaps some of your users are just used to do this particular thing a different way. You made the program, but it doesn't mean your users don't have a say in it per se. I wouldn't implement every feature every time I get one right away. Especially those features meant to replace the current way you implemented a functionality. But if enough users request a similar feature then it might be time to reconsider the way you implemented it and give them what they want. This could also be to add a field of information on a form, and other things that add to the program's design and functionality. One last type of design feature might be to change terminology. You might have called something a report, they might prefer to refer to it as a list rather than a report. People in an industry are used to call things certain ways. And little things like adapting to their terminology shows a great degree of respect to your users (which all paying customers love to get).
  • Minor Features: These can be design features but very quick to implement like adding a keystroke to access a functionality or other quick things like that. They are the quickest to implement and even if it seems insignificant to you, they will be liked by your users. Once the program is done, you as a the programmer don't matter. If you want your users to buy your program (keep the business so to speak) you might want to consider implementing these, they're quick and they show your users that what they want matters.

These are the typical types of features you're likely to come across in the life of a software development project. None of them should be neglected as they all serve the purpose of answering the needs of your users. There are limits however. If a user tells you that all your program should be changed he/she atleast better have some indisputable reasons to tell you that. Very big features (like whole sub systems or complicated features) might also best be implemented in a subsequent version (as you'll see later in this document).

At this point, the maintenance has to consider what exactly is being maintained and for what reason. Because the type of request and it's complexity will determine which version they will be implemented in (if it does get implemented). So the combination of feature requests from your users (or from you) and the correction of bugs, together, consitutes the maintenance part of a software development project. Now, let's see how and when to draw the infamous version numbering line.


There's more than one reason to have more than one version of a project. Whatever the reason may be, there are ways to determine this. Hence, before we go any further, let's start by listing here what the different reasons may be for breaking down your project into several versions.

  • The Project Is Too Big For One Release Only: Let's face it, sometimes you get specifications that are just too big to do in one shot in a realistic kind of way. This is where the notion of project phases come into play. At this point you need to split the project into essential functionalities and wanted functionalities. I will give an example of this later in this document. But the main thing to remember here is to give the essential functionality in version 1.0 and the wanted functionality in subsequent versions. If there is alot of wanted functionality, a great way to break them down would be by grouping them in functional modules such as reporting, dafa entry and the likes so that you need to think about one thing at a time when implementing them.
  • The Project Needs To Keep Up With Reality: These are the types of projects that start off with a base of functionality as it is currently need with the knowledge that it will need to change on a regular basis because the needs may change that fast in that particular type of project. Knowing this in advance will make you code accordingly hence making your code very adaptable to new situations and needs because you already know they will need to change. Since in these cases it's very unlikely that the situation won't stop changing you can imagine that there will be alot of versions to come for this particular type of project.
  • Customers And Users Ask For Many <Maybe Too Many Things) To Add: This is the kind of situation that is often beyond your control. People use the program you made. They like it but they would love it so much if only it could do this or that. So being they paid to use your software, they won't be affraid to ask for things. You as the creator of this project probably need to do your best to give your paying customers what they want. Some of the requests can be done quickly but others can be quite long to implement.
  • Sequels To Gaming Projects: This one doesn't need alot of explaining as you can imagine. Why would you make a sequel to a game? I'll answer that by aking you why would they make a sequel to a movie? It's not uncommon to either make an ending to a game that just yells sequel out loud or to just create a new plot where your characters in an existing game fit in perfectly into this new plot. Imagination is the only real limit to gaming projects and I'm sure you know that imagination doesn't have that many limits. So Sequels can definitely happen and probably more often than you might imagine.

These are the four main reasons for future versions. There's others but typically they'll relate to one of these four. The main thing to remember is that when you do decide to split up a project in more than one version You have more than one reason to organize these versions and more than one way to do it. As most of the other parts of this series, an example is the best way to visualize some of these things. Hence let's take our now famous Finance CAD example and see how the maintenance phase and future of this project applies.


We already know the specifications that made the first version of Finance CAD. Since there's no users we will look at Finance CAD and see what we would like added to it for say version 2.0 (and any
sub sequent version if needed. As we described it so far it seems like a pretty complete application right? You'd be surprised to see the creativity of your users. So let's start enumerating some suggestions here and after, we'll take these and classify them accordingly to give you a real world example of how things might work.

  • Adding project management features so that reports on the creation of a house can be given by time interval and date as well as by construction phases if needed or desired.
  • Adding the ability to view the layout of the house in 3D to get a perspective view of the house.
  • Related to the previous one, adding textures and maps to use the textures on our 3D view of the house to make ot look realistic.
  • Ability to compare house plans scenarios (with costs related issues) so that we can pick the best way.
  • Addition of a physics engine to simulate and test the solidity of materials picked for the construction of a house.
  • Create an accounting system so that everything can be accounted for and billed for automatically.
  • Add a subtable to the items price list so that we can keep a history of the price changes.


These are just seven features and as you can see, they vary alot in degrees of complexity and involvement in the whole project. Of course there could be more features but this should be plenty to examplify what I mean by classification. So let's take each of these features, explain some of the details so we can what kind of feature it is as well as when and where to implement it.

  • Our first feature is project management features. What we want here is the ability to plan out the construction of house. Hence bring the notion of time (and related expenses) to the construction of the house so that when we estimate the cost of building the house we can now also include labor in the estimate. This has the ability to give a more complete picture of what it would really cost to build the house. This would typically mean the addition of certain fields in the database and a little design work to add the respective fields to be entered on the screens. It would also mean some basic time and date related functionality so that we can calculate the amount of time needed to build the house. So it's a simple feature to ask for but not all that simple to implemeent. It is, however, an important feature because of the added accuracy of the estimate.
  • The second and third feature will be combined together since they are so closely related to each other. This way the user will have the ability to view the house in wireframe 3D and/or texture rendered view (to give a more realistic view of the resulting house). This means adding fields to the database to accommodate for the 3D extra fields as well as material bitmaps needed for the rendering. Then comes the 3D engine to allow to view the house in actual 3D Now this is a very big feature of course and like the previous feature it would be a very wanted feature.
  • The ability to compare house building scenarios means the ability to take a house plan, define the types of materials used to build the house (hard wood floors versus tiled floor, 2 layer windows isntead of one layered window) and different things like that for building materials and be able to compare the prices of all of those based on the quantity of each materials used in the house plans. This can be a very useful information to you and the clients you are creating the house for. Give them budgeted options so that they can get the most features for the most affordable prices. This is a great feature, however it's nothing they can't do right now just by copying a house plan, changing the materials used and saving that as a different name, print both plans and see for themselves. Technically this means to add a scenarios table to the database that is attached to the main house layout. And adding some queries to interrogate this table when needed. It also means changes to the data entry screens to allow to add more than one set of materials used for a house plan. Medium size modification. Ultimately it could be implemented at any desired time.
  • The physics to test the solidity of a given material. Well this speaks for itself really. When you give the house the materials used for the construction. Once this is in place in the house layout you could, with the proper formulas, evaluate what the construction can take as far as abuse goes. This can depend on the materials used, the house (or building) structure as well as what kind of abuse that house could be subjected to (storms, tornadoes, hurricanes, earthquakes and the likes). This, like the 3D engine is a very big add on. But you know that not every single one of your customers will actually want this kind of evaluation on their house. Typically, the more expensive the building is to build, the more important this type of evaluation becomes. Hence, this is a cool feature to have, but not an absolute most, not yet anyways.
  • The Integrated Accounting System Built Right In. This is of course a personal feature request. Of course once the house is in the database it would be nice if every time you billed something for that house, or bought something from supplier for that house, if everything was automatically part of your accounting. You could then concentrate on what you like to do most. And leave the boring accounting part up to Finance CAD. To be sure, not everyone that might use Finance CAD will want this feature or even understand why it's in there. But it would be nice for your company. Hence this can wait since you probably already have people doing this part right now. It's a big alteration since alot of different modifications to the database are needed including the addition of several tables to accommodate for the accounting needs of the program. Plenty of new forms as well and let's not forget all the reports that will be needed for the accounting. Since it's not a crucial feature, just a wanted feature. This can wait as it shouldn't influence much on the success of Finance CAD as the tool it is.
  • Adding a sub table to the Items table to keep track of price changes as they occur. This is a quick feature to add. A couple queries, a small change on the Items Data entry screen and in related reports so that the prices used at the date the floor layouts were created can be retrieved and used as needed. It is a very useful feature because it eliminate a great deal of repetition (redundancy) in the table structures so this can be done as soon as possible and will be welcomed by most of your users. These are little details that not everybody thinks about so when they are indeed thought of, it just gives you that much better of an image. It's always good practice to show attention to details in your software creations and this is, in this case, a great way (and a quick way) to do just that.

And there you have, these are the details of the new features to add. As you can see, by knowing more of the details of these features we can already start to think differently about each of these features. Information, in any development project is always very important and plays crucial roles in the overall realization of the project itself. With this extra information at hand, let's classify our features and see when would be a good time to implement them.


Now that we have our feature requests defined, we can go ahead and define their order of realization. Is there any written rule on this? The answer is yes. Indeed, there's 2 main reasons to give a feature any priority. Priority will of course play a big role in how soon a feature is implemented in the future. One of them depends on the users the other depends on the programmers. Let's see what these reasons are.

  • The Feature Is Definitely Needed: By this I mean that the feature has the potential to become very crucial in the success of the project. This could be, for example a feature that all other competing products have but that you just didn't think of putting it in yet. It could be a feature that isn't in any other products that would help set your product apart from your competitors. Depending on the industry your project exists in, this kind of advantage might definitely be worth a second (or even third) consideration. If it's for your own personal non commercial project well that all depends on what you are willing and ready to do for your users. Nonetheless they shouldn't just be ignored or skipped over.
  • The Feature Can Become Popular: For applications, features that can help make your project popular will typically be features that make your project work better and faster. Time is money so anything that make your project work faster (hence save time) without making your project more complicated to use in the process are very likely to become very popular very fast. This is also something you should think about when creating the program initially. But sometimes, something you forgot about will resurface in the form of a feature request so then it's worth taking the time to implement.

From this point, the type of project you are making will influence alot of how certain features can be classified. But with these two guidelines you can begin to evaluate the importance of a given feature request. Now you need to add to that some business knowledge so that when you see a given feature you can evaluate if it applies to your project's intended purpose or not as well as if the feature should apply to it. Combining these two guidelines, the business knowledge and the types of features as described at the beginning of this document will give you the tools to position the features where they go in the future time line of your project. We will now illustrate this by taking each feature mentioned and described above their priority and realization order.


This might be because of my Visual Basic background so this section is a suggestion more than a rule per se. This means you may like and want to use this or you may want to forget the last element described here. This exists in more than one language so this is the version numbering method I like to use. A version number to me is separated in four elements. Each play a specific role in what I put where when it comes to product maintenance. Let's review these elements so you can see how I use them.

  • Major Version Number: This is the main version number. Basically this version changes when the specifications of the program changes dramatically. This does not include bug corrections as these belong in the revision and release numbers. This number stays at zero until everything in the specification and other documents that define what the application currently should do in version 1 are not completed. Once done though (and debugged of course) then you can say that you are at version 1.00.000a. In database applications anything that changes the structure of the database and it's relationships should be considered major changes as well.
  • Minor Version Number: This second part of the version number to me is for rather major changes that are still about the specifications as they were designed for the current version. In our example, the different way of doing things would be included as a minor version number for example. It changes the design but is aimed at accomplishing the same original task. As another example that commonly happens in the IT (Information technology) industry. Many times when you release your first version of a product one of the main thing you'll get asked for is to add new reports that are often very useful to the user. If this can be done with the existing information in the database them great it can be a minor change. But if this means adding a table (or two) hence adding data entry screens to accommodate the new table, changing and/or adding relationships to other tables then this should be done as a major change hence in the next major release. This is because there are users already using the current database structure as it is hence don't expect it to change on them because of a minor change to the program.
  • Revision Version Number: Revisions are bugs that can only be fix by bringing minor changes to the way things are currently done in the program. Or things that should have been there but aren't. These do not mean changes to the database or other major items. As an example, say you have a report done that should have expected a starting and ending date as it's input parameters. But for some reason you only have a starting date. Something was missed for some reason and the ending date isn't there on the report form. Then you need to add it because the report doesn't work without that ending date. No database changes, no major work to be done per se. just an input field to add to accommodate the ending date. Typically, revision level bugs (and release level bugs) are rather quick to find and fix. Not everyone uses the Revision level per se. I've seen people stop and the major and minor version numbers (Version 1.00 for example). I have also seen people skipping the revision but using the release letter (much like they would use the revision number so you would see something like version 1.00b).
  • Release Letter: The release letter are quick internal bugs. Hence there's nothing visually wrong with the program or the particular form they are using. But it just doesn't do the job it's supposed to. Could be due to anything. They are all very quick to fix, but sometimes can be a bit trickier to find. For example. You rounded off a percentage in a formula that shouldn't have been rounded off. Many of these types of bugs are better found by the people that use the program and know what to expect as results of those formulas. Because sometimes, you as a programmer might think it makes sense to round off that percentage and for all intents and purposes Other types of release level bugs can be much more direct to find however. And can be corrected rapidly. Like revision numbers not everyone uses the release letters. But you'll find that if you are making a rather big system, having all four parts of the version number can help organize when and how a given feature can be added.


Here we will give each of the six features (there were seven but we combined the two 3D related features into one). Their priority and explain why these priorities were given to them.

  • Project Management as described above can quickly become a great organizational tool for a house building project. Let's face it with all the intricate details of creating a plan for a house and going ahead and building the house (dealing with contractors and such). It can become easy to get lost in all the details even if they are right there listed in front of you. Hence we need to give this one a high priority because it plays a crucial role in the program's "expected" behavior. Now an architect firm might not need this because they typically only need to worry about the plans themselves, not how it's built. As far as version number goes, this would be considered to be released in the next minor version number. Version 1.01.000a because it's a much needed feature. but because certain fields would be added to existing tables, we would need to remember to create a script to update the database structures accordingly.
  • The 3D rendering of house plans is our next feature. Now, if you've never moved a 2D to a 3D system before chances are you might think it's as simple as adding a Z coordinate to the whole system. That's often not the case. Especially not today. Today 3D means either using DirectX, OpenGL, Allegro or some other 3D engine. It means a learning curve if you haven't used these 3D engine before. It also means a whole set of calculations, new file formats and basically an all around change in the program. Because of all the outside implications involved as well as the internal ones This has no choice. It goes in Version 2.00.000a because there's just too much to do. However, since it is a very nice feature to have this might be enough to decide to bring version 2.0 to it's release as soon as possible and give it a couple notches up the priority scale.
  • The house building scenario comparisons is a feature that is nice to have. It's a shortcut however to already existing functionality. As I mentioned before, you could already to this by creating a house plans, adding the elements needed. Adding the first set of materials to use to get a first price estimate. Save that under a different file name, change the materials for the second time to get a second price and so on. it would be a bit longer to do so yes, speed is the only reason why this short cut is a much wanted feature. who says speed says time saved (hence money). This feature means adding a table to seperate the scenarios from the floor plans themselves. Possibly a change to the input screens to present the materials in a grid instead of a set of fields (depending on how you originally created that part). it' a big change but it doesn't change the internal design of the program per se. Hence, this should be in the next minor version number. Version 1.02.
  • The physics Engine is a feature that visually will completely depend on the addition of the 3D rendering module. Internally however the physics engine could be a separate and completely independent tool. Why? Because not everyone (not even a majority of your users) are likely to need or want this feature. It's fun to have. But this would also mean raising the price tag of your program (as would adding 3D). In that case you have to ask yourself how many people would pay for that difference? Hence this should be either a separate application or an option feature that people get only if they want it or need it. Perhaps here, aside version number, the notion of specific Editions are in order. This would be in the professional edition of your software in this case. So people that want this feature would pay extra to get. Don't get me wrong here, for those that do need this feature, it is probably a crucial feature to have hence paying extra wouldn't be a problem as it would be more than justifiable for them to get the feature. For this article though, we would put that with the 3D in version 2.00.000a. Or 2.01.000a as 3D would probably be more wanted than the physics engine per se.
  • The integrated accounting system, much like the project management system is a nice to have feature as in making one's life easier feature. Because it takes care of many internal things automatically for the users. But it's a hard to sell feature because most companies that would buy Finance CAD typically already have their existing accounting systems at hand. So for people opening up their new businesses this feature would be easy to sell. For the others, you might want to think about interfacing Finance CAD to their respecting accounting systems. Fortunately, many accounting system makers offer the documents needed (such as database structures and table dependencies) so that you know what goes where and what table needs data from what other table so you can interface rather straightforwardly. Now as far as which version this feature belongs to. Assuming most of your customers already have their own accounting systems. I would put this feature in Version 3.00.000a since again it doesn't represent the majority of your users. In relation to this feature, you could also decide to add compatibility with the more popular accounting systems just a M.Y.O.B. Quickbooks and other widespread accounting systems in lieu of integrating the accounting per se. That all depends on what the market is asking for at the time of the release.
  • The pricing history is a quick add-on as I already mentioned. It's a great way to allow to retrieve the situation of a house plan as it was back when it was originally created without needed some kind of esoteric information storage. This table basically has the house plan number, a date, an Item number and a price. When retrieving the floor plan we take it's creation date and search for that date and that item in the table to get the prices of the materials used at the date the house plan was created. Rather simple to do, non intrusive to the rest of the system as far as database structure is concerned. If you do that, you might suddenly thing that this system could work for other reasons in the program too and might decide to add this in more than one place (such as the accounting system when it's implemented for example). This could go in the next revision number (which would be version 1.00.001a).

NOTE: You might have noticed that I didn't release any of hese feature under any specific release letter. The are all organized in major, minor and revision numbers. The main reason for this is that in my case, release letters are used specifically for bug fixes. A correction to one of these features, when added, would be in the next release letter if a bug occurs. But to me, any feature should be released as a major, minor or revision level change.


And there you have it. We are now at the real end of this series on commercial and professional software development. It's important to remember that this series (all seven parts of it) constitute a typical scenario on what taking a project from the start to the end (and beyond as shown in this last part) is all about. As you can probably imagine after reading all seven parts, there's are many things to consider when developing a big project. You could think of this series as a guideline, if you will, into what the steps are, and possibly what you will need to achieve these steps.

The main rule of thumb as you might have guessed after reading this series is that preparation is the most important part of creating a program. This goes for games, applications, tools, utilities and the likes. Now when you are presented with a project to do you simply have to do that project. But sometimes that project will be an idea you have for a specific kind of program. Hence knowing what the potential customers might want becomes your responsibility to discover. It's not an uncommon practice to have surveys on your website that users can fill out in order to give you an idea of what would work with them. Keep them short so it doesn't take them hours to fill out 10 questions max is a good standard to follow, and keep all of the questions related to the one subject you want to find out about. If you have more than one thing you need to know about, create one survey for each of them. This way people can fill out just the ones that concerns them and this helps you keep this knowledge organized and manageable.

I'm always open to suggestions as I have mentioned many times in this series. Just contact me and ask me questions, give me suggestions if you have any. This whole software development academy project is about teaching you what you need to know. So if there's a given specific subject that I have overlooked int his series or that you would particularly like to know about. Just let me know about it and we'll see what we can do about. And most importantly I hope you've enjoyed reading this series as much as I've enjoyed creating it for you and of course, that you've learned something from it which is it's main intended goal.

Stephane Richard (MystikShadows)

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.