Our frontend was built using Material-UI 0.18.7, and we realize that this is now very out of date. Our frontend guy is telling me that it would be nearly a total rewrite to upgrade to a 3.x release (and our frontend is large and complex) and we just aren't able to undertake that at this time. Beyond the obvious problems that come with a very old version, are there any special issues that would be caused by not upgrading?
Well since this is a front-end library, there is not much issues concerning security - which would be one of the main reason to upgrade.
You can see their changelog and search for keywords like 'security', 'patch' or w/e.
Of course the big reason to upgrade would be to get new features, more optimized solutions (if you are experiencing slow downs), bug fixes and much more.
Depending on the size of your front-end, it might be worth checking how much time it would actually take to upgrade.
Don't forget to take in consideration the time your front-end guy would need to implement new requested features which are already implemented on new versions, him needing to make dirty hacks to go through some known bugs, use other old libraries, etc... if you keep the old version.
Related
Which is the more feasible strategy for version upgrades when you are multiple versions behind. For example from 6.4 to 2005.
Should we really do a version by version approach as SAP suggests. I understand it's recommended way but still.
Any one can share their experience regarding this?
What difficulties could be faced when directly migrating multiple versions?
Thanks!
There are several approaches you can take. Which one you take depends on the knowledge your team has and with the amount of customizations you already performed.
Step by Step
This is the recommended way by SAP. This is a more secure strategy, where it's very clear what changed between different versions. With every version, you will experience build failures, startup failures and possibly even data issues that need to be migrated. But it's very clear what version caused those issues. With the SAP help and the upgrade notes, you should be able to easily find what was changed, and how to fix it. Disadvantage with this approach is that you need to download, unzip and build for every version, and that takes time. Sometimes you even need to fix the same code twice, when the implentation was changed multiple times
One Shot
With this approach, you go straight to the latest version. You just put your custom code in the latest version and just see what build failures you get.
With this approach, it will be harder to figure out what exact version upgrade caused a specific issue. You should still check all upgrade notes, to make sure that no migrations are needed. Advantage is that you only perform everything once. If you have an experienced team, this is a feasable approach. If you have a new team, be carefull with this approach. You might encounter some difficult errors where you won't be sure what version caused them, so finding info in the SAP help might be harder
Hybrid approach
A third option would be a hybrid approach, where you upgrade several versions at once (For example to versions that contain big changes, like with the addition of backoffice in 6.3). This makes it easier to apply changes for those big changes, while you don't have to go through every version one by one.
Conclusion
I've tried all approaches in the past. The step by step approach takes a lot of time, but makes the changes easier and clearer. With the One Shot approach, you only need to download the latest version, but it might be somewhat harder to find the bugs. If you have an experienced team, you should go for the one shot approach. When you are a lot of versions behind and there were big changes, you could go for the hybrid approach
I had a similar requirement of upgrading from version 6.2 to 2005, I went with the One-Shot approach as explained by Yoni, and the biggest challenge I faced was due to Java version change.
I believe One-Shot approach and Step by Step approach will take a similar amount of time in the major version upgrade, though Step by Step approach is safe but redundant. My personal favorite is One-Shot.
I recently did a platform upgrade from hybris 6.7 to 2005 and did it step by step, mainly because of the java version change and, other than that, there were certain migration steps in each intermediate version that were needed to be done. Also the customer had a lot of custom promotion rules and they needed some special care.
In my case, the process in each step was this:
Upgrade to new version - there is an help.sap.com page for each step, I recommend you follow it and go through each of the section to see what applies to your project, e.g Upgrading Platform from 6.7 to 1808
Compile the project - some deprecated things will be removed in some steps and you have to refactor where needed. This step took me the most amount of time
Start the hybris server - after you finish the refactoring and your project builds successfully with ant clean all there is the possibility that the platform will fail to start due to some (now) incorrect xml config. The "good" part here is that you can see in the console what the problem is and the fix should go faster than the previous step.
Perform the necessary upgrade steps - here is the tricky part, once your platform starts you have to perform the necessary upgrade steps for each extension and add-on that needs it, otherwise you risk working with some broken business logic. You need to do some regression tests and check that everything works as it should.
All in all, an upgrade takes time and depends on how many versions you have to go through, but I think taking it step by step is the most efficient way to accomplish it.
Several days ago, Mirth Connect version 3.3.0 was released. Noting the great new features, we decided to upgrade immediately (just days after the initial release). We followed these Upgrade Guide instructions during the upgrade. However, the specifics of upgrading from 3.2 to 3.3 are missing from these Upgrade Guide, so we did not suspect much to change on the way Mirth should be implemented...
During this process, we ran into a handful of issues that caused our production channels to go down for several hours (†).
It would have been really nice to have specific information for this upgrade. Some issues that would have been really useful to know beforehand (just examples, no need to actually answer):
Are you changing the default toString() method for objects/arrays to return JSON representations?
Does this upgrade include a db migration, meaning we can't revert to
previous version once upgraded?
Because code templates are now children of "libraries", will we need to access the code template through the library, or will we be able to call it directly (as it was in 3.2)?
A solid documentation like this would have allowed us to understand the full gravity of what needs to be accounted for when upgrading. Typically, Mirth has some documentation for each minor release. But even then, the documentation is very terse. Would it be possible for the Mirth team to start being very explicit with what the upgrade entails?
The Rails Upgrade Guide (obviously much larger team, so can spend more bandwidth on this spec) provides a really great example of what an upgrade guide should entail.
† yes, yes, I learned my lesson, I won't upgrade immediately to production anymore
The Release Notes page will give the lowest level of changes to the application, but you're right in that a better documentation is needed.
I'm working for a company that has an established application written in VB6. The application is stable and continues to provide the company with good income. However, it is beginning to show its age and noises are been made to port to a more modern platform such as .Net.
Since this is hardly ever a cut and dry decision I would appreciate input on when it is a good time to port a long standing application to a modern platform.
Some of the pros and cons that I have already worked through:
In favor of porting
Finding skills for an old programming language becomes harder and more expensive
Support from the platform vendor ends at some point
Leveraging modern programming practises on the old platform becomes harder or impossible
Rewriting provides the opportunity to improve existing practises
Moving to a modern platform is motivating for the development team
Moving to a modern platform provides marketing opportunities
Against porting
"If its not broken don't fix it"
The cost of rewriting versus the return
Risks associated with the transition from the old to the new application
Upskilling existing software engineers
Some related StackOverflow questions:
What makes code legacy?
When do you say that the code is Legacy code?
One of the things to consider is that porting an application can get more and more expensive over time. I have seen applications writen in 'ancient' languages that were very well developed. But, as happens many times, all the domain knowledge was in the code and in the heads of the developers, not in up-to-date documents.
So in situations like this porting means not only rewriting in the new sparkly language but also reverse-enginering the specs and picking the, hopefully available, brains of the developers. This becomes harder and harder over time.
An other thing is that 'porting' is hardly ever as easy as the Migration Wizard want us to believe. Many wizards produce a half-baked solution that is still constructed according to the constructs and features common to the 'legacy' environment and will hardly be using the new features and possibilities. This might not seem that bad but if you leave it at that level you are in fact making it very hard for developers that know the 'new' language to understand the code and make porting to the next platform or language even harder. That is what I call LEGACY in capitals. Dragging useless stuff around for decades.
The optimal moment to start porting, from a developer's point of view, was yesterday.
The optimal moment to start porting, from a manager's point of view, is tomorrow.
The optimal moment to start porting, from a competitor's point of view, is never.
There are a lot of other considerations to evaluate: opportunity cost (what else could we be doing), capacities for extensibility and growth (what else does the application need to do/be), sustainability with other moving parts (DB upgrades, OS upgrades), etc. The list goes on and on.
Specific to VB6, I would evaluate what limitations are in the way of product progress vs. moving up to the current .Net framework. Ask yourself -- is this really an IF scenario, or a WHEN scenario?
From a general standpoint, the worst time to port an application is when you HAVE to port it. Your situation sounds like an ideal time to begin code migration -- before it becomes a necessity. Given your legacy product's profitability for your company, any situation where you're forced to move to migrate brings pressures around deadlines, scope, etc.
All things considered, your situation sounds like an ideal time to port up to the .Net Framework, well before it becomes necessary.
Echoing jro and especially Erno,
Upgrade before there is a crisis.
Upgrade before the developers move on to other places where they have a chance at working on a modern framework.
Upgrade while the developers that built the original program are still around.
No competent developer will accept a pure porting job, it is not a career enhancing move. But the existing developers will be happy to learn the latest framework as part of a porting effort.
VB6 was released in 1998. March 31, 2008 Microsoft EOL'ed all VB6 support. Your company is so far into the danger zone with this code, it isn't funny.
To add some perspective,
Netscape was still an independent company and they just release Netscape 4.
Clinton was still president
The internet was still a new concept
Intel had just released their hot new Pentium II running at 450 Mhz
The Matrix was still filming
Google hadn't been founded (it was later in the year)
At some point, the company will be forced to upgrade the app because the operating system will no longer support the apis.
You should leave this company. It is career death to stay.
Update because Cody thinks "I am an individual developer":
#Cody -- Rethink your assumptions. I run my own company. Without fail, every time we have slipped behind the last stable release of a platform, catching up has been incredibly painful and expensive. The latest pain point is we are on dojo 0.4.3 and Tapestry 4. T4 and dojo 0.4.3 have this mutual interdependency that we are separating (slowly). Moving to Tapestry5 and/or jquery or even just to the more recent version of dojo is very slow and very painful. The porting has taken over a year because it has to be this long stretched process to keep other development moving along.
The choices are :
stay stuck on the old library
forever (with the problems around
finding/attracting talent),
try to run dual-mode (old/new) code (code doesn't always cooperate,
or freeze development on large chunks of the product during the
port
So far we have been doing a combination of #2 and #3.
Being on old version of either dojo or tapestry means that we have lost the ability of the community to support us and help us with the problems. The advantage of a framework is that other people are doing work that solves your problems. Nobody is solving any VB6 problems any more. Microsoft will not even take money to solve VB6 problems.
The OP's company is completely on their own. Note: that Google was just founded the year VB6 was released. I would suspect that VB6 knowledge has been disappearing from the web and that each year a Google search about any programming problem the OP's company makes will return fewer and fewer results.
This is a business viability risk.
The happy talk about MS supporting VB6 forever and ever is not a good idea. All it takes is some SVP at Microsoft saying: "We can ship the next Windows version in time to make Christmas if the teams do not have to fix these issues that affect only VB6. We will issue a Service Pack later." At some point this can and will happen.
A competitor can come along and introduce a competing product using the latest tools faster ( because the large pool of libraries available when using the latest frameworks.) The OP's company has lost the ability to be nimble because the latest tools and libraries no longer support VB6. (A 13! year old framework!!)
This is another business viability risk.
The fact that this needs to be explained to anyone is a huge, huge warning flag to any developer with any experience who is interviewing at the OP's company.
This reduces the quality and quantity of the talent pool enormously.
Not being able to attract quality talent is another business risk.
The original OP should bail.
Its not just Microsoft and will the Windows support the app. What about things like printers? or displays? Epson is under no obligation to release printer drivers that support a VB6 application.
What happens when the print function stops working for customers on their latest cool 4G-enabled printer?
What happens when customers try to use the app on the now-standard 2000x4000 display and the fonts look all goofy?
What happens when Adobe starts having Adobe Reader advise that the PDF file version should be upgraded?
Seeing a warning dialog popup, not being able to print, use the latest display well, etc will result in customers quietly moving to competitors. They will not even bother to tell the OP's company that they are doing this.
The OP should move on before the layoffs hit.
I am curious as to how other development teams spec out new features. The team I have just moved up to lead has no real specification process. I have just implemented a proper development process with CI, auto deployment and logging all bugs using Trac and I am now moving on to deal with changes.
I have a list of about 20 changes to our product to have done over the next 2 months. Normally I would just spec out each change going into detail of what should be done but I am curious as to how other teams handle this. Any suggestions?
I think we had a successful approach in my last job as we delivered the project on time and with only a couple of issues found in production. However, there were only 3 people working on the product, so I'm not entirely sure how it would scale to larger teams.
We wrote specs upfront for the whole product but without going into too much detail and with an emphasis on the UI. This was a means for us to get a feel for what had to be done and for the scope of the project.
When we started implementing things, we had to work everything out in a lot more detail (and inevitably had to do some things differently from the spec). To that end, we got together and worked out the best approach to implementing each feature (sometimes with prototypes). We didn't update the original spec but we did make notes after the meetings as it's very easy to forget the details afterwards.
So in summary, my approach is to treat specs as an exploratory tool and to work out finer details during implementation. Depending on the project, it may also be a good idea to keep the original spec up to date as the application evolves (which we didn't need to do this time).
Good question but its can be subjective. I guess it depends on the strategy of the product, if its to be deployed to multiple clients in the same way or to a single client on a bespoke project, the impact, dependency these changes have on the system and each other and the priority these changes need to be made.
I would look at the priority and the dependency, that will naturally start grouping things?
I'm beginning development on a solution that will plug into an existing application. It will be made available for public use.
I have the option of using a newer technology that promotes better architecture, flexibility, speed, etc... or sticking with existing technology that is tried and tested which the application already uses.
The downside of going with the newer technology is that a major change to an essential config file needs to be made to support it. If the change goes wrong the app would be out of service. Uninstall is also an issue as future custom code by other developers may require the newer tech and there's no way this can be determined.
How important is this issue in considering an approach?
Will significant config changes put users off deploying code, or cause problems for them later?
Edit:
Intentionally not going into specifics about technologies here to avoid the question from being siderailed.
Install/uninstall software can be provided but there is some complexity involved which may cause them to foul up on edge cases resulting in a dead app. (A backup of the original config would be a way to mitigate that.) Also see the issue about uninstall above where I essentially can't provide one.
Yes, in my experience, any large amount of work will make users think twice about deploying or upgrading.
It's your standard cost/benefit analysis done by businesses with just about every decision. Will the expected benefits more than outweigh the potential costs?
When we release updates to our software, there's almost always a major component that's there just to assist the users to migrate.
An example (modified enough to protect the guilty): we have a product which generates reports on system performance and other things. But the reports aren't that pretty and the software for viewing them is tied to a specific platform.
We've leveraged BIRT to give us intranet-based reporting that looks much nicer and only needs the client to have a web browser (not some fat client).
Very few customers made the switch until we provided a toolset that would take their standard reports and turn them into BIRT reports. Once we supplied that, customers started taking it seriously - the benefit hadn't changed, but the cost had gone right down.
You've given us no detail, so we can't answer with any specificity. But if your question is, will a significant portion of your potential userbase be deterred from using your product if they have to do significant setup work, then the answer is yes. I've seen this time and time again, with my own products and those that I've installed myself. When the only config change is an uninstall and reinstall. People don't like to do work.
You may want to devote more effort than you've considered so far to making the upgrade painless. Even if you're upgrading someone else's framework, you may find the effort worthwhile and reflected in an increased number of installs.
I have noticed that "power users" - developers, sysadmins, etc. - are willing to put up with more setup work.
I'm not sure what you mean by "major config change", but if you're talking about settings / configuration files, then I've been doing something like this:
An application always contains a default configuration which is useful for most users, and which can't be replaced. Instead, users can override one or more of the default settings in their own, separate configuration file. When a new (major) version is released, most users don't need to reconfigure anything: their own custom configurations are still taken from their own configuration file, and possibly required new parameters are taken from the new release's default settings.
It's obvious that most users don't want waste their time adjusting some settings that already were right - and quite rightfully so.