New Boss Equals Many Changes
-
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.
-
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.
There is absolutely no good business reason to convert this code at all. If he insists, he's obviously shouldn't have been hired.
-
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.
-
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
This is a refactoring. It is a alleged improvement that should cause no change in functionality. Two things, then: One should refactor in response to "code smells", not in response to personal taste. In its 4.0 .NET release, Microsoft talks about making sure both languages have identical functionality. Maybe something somewhere in the past didn't work in C#. Is that still true? Is it something you need to do? Second, refactoring without unit tests is a high wire act. If the codebase lacks them, you are asking Fortune for bugs -- and she will deliver.
-
This is a refactoring. It is a alleged improvement that should cause no change in functionality. Two things, then: One should refactor in response to "code smells", not in response to personal taste. In its 4.0 .NET release, Microsoft talks about making sure both languages have identical functionality. Maybe something somewhere in the past didn't work in C#. Is that still true? Is it something you need to do? Second, refactoring without unit tests is a high wire act. If the codebase lacks them, you are asking Fortune for bugs -- and she will deliver.
kjthorn wrote:
This is a refactoring. It is a alleged improvement that should cause no change in functionality.
Refactoring code is fine if the purpose of said refactoring is intended to render the code more maintainable - I.E. making it more modular. I would not, however, consider a conversion to another language entirely a necessary "refactoring". Refactoring is best done in small sections a little at a time and, as you said, with unit testing. As I said earlier, converting it to C# from VB.Net just because you "want to" is an ego trip on someone's part. It's a collosal waste of time and is a direct request to destabilize your product. Maybe the group is so lacking in things to do that this guy thinks he needs to make up a project with which to justify his existence. -Max
-
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:
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
Yield, doesn't have an equivalent in vb.net. And I may add that it was a major pain to convert a small piece of code from C# to vb.net retaining identical functionality.
"When did ignorance become a point of view" - Dilbert
-
Zhat wrote:
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
Yield, doesn't have an equivalent in vb.net. And I may add that it was a major pain to convert a small piece of code from C# to vb.net retaining identical functionality.
"When did ignorance become a point of view" - Dilbert
Well, now I know and agree. There's always something, but the point is to convert ALL existing code for those rare occasions. It seems alot easier to just leave them alone, Code in C# moving forward and if there's ever a problem, we can always code in VB.NET..the framework cares less...but we'll see what he says. :)
-
Well, now I know and agree. There's always something, but the point is to convert ALL existing code for those rare occasions. It seems alot easier to just leave them alone, Code in C# moving forward and if there's ever a problem, we can always code in VB.NET..the framework cares less...but we'll see what he says. :)
I'm pretty sure I can find a few examples of where vb can't be converted to C# too, but I just didn't have any examples in mind. My point was: If it works, don't touch it.
"When did ignorance become a point of view" - Dilbert