I know it's painful for microcoders to see all the new (usually dirt cheap) chips/chipsets but not be able to use them because the rewrite and retesting effort would be massive. I've only seen it happen when the device is so popular that people think up additional things it could do and there's a potential for greater sales. Even then, the bean counters have been known to say no - better the devil we know.
As the expert system said "I were one, two." I think I hurt Don's feelings when I said I wouldn't hire him but I wouldn't hire me either! At least not back then when I was a "sole practitioner" and that's *because* I was a sole practitioner.
Some of my most profitable gigs were converting stand-alone versions of programs I had written to networkable ones. Obtuse coding got me the repeat business because they shopped the upgrade elsewhere and were told "it would take us weeks to figure out what it does, let alone make it do something else." It was "ahead of its time" coding - outputting dBase II in neatly formatted boxes using ASCII line commands. We burned out at least one dot matrix a month because the client spec'ed 30 active jobs but there were really 300.
If you're dealing with a limited data entry pool you can skip a lot of bulletproofing, I agree. For something that doesn't face hostile actors time is money and I worked 16 hours a day as a lone cowboy. Making it bulletproof wasn't as important as making it work.
To top it off, big jobs seemed to come in all at the same time so I really had to work as fast as I could all the time because I might lose a big job because I was too busy.
Even if the code isn't great, a second pass is never a bad thing. "Build one to throw away - you will anyway." -- Mythical Man Month
I do agree that the first time you have to update your own quick and dirty code is the time you learn to be a little slower and a little cleaner.
Ain't it great to have to rediscover an issue that you solved months or years ago and work around and around it until you remember why you had to do it the way you did?
Just opened a tub of in-date yogurt that had a nice big green mold spot where the foil didn't seal. That would be hard to catch, I suspect. A true self cleaning fridge would be great, though. I've taken to writing the date I open pickle jars and such on the bottom of the jar with a sharpie. Sometimes it shocks me how old some stuff is. (0:
I'm pretty sure that's firmware, not software. (-:
But these are usually very close to trivial programs that operate with little user input and that interact with relatively few sensors - at least soldering irons and other items like that. And I would expect that as with new cars, updating will be more and more feasible because so many new appliances will be web-enabled.
It's still quite unfair to compare a microwave's program to something like Linux or Windows that has to host an nearly infinite variety of applications on hardware that's very, very variable. It's largely a function of the number of lines of code. As that rises, the likelihood of finding all the bugs drops in proportion.
How much extra care? If it's extra care, doesn't that imply extra cost? Which gets us back to the comments I took issue with. To be more careful requires more cost and more time. Companies reuse code and build code libraries to be competitive. If they had to write everything from scratch every time it would be prohibitively expensive. Can a "sole practioner" afford to take more time and care? Yes, of course, but even then the more time you spend on one program the less you can spend on other programs (and sources of income). So making programs as perfect as you can make them cuts into your revenue stream. Is it worth the tradeoff? Maybe it is if your client reputation shines as a result and you get more business and clients who are willing to pay for the increased reliability.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.