|
|
|
|
|
by dbcurtis
3341 days ago
|
|
OK, but this has been a very long transition. There has been lots of time to evolve to 3.x. Has the primary barrier been the slow transition of library dependancies? I'd really like to understand this from a technology transition management standpoint. If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been? Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits. |
|
Now, you have 2.7 apps that are very mature, stable and reliant on lots of little things. Okay, big job.
Now let's throw another wrinkle into this. You can pay good money to develop your next feature, or to port your system to 3.x. One adds real value to your customers and improves your bottom line. One lets you say you are on 3.x and gets nods of approval from random programmers.
What do you think a business is going to do? Exactly.
When will we eventually port? Sometime shortly after 3.x becomes the overall standard. THIS is actually what we are seeing right now, which is great, but that hasn't been the case up until the last year or so.
>Any technology that lives long enough eventually has to transition its customer base.
While true, this costs money, time, and effort. So you better be damn well sure there is a good ROI that is something more than "This code that nobody but programmers see is more elegant and properly structured".
There's a reason banks are still using COBOL after all...