Intro to the "Next Year's Model" Problem
Jan 16, 2020 15:34:03 GMT -8
Post by Uncle Buddy on Jan 16, 2020 15:34:03 GMT -8
What do I mean when I say "next year's model" of genieware?
Here's an analogy.
You have an old car that you love. You've nursed it through the years and it runs great. But the paint's peeling off and your neighbors tease you about it. So you keep it parked in the alley next to your beautiful garden.
Then a neighborhood watch reports your ugly car to your landlord who isn't supposed to be renting you his house anyway because the Association has rules against that sort of thing, as well as old cars with peeling paint. So the landlord builds a garage where your beautiful garden was and increases your rent to pay for his garage.
That's the next year's model problem. I know, it's a sloppy analogy, but I like it.
I won't come right out and say that capitalism spoils everything it touches (I didn't say that). But software that is sold tends to be released as version 1 before it's finished. As a novice coder I can say without hesitation that writing code over from scratch always, without fail, produces better results than patching up old code. Because coding skills improve with use, a programmer who uses old code as a model is just cheating himself. I've been stymied in every case where I tried to ignore this phenomenon. But when a broken down, patched together, hurry-up-and-finish job is presented to the public as version 1.0, then when you get down the road to version 5, guess what that code has to be backwardsly compatible with?
Yup, you guessed it, the broken-down unfinished code that was version 1.0 becomes the model for all that is to follow. I don't know much about the software industry in general, but there is no discernible evidence that most of the genieware I've tested was created by professional developers. Most of the available genieware sells for a pitifully low price and professional developers need to make a living.
In this section of the blog I will be reviewing a great variety of unfinished genieware. I can say that with confidence because none of the genieware I've tried to use had any business being put out as a product. That's OK, it's an understandable situation. People want to be paid or at least acknowledged for their work and writing software is hard work. Even if there's no money to be made, you still want to tell people about it.
Treebard is not another attempt to sell a product. It is a showcase for functionalities that should exist in any genieware. It's inspired by the needs of genealogy itself, not by the need to attract consumers with a shinier door handle. Treebard is also inspired by the existing programs, by what's missing from them or what's wrong with them. Treebard is meant to show the way, not because I'm a great coder (I'm not) but because I'm a great critic. I am very much inspired, by what's wrong with today's genieware, to demonstrate the way things could be. Because there are no numbered versions of Treebard GPS, it doesn't have to be backwardly compatible with itself so the GPS version is free to throw away mistakes. This will still be true after I make the code publicly available. Treebard will be open source to the max, that means no copyright. I'm a Taoist: "The more you have, the more you have to take care of."
So if someone wants to use Treebard for their genealogy work, it should be forked as version 0.0. Once it becomes version 1.0, it should start to be backwardsly compatible with itself. I'm 64 years old and going blind from too much computer time so I doubt I'll be the one who creates software for daily use. Also there is some question as to whether Python should be used, since it runs slow, although the Gramps developers seem to be getting away with it. Mr. Tamura Jones has a good discussion on that topic which I didn't really understand very much of since I'm sticking to the most basic vanilla Python I can find. One of the goals of GPS is to keep the code from becoming opaque to beginning coders. I believe a GPS team, if one ever springs to life, would be better manned by avid genealogists who tinker with code than avid coders who tinker with genealogy.
Here's an analogy.
You have an old car that you love. You've nursed it through the years and it runs great. But the paint's peeling off and your neighbors tease you about it. So you keep it parked in the alley next to your beautiful garden.
Then a neighborhood watch reports your ugly car to your landlord who isn't supposed to be renting you his house anyway because the Association has rules against that sort of thing, as well as old cars with peeling paint. So the landlord builds a garage where your beautiful garden was and increases your rent to pay for his garage.
That's the next year's model problem. I know, it's a sloppy analogy, but I like it.
I won't come right out and say that capitalism spoils everything it touches (I didn't say that). But software that is sold tends to be released as version 1 before it's finished. As a novice coder I can say without hesitation that writing code over from scratch always, without fail, produces better results than patching up old code. Because coding skills improve with use, a programmer who uses old code as a model is just cheating himself. I've been stymied in every case where I tried to ignore this phenomenon. But when a broken down, patched together, hurry-up-and-finish job is presented to the public as version 1.0, then when you get down the road to version 5, guess what that code has to be backwardsly compatible with?
Yup, you guessed it, the broken-down unfinished code that was version 1.0 becomes the model for all that is to follow. I don't know much about the software industry in general, but there is no discernible evidence that most of the genieware I've tested was created by professional developers. Most of the available genieware sells for a pitifully low price and professional developers need to make a living.
In this section of the blog I will be reviewing a great variety of unfinished genieware. I can say that with confidence because none of the genieware I've tried to use had any business being put out as a product. That's OK, it's an understandable situation. People want to be paid or at least acknowledged for their work and writing software is hard work. Even if there's no money to be made, you still want to tell people about it.
Treebard is not another attempt to sell a product. It is a showcase for functionalities that should exist in any genieware. It's inspired by the needs of genealogy itself, not by the need to attract consumers with a shinier door handle. Treebard is also inspired by the existing programs, by what's missing from them or what's wrong with them. Treebard is meant to show the way, not because I'm a great coder (I'm not) but because I'm a great critic. I am very much inspired, by what's wrong with today's genieware, to demonstrate the way things could be. Because there are no numbered versions of Treebard GPS, it doesn't have to be backwardly compatible with itself so the GPS version is free to throw away mistakes. This will still be true after I make the code publicly available. Treebard will be open source to the max, that means no copyright. I'm a Taoist: "The more you have, the more you have to take care of."
So if someone wants to use Treebard for their genealogy work, it should be forked as version 0.0. Once it becomes version 1.0, it should start to be backwardsly compatible with itself. I'm 64 years old and going blind from too much computer time so I doubt I'll be the one who creates software for daily use. Also there is some question as to whether Python should be used, since it runs slow, although the Gramps developers seem to be getting away with it. Mr. Tamura Jones has a good discussion on that topic which I didn't really understand very much of since I'm sticking to the most basic vanilla Python I can find. One of the goals of GPS is to keep the code from becoming opaque to beginning coders. I believe a GPS team, if one ever springs to life, would be better manned by avid genealogists who tinker with code than avid coders who tinker with genealogy.