New Boss Equals Many Changes
-
So, my team (I’m the programming manger) has been developing Web/Windows based applications using, dare I say…VB.NET (go ahead, say what you want, we like it, it does what we need it to do, and our end users/customers absolutely love what we do for them, so let the jokes fly if you must… :) ). Anyway, we just got a new Director, and his first mandate is to stop all VB.NET development and start doing it in C# (something about his prior team not being able to do something in VB.NET, like a web service, so they just switched to C#). Good news is that my team can actually code in either, though we’re much better with VB.NET so any new development won’t be too difficult. BUT! Our existing code/applications, some of which took years to write and get to the point of where they are today won’t be so much fun. So, is there any reliable tool(s) out there, that folks have actual experience with, that we can use to convert or assist us in conversion? I see plenty in my Google search, but have no personal experience. My team is small, yet we produce a high quantity (as well as very high quality) of projects for our end users and have a running list to keep us busy for a very long time. We view that as a slow down to that process (yet we don’t have any problem switching as we see either one as a viable solution for our development efforts). Thanks in advance.
Hi Zhat. I faced the same problem any years ago, and this online tool was pretty helpfull to overcome that issue. In some cases the result code may need a little corrections, but nothing out of this world. http://converter.telerik.com Let me know if it results as usefull for your team as it was for me. Best regards.
-
So, my team (I’m the programming manger) has been developing Web/Windows based applications using, dare I say…VB.NET (go ahead, say what you want, we like it, it does what we need it to do, and our end users/customers absolutely love what we do for them, so let the jokes fly if you must… :) ). Anyway, we just got a new Director, and his first mandate is to stop all VB.NET development and start doing it in C# (something about his prior team not being able to do something in VB.NET, like a web service, so they just switched to C#). Good news is that my team can actually code in either, though we’re much better with VB.NET so any new development won’t be too difficult. BUT! Our existing code/applications, some of which took years to write and get to the point of where they are today won’t be so much fun. So, is there any reliable tool(s) out there, that folks have actual experience with, that we can use to convert or assist us in conversion? I see plenty in my Google search, but have no personal experience. My team is small, yet we produce a high quantity (as well as very high quality) of projects for our end users and have a running list to keep us busy for a very long time. We view that as a slow down to that process (yet we don’t have any problem switching as we see either one as a viable solution for our development efforts). Thanks in advance.
You could always hire more developers, like me. :)
-
Actually I had a similair experience a few years back. It took me well over 2,5 years to fully convert an asp.net 1.1(vb.net) application to a asp.net 3.5 (C#) successor. However, I had to convert the entire application. For my basic translation I used sharpdevelop [^]; this has a built in converter. Also, I used online conversion tools, as there are many available [^]. Hope this helps!
It helps greatly, thanks. I'm hoping NOT to have to do this conversion, and at worse just start all new code in C# vice VB.NET. However, I need to at least plan for having to convert, and determine the pitfals so I can further discuss this with him next week.
-
My experience has been that new code will use the language du jour, but older systems will never get converted. What's the ROI? And you're doing a lot of running just to stay in place.
Psychosis at 10 Film at 11
BrainiacV wrote:
What's the ROI?
None. But, there's the issue of maintaining two seperate code bases, vice 1, and maybe that's part of what's driving him. This isn't a final decision yet however so maybe in the end we won't have to worry about conversion of existing code.
-
I don't intend to be mean sounding, but honestly, he sounds like a fool. Who would walk into a new job and for no good reason say, re-write everything, or switch languages so that now we have two languages to support? What's the business benefit? Makes no sense. I can't imagine what it is, but if there is one very specific thing you can't do with VB.NET that you can in C#, just write that one very specific thing in C# and move on. Re-writing working code just for sake of switching languages not only offers zero benefit to the business, but it costs the business time and money. I would fire that guy before he even started just for suggesting it, it's irresponsible. I write code and I manage large development projects and what I've found is, ask yourself a simple question when making decisions like this... could I stand up in a board meeting and explain why this decision was made and how it will ultimately benefit the company? If not, don't do it.
MachineGun wrote:
I don't intend to be mean sounding
No offense taken, you make valid points. This isn't a done deal, but an ongoing discussion between him and I, although he seemed pretty set on doing all new code in C#, the conversion of existing code is yet to be final. This new director really isn't new to our company, he's been here for over 25 years, at a "sister" organization. He's already done this at his other place, and apparently could justify the effort, at least for those folks, but he is very good at what he does. Our's is a different beast however, but again, the conversion of existing code isn't final, I'm just trying to get a grasp on what tools are out there in case I do have to make it happen.
-
So, my team (I’m the programming manger) has been developing Web/Windows based applications using, dare I say…VB.NET (go ahead, say what you want, we like it, it does what we need it to do, and our end users/customers absolutely love what we do for them, so let the jokes fly if you must… :) ). Anyway, we just got a new Director, and his first mandate is to stop all VB.NET development and start doing it in C# (something about his prior team not being able to do something in VB.NET, like a web service, so they just switched to C#). Good news is that my team can actually code in either, though we’re much better with VB.NET so any new development won’t be too difficult. BUT! Our existing code/applications, some of which took years to write and get to the point of where they are today won’t be so much fun. So, is there any reliable tool(s) out there, that folks have actual experience with, that we can use to convert or assist us in conversion? I see plenty in my Google search, but have no personal experience. My team is small, yet we produce a high quantity (as well as very high quality) of projects for our end users and have a running list to keep us busy for a very long time. We view that as a slow down to that process (yet we don’t have any problem switching as we see either one as a viable solution for our development efforts). Thanks in advance.
-
Hi Zhat. I faced the same problem any years ago, and this online tool was pretty helpfull to overcome that issue. In some cases the result code may need a little corrections, but nothing out of this world. http://converter.telerik.com Let me know if it results as usefull for your team as it was for me. Best regards.
-
First, I'll agree with the others that this should be a go-forward process, with conversion or legacy applications coming at some future point (if at all). The truth is, the syntax of the language in which you're coding is not the problem. Either solutions are well-designed or not, which is more about the process of building the applications than it is about the language. One thing to keep in mind, though, is this is an excellent chance to refactor. I'd start having my team think about and start maintaining a list of those things which they've always wanted to work out. We all look back on code we've written (X time period) ago and say, "What crap! What was I thinking?" Take advantage of this opportunity to rework some of that.
Thanks. As far as new code, no problem doing C#, we can easily adapt and make that happen moving forward. Also, we do have some small number of "legacy" app's, written in VB6 that we have to convert due to business reasons, but we've already planned on just rewritting those from scratch, not just "converting" them, so basically that's new code as well...it's the large number of current app's that are in production which I'm concerned, and therefore asking about. Not firm decision has been made yet, just preparing for it is all.
-
Well, he actually hasn't started officially yet, just made a visit and we had brief conversation. But, the intention I'm seeing is that all NEW code first, followed by existing code later.
Your new boss has a lot to learn. Even though VB.Net and C# both compile to CIL, he's going to find that converting the existing system to C# just because he "doesn't like" VB.Net is going to be an enormous drain on your productivity. About 4 years back we had a boss here that was of that mind set. Come to think of it, MOST of the bosses we've had have been of that mindset. Heh. Anyway ... about 5 years ago the latest "boss" declared that we were going to get rid of all the legacy VB6 code and convert it to C#. Well ... as you might guess here we are 5 years later and the balance of VB6 to C# is approximately the same as it was. Why? Simply because the amount of effort required to completely convert existing subsystems to a completely different language is TOUGH! If you are doing any real development or servicing a client base, you are more concerned with fixing bugs and adding features than you are in wasting time just rewriting code because the boss doesn't "like the language". Tell your boss for me that his idea is - shall we say, unreasonable. (I was going to have you tell him he's "nuts" but I don't think that would go over too well in your position. :-)) If you want to use C# going forward, that's fine. The two languages co-exist perfectly. There is absolutely no reason, NONE, to convert functional commercial code from one language to another within .Net. I, too, am a "converted" VB developer - I only write new stuff in C# now. However, I have about 500,000 lines of VB6 and VB.Net code I'm responsible for in an enterprise application that serves 1400 clients. Your boss has absolutely NO CLUE how much lost productivity a rewrite of your VB.Net code in C# just because he "doesn't like VB.Net" will cost. If he has any concern for your department's performance metrics (and what manager doesn't?) you must convince him of this. Think you have a big bug list right now? It will grow by an order-of-magnitude if you convert functional, tested code from one language to another. VB.Net and C# are ver similar, yes - but the paradigm of the code is different. Many, many bugs will be introduced and for absolutely no sustainable business reason. Don't even let him START that project. It is a disaster waiting to happen. -Max
modified on Friday, June 25, 2010 11:30 AM
-
I wouldn't recommend that you necessarily convert your existing code to C#, why not just write C# going forward and keep the VB.Net code as-is? -Max
-
Thanks, yes I saw that online, tried some simple code conversions, but couldn't say how well it might perform until I run some heavy code through it. But there are several other converters out there, both free and for purchase. We'll just keep testing as best we can until a formal decision has been made to actually convert our existing code. Hopefully he'll stay focused on new code and leave conversion alone.
-
db7uk wrote:
An interesting move from your director if I may say so. What was his motive behind the switch?
Well, apparently his team found "something" that they weren't able to do in VB.NET, so they tried it in C# and got it to work...therefore logic dictates that C# trumps VB.NET as an overall solution to all problems (I heartedly disagree with this thought, but hey I've yet to see anything that can be done in C# that can't be done in VB.NET, but there could be those cases).
db7uk wrote:
If someone were to ask me to change the code language they had better come up with a reasonable reason why! or am I missing something?
First off, Directors don't need reasons, they are the reason, but I know this guy and he's been with our bigger organization for well over 25 years, so he must have good reason. But, the discussion isn't finished by any means. Good thing about being a manager and coder is that I can basically provide the up/down side to doing this, provide good examples and suggestions (from all you kind folks) as to why we should attempt conversion and then see what happens. At the end of the day, regardless of the decision, we'll do what we're tasked to do, amke it work for our end users and drink a cold beer after...it's what we do best (not just the beer part).
modified on Friday, June 25, 2010 10:57 AM
Zhat wrote:
he's been with our bigger organization for well over 25 years, so he must have good reason.
To assume that he has a good reason is just as large a failure in logic to have your team transition to C# because a prior team couldn't get something done in VB. The truth is that the two languages are near parity. And there are some things that VB does that C# does not. Particularly when you are dealing with XML. I feel for you as from where I sit you could be in for a rough ride. My experience is that when a new boss announces changes before officially filling a position, then the new boss considers this to be a cleanup job. I would get my resume ready.
-
Zhat wrote:
the intention I'm seeing is that all NEW code first, followed by existing code later.
Such a waste of time and money unless there is a bonafide real world reason to change it that will benefit both customers and the product in general. If your development team are versatile enough to work in either language, then there seems like no good reason to rewrite existing code into another language other than for Mr.New Director to 'make his mark'.
---Guy H ;-)---
-
As funny as that is, this guy is fairly sharp (no pun intended), but he's not a true hands on developer, where as my group, including myself, live in code all day (I just have to add the extra responsibilities of manging at the same time). I didn't have time to ask him for details but we'll discuss this again.
I have no info on conversion tools....but I have a ton of philosophy for you..... :) This whole situation reeks of job security! Your team has a bright future ahead of you, converting things that don't need to be converted, while continuing new development. Full employment for all, even if biz slows. It might prove to be an excellent learning situation also, in as much as you fully understand the legacy code base and the reasoning behind writing things in the way that you did. The conversion process might be a great place to beef up your weakest C# team members, those least comfortable outside of the comfort zone. Flip it, look for the positives. Oh, and good luck! :)
-
I have no info on conversion tools....but I have a ton of philosophy for you..... :) This whole situation reeks of job security! Your team has a bright future ahead of you, converting things that don't need to be converted, while continuing new development. Full employment for all, even if biz slows. It might prove to be an excellent learning situation also, in as much as you fully understand the legacy code base and the reasoning behind writing things in the way that you did. The conversion process might be a great place to beef up your weakest C# team members, those least comfortable outside of the comfort zone. Flip it, look for the positives. Oh, and good luck! :)
ErrolErrol wrote:
reeks of job security
I can't say in our situation that this would even be a thought, we're pretty busy, our company is good and even if we did decline/find the need to get rid of folks, doing conversion work would save anyone from that chopping block. However I agree with the learning situation. We have new code, which I can easily get my team to do in C#, so there's a learning situation there, and we also have a small number of old legacy VB6 applications which also have to be redone, so we'll be looking at a total re-write of those in C#, again a good learning situation for some folks. It's the current production applications I'm concerned with...even if we do decide to convert everything, those prod app's would be done last, and as time permits (hopefully), but we'll see.
-
Well, two code bases is 1 thing, but again, I got some pretty shrp people, so that's minor. We'll see after we continue the discussion.
Not sure I follow why that's considered to be 2 code bases. Both can exist side-by-side in both the VS project and TFS. It's still one code base. Separate maintenance doesn't have to be done. Y'all are making this much more complicated, I think, than it has to be. -Max
-
BrainiacV wrote:
What's the ROI?
None. But, there's the issue of maintaining two seperate code bases, vice 1, and maybe that's part of what's driving him. This isn't a final decision yet however so maybe in the end we won't have to worry about conversion of existing code.
Right now, since your team is equally versed in both languages, the cost of maintaining a code base split into two languages is zero. This new director knows (or thinks they know) something you don't. It is worth your time to try to understand why they really want to make the change. Perhaps its as everybody suspects and they just want to feel they're making improvements, but perhaps there's a very real gotcha coming that they're trying to save you from. Also, if you have to convert, see if you can do ground up redesign/rewrites instead. That, at least, will produce a very real future ROI that your director can claim and that your team gets to benefit from too. I'm sure you've got a few apps you'd like to do that with, start with them.
patbob
-
Well, he actually hasn't started officially yet, just made a visit and we had brief conversation. But, the intention I'm seeing is that all NEW code first, followed by existing code later.
BZZZT. First mistake ... don't jump into doing anything this soon. The guy hasn't even started and you are thinking about making big changes like this? Once he arrives and gets involved in the real world of what you are doing and the politics in your world, his expectations may change and you will have wasted a lot of time for nothing. Always let "hot" issues like this simmer for a while and they usually either go away or something else get a higher priority and expectations change and the apparent need for the "hot" item gets modified. Don't be so eager the please the new boss.
-
ErrolErrol wrote:
reeks of job security
I can't say in our situation that this would even be a thought, we're pretty busy, our company is good and even if we did decline/find the need to get rid of folks, doing conversion work would save anyone from that chopping block. However I agree with the learning situation. We have new code, which I can easily get my team to do in C#, so there's a learning situation there, and we also have a small number of old legacy VB6 applications which also have to be redone, so we'll be looking at a total re-write of those in C#, again a good learning situation for some folks. It's the current production applications I'm concerned with...even if we do decide to convert everything, those prod app's would be done last, and as time permits (hopefully), but we'll see.
My point about job security was exactly as your reply regarding "doing conversion work would save anyone from that chopping block" reiterates. Your concern about your current production applications is very valid, but it makes the hair on my nearly bald head stand up...a little, if you look real closely! I always wonder about putting the easy or unimportant or rarely used stuff first, in a conversion scenario. I really don't think that works well, unless there is a level of skill insecurity that dictates that course. I think one should attack the current production product as a highest priority. Yes, yes, if it ain't broke don't fix it, sounds good as a homily, but I think the ROI inherent in working on the current products, while they are at their freshest intellectually with your developers and at in terms of marketability, is the correct course in most circumstances. In another circumstance, in a fresh start scenario for example, it is reasonable to do the no-brainer-this-will-never-change-in-our-life-time stuff first. In your current story though, I think it is better to swing for the fences and make an impact on the game. It brings a level of commitment and concentration to your conversion efforts that might be lacking otherwise.
-
So, my team (I’m the programming manger) has been developing Web/Windows based applications using, dare I say…VB.NET (go ahead, say what you want, we like it, it does what we need it to do, and our end users/customers absolutely love what we do for them, so let the jokes fly if you must… :) ). Anyway, we just got a new Director, and his first mandate is to stop all VB.NET development and start doing it in C# (something about his prior team not being able to do something in VB.NET, like a web service, so they just switched to C#). Good news is that my team can actually code in either, though we’re much better with VB.NET so any new development won’t be too difficult. BUT! Our existing code/applications, some of which took years to write and get to the point of where they are today won’t be so much fun. So, is there any reliable tool(s) out there, that folks have actual experience with, that we can use to convert or assist us in conversion? I see plenty in my Google search, but have no personal experience. My team is small, yet we produce a high quantity (as well as very high quality) of projects for our end users and have a running list to keep us busy for a very long time. We view that as a slow down to that process (yet we don’t have any problem switching as we see either one as a viable solution for our development efforts). Thanks in advance.
Rather than waste your time, your boss's time, and the company's time rewriting the current code base, keep it in basic and write your new code in C#, since they are compatible. To just rewrite it not only introduces new bugs that will need to be tested, but is simply just a "cluster flub" (coined from a Clint Eastwood war movie). If your boss was truly thinking of the business, rather than puffing up his pride (and position), then it would not matter. His is risking the business and project for what? If it worked in VB, so what? Pride be damned. Get the product out. Besides, it doesn't take a MBA to figure this one out.