9

The team I'm involved in is more on the business side of the project and the development is being done by another company. This development company comes from an old VB6 background and have only in recent years started using VB.NET. This custom project is outside their main software product they develop on. Our business team has big concerns over not only their modern development skills in the .NET space but also the fact they are using VB.NET for this project and not what seems to be superior language in C#. Our thinking is if we asked them to develop in C# they would likely need to add new developers vs. using their existing old VB and now converted to VB.NET developers and thus we would likely get a better product.

Are we worrying too much about this from a project management and success standpoint. There just seems to be way more C# developer talent out there vs. VB.NET talent. Also, just worried these old VB6 developers will have poor development habits. Should the business side raise an issue on this or just let it be?

| improve this question | |
  • 4
    I really would like to understand how this contractor company was chosen, if, as I understand from your question, most of the people in your company don't think they are qualified for the job... – Alexis Dufrenoy Apr 28 '11 at 9:00
  • 1
    This whole post assumes C# developers are some how more "up to date" and never where (even one upon a time) VB6 programmers. It also assumes the development team has been left unchanged since the transition from VB6 to VB.NET. I'd start by questioning these assumptions... You know the old saying: "real programmers can write assembly in any language". Using a "better" language does not increase completion rate or completion speed: working with the tools they know best does, though. – André Caron Apr 28 '11 at 18:52
  • Yes, I agree, but do you not agree that most VB.NET developers are ones that moved from VB6? Sure many VB6 guys have moved to C# and I think and feel those are the more progressive developers since they made the leap to a new language, one that was born object-oriented. Those that didn't change languages I see as possibly lazy or less progressive. @Traroth - we have an existing financial tie to them so it makes it more appealing to upper management from a non-technical aspect. That wins out in this case – wilbev Apr 28 '11 at 23:30
6

A point I would make is that your selection of which company to use to develop your software is crucial, the language used to develop the solution is less of an issue to you and more of a problem for the company you are using.

