the manufacturer has done a crap job of building the "networking" part of this,
Actually, the manufacturer has done an EXCELLENT job of building the "networking" part of this. Hacking into this remote is going to be very problematic! Think of the built in security! Maintaining it, however, is a different story.
Afraid not, a friend of my and myself actually tried contacting some of the old shareware companies to get permission to make the old shareware on a flash stick with a preconfigured DOSBox so kids could see what it was like in the early 90s.
What we found was
This is why you follow the license on the shareware, and what you did was essentially allow the copyright holders to restrict you retroactively. Most shareware, IIRC, had something along the lines of distribution was fine, you had essentially a "trial" free version, and payment to unlock the entire thing. Abide by those rules, and you should be fine. IANAL....
This is why I think copyrights should be a "use it or lose it" situation, where if a company does not sell their product in retail markets for x number of years they lose the rights which then go into public domain.
I'll agree with this. Personally, I feel the following should happen
- 1) bring back the register the work with the Library of Congress portion within a year of publishing. This will ensure the work remains available even if the publisher goes away.
- 2) make the copyright term truly limited. Since the average life expectancy for men in the US is 74 and you cannot realistically recall most things until you're at least 10, that means the max would have to be less than 64 years to effectively be limited. I would argue 32, rounded down to 30, which is darn close to the original copyright terms. I also am fine with the original clause that required re-registering the copyright halfway through.
- 3) putting something in "the vault" (a la Disney) automatically puts it in the public domain. (the anti-Disney greedy money grubbing clause)
- 4) copyrights are non-transferrable and distribution agreements cannot extend beyond half the copyright term. (guarantees that the copyright creators maintain ownership)
Apple launched the iPhone in January of 2007. Eleven months later, in November of 2007, Google showed a video that effectively juxtaposed Google-Android's original pre-iPhone "before" prototype which looked and operated more like a Blackberry button-driven phone, with Google-Android's post-iPhone-launch "after" prototype that heavily-resembled the look-and-feel of the iPhone and incorporated many of Apple's signature touch-screen inventions. In October 2008, T-Mobile released the G1, Google's first Android phone.
You can draw whatever conclusions you want, but it is hard to argue that Android did not change in nature due to Schmidt's privileged knowledge.
...Within the project's lifetime the whole way in which people used and viewed websites changed completely.
If you think everything can be foreseen at project conception, then you know literally zero about the realities of software development.
So apparently, the only thing that needed changing in your case was the GUI. If you knew squat about web development, that would have been a relatively minor thing to change, provided that you knew what you were doing in the first place. Building to IE6 indicates otherwise however.
You would literally need someone who can see the future on your team to be able to do what you're claiming successfully and consistently.
No, what I need to be able to do is take technology today, as it exists, pick the proper components, even if they are alpha/beta, and ensure that my choices are kept up to date and do what they need to do, especially in the alpha/beta area. It's called tracking your dependencies, and it's not accomplished by tying yourself to maven central.
Government IT projects are universally known to be a complete joke, precisely because the failure rate is astoundingly high.
What's funny is I was involved in a rather large successful gov IT project. The problem with the failure rate is the same as it is everywhere else - bad management and/or incompetence. Add something like Agile and you can just write it off before you start.
"Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause."
Oh not this old chestnut. This doesn't even make sense, the whole point in an agile project over waterfall is that it cannot run over budget or beyond schedule. The whole point is that you keep sprinting until you've spent as much as you want to spend for the deliverable provided at the end of each sprint.
Have you worked in the real world? Generally a project is envisioned, then estimated and budgeted. This happens at the beginning of a project, because generally shareholders (public companies) don't like to spend 50M on a project (promised functionality) and not receive a working model. Take the car analogy, GM is going to design a new car, they're budgeting 'x' for it based on previous history, and 'y' time. This will get it out on date 'z', per the normal car release schedule (once a year) Investors like the new concept, and eagerly await the production run to produce this new wonder. However, for this project, GM departs from their tried and true process, and incorporates Agile. They start work, the teams are too large, scrums eat far too much time so they segment the teams to stay on schedule. As things segment, communication starts to whither, because no one is managing the full project. Stakeholder see the frame, the new engine, etc taking shape per schedule, and decide that a minor change here and there will improve things. It comes time to integrate once the prototypes are designed and built. Gee, those 2 disparate changes now cause the engine not to mount to the frame, and the controls require rewiring because the harness doesn't match up. Now there's a mad scramble, the prototype doesn't make its date, the car isn't built and slips into next year. Stock plunges.
But some of what you say in your zeal to defend waterfall is just complete and utter nonsense because waterfall, like agile, is not a silver bullet either.
And this is hilarious, because no where do I defend waterfall. What I do attack is the utterly useless Agile crap. Waterfall has it's own set of problems, which we're not discussing here, or at least I'm not. I'm describing the real world, how people try Agile, and how they and Agile fails. You can keep dreaming that it works, but if you have a working "Agile" process, you're not actually practicing Agile, you're doing something far more. And to claim that Agile just incorporates this extra process, well, that's disingenuous, because I can make the same claim that you're following waterfall, just with these minor modifications.
In essence, I practice neither process, but a project management style that is more dynamic that grew out of understanding waterfall's short-comings and agile lately claims some portions of as its own.
It was called project management.
Historical revisionism runs rampant in the Agile crowd. Do recall that Agile started with XP programming, more or less, and when that failed (to get traction, produce results, any other measure you care to name) they started slapping additional things on top of it. It has morphed so much over the years that you have to pretty much specify the year and methodology du jour to know whether a project was "Agile" at that time. "Agile" is a failed "methodology", if you can even call something so ambiguous a methodology, and is just code for "we don't like being told what to do or take any responsibility for the results of the project". I'm the polar opposite of that, I take a project and intend to deliver it within specs, on time, and on budget. I generally succeed.