A peek into the axiam, "Software is created but never finished"
by Daniel "opcode" Arnold · 10/22/2005 (3:13 pm) · 4 comments
Like all of us I am very busy day in and out. Weekends are just two more days to work on projects which are just as important as the ones I get paid to develop. I don't know how my wife puts up with me. To keep her from asking herself that question, lately I've been treating her to dinner and a back rub each night.
I'm currently working on four software projects with two coming near to 'completion'. It has taken me a long time to learn how to plan and prioritize to get projects 'finished'. After experiencing the start and 'finish' of three long development cycles, I am just beginning to get the hang of it. Please note the 'finish' of these development cycles involves hiring someone to update it with extra features and bug fixes here and there.
I realized a couple years ago that software is never really 'finished'. Of course I heard rumors before then, but now having experienced it I have identified a few factors myself:
Unlimited Wants - As any economics professor will tell you, people have unlimited wants. The software title I developed with Rogers Software started to become a beast after two years of development. But development did not stop there. Our boss did not have the discipline to deny our customer's request for 'features' and 'updates'. Trying to keep up with our customer's unlimited wants almost killed us and the company. Fortunately, we changed our objectives in time to save the company, but you can imagine with all development it was a bit harder to save the software. We ended up having to rewrite a lot of code and spent months bug fixing.
It could be better... - Software can always be made better, even if it's just arguably better. Just look at calculators. I'm sure someone once said, "how could you make a calculator better, you just press buttons for calculations and your done.". I'm sure that person asked Texas Instruments that question, and that's just a hardware example! MS Office 12 anyone?
Ease of Changing Software - Software is very cost effective to change especially if it's written well. This doesn't help to finish a software project, but in fact often extends the development time. Changing physical objects usually incurs manufacturing costs to create redesigned prototypes. Engineers have to make sure the design is sound. New molds and fasteners have to be created. etc. Thus, these projects are designed from the start to have a defined finish line. Changes do occur, but not very quickly because the costs of redesigning and redeveloping are high. With software, aside from the labor costs, we may only incur a small nominal cost in electricity, but most of us keep our machines on during the day anyway. We have to be much more disciplined because the temptation to keep making software better is hard to resist.
Ease of Updating Software - With high-speed internet connections growing everyday, most software can easily update itself quickly and many times without the end users knowledge. Combine that with a developer's unlimited want to make software better, the ease at which it can be accomplished, and you have a recipe for never ending development.
At first this realization looks great. We can quickly and easily change/update our software anytime we or our customers desire. All at a low cost! That's great if you want to spend your life on one project. But as any economics professor will also tell you, nothing is free. The opportunity costs of all that software updating has to be considered, not to mention the most major cost of all, time.
So what do we do? Is this even a problem? Well, that depends on your development cycle. These factors still exist whether or not your objective is to develop on one start/finish cycle, or to indefinitely develop on milestone cycles. Below are some real world answers to both development cycles, and the one you don't want to be in.
one start/finish cycle:
A good idea here is to realize that while your software could be better, the point is to make it 'good enough'. Many times you have to forgo certain features and decide which ones are the most appropriate. Features which provide selling points are better than ones that are just fluff. It would be better to go ahead and include that extra cool weapon than to have the hud icons wiggle when your hit by an emp round. In a recent case with our company, It was better to allow separate product and service tax options rather than allow discounts to be entered from the checkout screen. Some decisions will be tough to make.
indefinite milestone cycles:
The objective here is to embrace three factors above, and make your customer's pay for each milestone. Didn't Jasc just come out with Paint Shop Pro 10? I'm still using 7! I will not go into Microsoft's history, nor shall I speak of EA's sports games which my brother re-buys every year (updated stats and graphics). Since this development cycle suggests that you will eventually implement all known features, you just have to decide which ones to do first. Of course the word 'milestone' plays a part in this cycle as well. It's better to not update the software for every little change. Rather, set goals to meet before releasing the software, this will make testing way easier. Otherwise you could be stuck releasing patches to fix bugs which cause more bugs. It is recursive.
undefined cycle:
This is the cycle you don't want to be in. It's best to figure out what your development cycle and objectives should be. Then act accordingly. You do have to sacrifice some flexibility to achieve your goals. Staying focused is the key.
-Daniel
I'm currently working on four software projects with two coming near to 'completion'. It has taken me a long time to learn how to plan and prioritize to get projects 'finished'. After experiencing the start and 'finish' of three long development cycles, I am just beginning to get the hang of it. Please note the 'finish' of these development cycles involves hiring someone to update it with extra features and bug fixes here and there.
I realized a couple years ago that software is never really 'finished'. Of course I heard rumors before then, but now having experienced it I have identified a few factors myself:
Unlimited Wants - As any economics professor will tell you, people have unlimited wants. The software title I developed with Rogers Software started to become a beast after two years of development. But development did not stop there. Our boss did not have the discipline to deny our customer's request for 'features' and 'updates'. Trying to keep up with our customer's unlimited wants almost killed us and the company. Fortunately, we changed our objectives in time to save the company, but you can imagine with all development it was a bit harder to save the software. We ended up having to rewrite a lot of code and spent months bug fixing.
It could be better... - Software can always be made better, even if it's just arguably better. Just look at calculators. I'm sure someone once said, "how could you make a calculator better, you just press buttons for calculations and your done.". I'm sure that person asked Texas Instruments that question, and that's just a hardware example! MS Office 12 anyone?
Ease of Changing Software - Software is very cost effective to change especially if it's written well. This doesn't help to finish a software project, but in fact often extends the development time. Changing physical objects usually incurs manufacturing costs to create redesigned prototypes. Engineers have to make sure the design is sound. New molds and fasteners have to be created. etc. Thus, these projects are designed from the start to have a defined finish line. Changes do occur, but not very quickly because the costs of redesigning and redeveloping are high. With software, aside from the labor costs, we may only incur a small nominal cost in electricity, but most of us keep our machines on during the day anyway. We have to be much more disciplined because the temptation to keep making software better is hard to resist.
Ease of Updating Software - With high-speed internet connections growing everyday, most software can easily update itself quickly and many times without the end users knowledge. Combine that with a developer's unlimited want to make software better, the ease at which it can be accomplished, and you have a recipe for never ending development.
At first this realization looks great. We can quickly and easily change/update our software anytime we or our customers desire. All at a low cost! That's great if you want to spend your life on one project. But as any economics professor will also tell you, nothing is free. The opportunity costs of all that software updating has to be considered, not to mention the most major cost of all, time.
So what do we do? Is this even a problem? Well, that depends on your development cycle. These factors still exist whether or not your objective is to develop on one start/finish cycle, or to indefinitely develop on milestone cycles. Below are some real world answers to both development cycles, and the one you don't want to be in.
one start/finish cycle:
A good idea here is to realize that while your software could be better, the point is to make it 'good enough'. Many times you have to forgo certain features and decide which ones are the most appropriate. Features which provide selling points are better than ones that are just fluff. It would be better to go ahead and include that extra cool weapon than to have the hud icons wiggle when your hit by an emp round. In a recent case with our company, It was better to allow separate product and service tax options rather than allow discounts to be entered from the checkout screen. Some decisions will be tough to make.
indefinite milestone cycles:
The objective here is to embrace three factors above, and make your customer's pay for each milestone. Didn't Jasc just come out with Paint Shop Pro 10? I'm still using 7! I will not go into Microsoft's history, nor shall I speak of EA's sports games which my brother re-buys every year (updated stats and graphics). Since this development cycle suggests that you will eventually implement all known features, you just have to decide which ones to do first. Of course the word 'milestone' plays a part in this cycle as well. It's better to not update the software for every little change. Rather, set goals to meet before releasing the software, this will make testing way easier. Otherwise you could be stuck releasing patches to fix bugs which cause more bugs. It is recursive.
undefined cycle:
This is the cycle you don't want to be in. It's best to figure out what your development cycle and objectives should be. Then act accordingly. You do have to sacrifice some flexibility to achieve your goals. Staying focused is the key.
-Daniel
About the author
Torque 3D Owner Stephen Zepp