If you pick a solid company that has been around for a long time and are willing to use them for the foreseeable future to maintain the code then your job is one of managing the link between your project and that company. They have the responsibility to delivery the business requirements using whatever language they see fit (within some limits you may wish to impose - it wouldn't make sense to start a new project in VB6 for example)

| improve this answer | |
  • Bottom line here is were stuck with this company for financial reasons that upper management is sold on. So it's very much a financial decision to use company vs. technical expertise. Personally I think the company is basically lazy and struggles to keep up with current development tools and practices. They have just recently moved from VB6 to .NET. Guess were screwed either way. – wilbev Apr 28 '11 at 23:35
4

You should consider a list of factors:

  1. Relationship with development team. They are a different company and you are concerned about technology they use but it doesn't seem you consider finding another vendor which would build something you want using technology you want. If you can change the development team it is one of options to consider, depending on other aspects. If you can't, well, read the rest.

  2. Type of project. If it is one-off type of project or chances are good no one else beside the original development team would be updating it in any way I would care that much about technology and focus on business side of the application. However if you consider different implementations for your customers and expect plenty of customization technology starts playing much more important role. But then, don't make it about "what seems to be superior language" but more about "we need such and such things, does this technology allow us to get them, get them cheap, and get them in a way which won't make maintenance costs skyrocket?"

  3. Developers' skills. If the development team is skilled with one technology and doesn't know other it isn't the best idea to force them to use the latter. If you go with known technology you can get pretty good results even though it can be considered as generally worse. However in your specific situation it can be opposite, because of development team's skills.

  4. Bad habits. Actually this one is technology-agnostic. You can have developers with bad habits no matter which technology you choose. Besides if you have your developers learning the technology from a scratch odds are they would screw something because of limited knowledge. With well-known technology you at least avoid this risk.

Anyway, the subject is worth discussing internally and, if you come to conclusion that technology is crucial here, externally as well. However don't fix yourself on a specific answer - it would probably come out from discussion.

| improve this answer | |
  • 1
    Thanks for your reply, that's good information. We already have a long-term relationship with this vendor so were pretty much stuck with them unfortunately. It's definitely not a one-off type, but a large, long-term project and product. – wilbev Apr 28 '11 at 4:35
  • 1
    From the development POV while I agree that C# is "superior" in many ways, the syntax is not that different from VB.NET. If they have good VB.NET programmers they should be able to program in C# as well... if they are VB6 programmers they will probably have difficulty in and bring along bad habits in any .net language. – Beth Whitezel Apr 28 '11 at 4:48
  • 1
    @wilbev: So if it is a long term engagement and you want their technology to follow the trends you should bring that on the table, officialy. I would not insist on using such technology in this exact project but let them change technology in more likely, the way they want. Such change is not simple task to make and it need to be properly done or one risks dramatic events to come (loosing developers, quality, productivity, estimation skills and many more). – Bartosz Rakowski Apr 28 '11 at 7:08
4

Software engineering is one of those fields that constantly changes. In one moment, we're developing in Java on EC2 and Tomcat using Struts and in the next moment we're using Google App Engine, Jetty, and Spring.

As long as the developers you're working with are smart, pragmatic, and capable of exploring and mastering new technologies, then I think you'll be fine.

From a software engineering perspective, and from a Computer Science perspective, once you learn how to program in one language, the learning curve for another drops significantly. My suggestion is to list this as a possible risk and maybe clarify what the plan is with the development team. They will most likely be able to alleviate your concerns if you talk with them.

| improve this answer | |
  • Thanks for that. I agree, we need to bring it up as a potential risk. Another angle I see for the reason of using C# is the fact we are asking for a smartphone version where Mono could save significant development and requires C#. – wilbev Apr 28 '11 at 23:40
2

If you manage properly your contractor, beginning with a contract protecting your interests and forcing the contractor to deliver a quality software in time and budget, you should be safe. Is somebody monitoring the progress of the project from your side?

What I would say is this: when selecting an IT contractor, don't only look at the price. Audit the development processes (are they using a methodology? Which one? Is it suited to your working processes?, Do they use up to date working tools, like continuous integration? etc), the used technologies (as you pointed out, VB.NET might be a bad choice for serious .NET development). A project failing will turn out much more costly than the most expensive contractor!

| improve this answer | |
  • Yes, our business side will be monitoring the progress closely. I will try to raise this as a risk to the project. – wilbev Apr 28 '11 at 23:48
2

Are we worrying too much about this from a project management and success standpoint?

Stop worrying, start managing risks. Identify risks associated with this sub-contractor and the technologies they are using. Analyze them quantitatively and qualitatively. Develop response plans. Assign risk owners. Start risk monitoring. That's a professional alternative to "worrying".

| improve this answer | |
2

There just seems to be way more C# developer talent out there vs. VB.NET talent.

I think this is an observation bias - you are seeing more C# devs because more of them are available and not working. I'm seeing lots of calls for skilled VB programmers to convert existing VB6 applications to .NET before the next version of windows comes out [1]. The replacement app uses VB.NET mostly because the team leads are more fluent in it, however a lot of new development is in C# and Python [2].

This development company comes from an old VB6 background and have only in recent years started using VB.NET.

This sounds somewhat like my last employer. Some features were done in .NET a long time ago, but if you looked at their commercially shipping apps, most were VB3 [3] and VB6 until recently. Apps ranged from VB6 to .NET 3.5 and you'd have to dig into DLLs to find out what was what. The programmer with the most seniority has been there 17 years and is still VB6-exclusive. The youngest programmer there as of December was me - and I left after being there 5 years. The first shipping product was made in VB3 about 18 years ago.

Should the business side raise an issue on this or just let it be?

My opinion is to let it be.

Notes:
1 - Microsoft has stated that Win7 and Server2008 are the last operating systems to include the VB6 runtime. This could mean that we have to figure out how to distribute it ourselves, or perhaps it means that the next operating system will break as much stuff as Vista did.
2 - The C++ and FORTRAN bits aren't getting converted.
3 - VB3 apps with VBXs could not be made to run on Vista.

| improve this answer | |
  • Thanks for comments. These large applications still in VB6 or even older code is probably a lot more common that we realize. It's amazing how long it takes for them to change. It's hard for me to get excited about VB.NET when every blog you see or conference you to to that's .NET related shows code in C#. The writing is very much on the wall. – wilbev Apr 28 '11 at 23:46
  • @Wilbev, the current app I'm converting runs about 12MB of VB6 source code (about 68,000 lines of code). At the last place, the VB6 part of the product that brought in about 60% of the office's revenue was about 5x larger. And because it involved tax-stuff, it had to change every year. It is my belief that VB is the new COBOL, and if it weren't for Microsoft's attempt to kill it with the next OS releases, I think there would be VB6 coders until the end of time (or the year 9999 which ever comes first). – Tangurena Apr 29 '11 at 0:13
  • Do you think VB programmers generally speaking have bad habits? Like not good object oriented practices? And what you think about these VB to VB.NET code converters? – wilbev Apr 29 '11 at 4:26
  • @Wilbev, some do, some don't. At the last place, we had one programmer who learned VB3 from the PHB (he is shaped like Dilbert's PHB), and she cannot transition to .NET and classes - all her .NET code looks like it belongs in VB6. The other VB6 coders understand classes just fine and know what to do, they are just stuck in VB6land. The converter was removed from VS2010, and the one inside earlier versions is a crippled version of ArtinSoft's tool. Expensive, and a rewrite takes more than just converting it so it compiles. If I made a webinar about how to do it, it would be about 4 hours long. – Tangurena Apr 29 '11 at 4:37
1

None of these are really worth raising with the development company, for the reasons you identify. If you are worried about it, stop using them. That is that.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.