Good answers, already
I read a lot of good answers (the drive folder's image is a good one, for example, as is the object/concept separation/organization).
Still, some other, less "technical" arguments could help, not to explain why namespaces are better than the alternative, but to unearth the bad reasons namespaces are not used.
Every C#, VB.NET, Java, C++, whatever developer worth its salt on this planet acknowledge namespaces/packages are a good thing. Hey, they are even considering it in Mozilla's JavaScript.
I guess that your question on Stack Overflow has the "Authority Argument" touch...
^_^
Old Habits die hard
I believe you are falling in a case of "Old habits".
While I have no direct experience about VB.NET against VB6 old habits, I do for C++ against stripped-down C-like, C++.
Half the work...
When dealing with legacy habits, half the work is discovering they already use namespaces, without acknowledging it.
For example (this is most true for C++ devs colliding with "old fashion", C-like code, but it is viable everywhere, I guess), do they use prefixes for their symbols.
Do they have:
- AccountUser
- AccountPrice
- AccountId
- LoginUser
- LoginPassword
classes/symbols, and explain that the "User" of Account is not the same than the "User" of login, and thus, the prefix to differentiate them?
The "pattern" go right through the ceiling when they prefix their symbols by module (which is certainly the case for your code, if it is large enough):
Do you have a MyUtil DLL, as well as MyKernel DLL and a MyGui DLL ?
Thus, do you have:
- MyUtil_Something
- MyUtil_SomethingElse
- MyKernel_YetAnotherObject
- MyKernel_AnotherThing
- MyGui_SomeGui
classes/symbols?
If yes, then they should acknowledge they are already using namespaces.
If not, then either your codebase is too small (but your "9 projects" tell me it's not), or they are regularly problems of name collision... Which can be resolved either by the prefixing explained above, or even better, by namespaces.
The other half...
The other half of the work is making them explain why their "namespaces" are better than the one built-in in the language (this is the moment you should keep from banging your head against the walls in frustration because of lethal exposure braindead reasoning).
Again, you can use the Argument by Authority thing (What? You do believe know better than the Top Gun engineers from Microsoft?), but in this case, you should give examples of why the .NET (or whatever) namespaces are better than the one they use (or don't use).
For VB.NET/.NET, there already more than enough good arguments, and I won't go on the ones behind C++ namespaces because it would be out of topic.
But at the very least, using built-in namespaces makes the prefix mentioned above optional. Quoting an example from internet (I'm not very knowledgeable of VB.NET):
Imports MyWholeProject
Class HelloWorld
Public Sub Main()
Dim o As MyModuleAAA_MyObject = New MyModuleAAA_MyObject
Dim t As MyModuleBBB_MyThing = New MyModuleBBB_MyThing
Dim g As MyModuleCCC_MyGizmo = New MyModuleCCC_MyGizmo
REM etc.
End Sub
End Class
Is quite more verbose than the namespace enabled:
Imports MyWholeProject.MyModuleAAA
Imports MyWholeProject.MyModuleBBB
Imports MyWholeProject.MyModuleCCC
Class HelloWorld
Public Sub Main()
Dim o As MyObject = New MyObject
Dim t As MyThing = New MyThing
Dim g As MyGizmo = New MyGizmo
REM etc.
End Sub
End Class
And verbosity lead to more obscure code, and thus bugs. Of course, you could replace MyModuleAAA by something less long, like MMAAA... But then, it leads to more obscure code, etc. etc..
More uses of namespaces on .NET can be found by Googling, like: http://www.vbdotnetheaven.com/UploadFile/ggaganesh/NamespacesInVbDotNet04202005005133AM/NamespacesInVbDotNet.aspx
Project/Career related reasons
Those reasons are more relatived to project/career management...
Maintenance is not optional
If your application is an old dying cow, where changing a label or the content of a combo is worth 2 days of work (it does happen) then there is no point, perhaps, to an extra-work of refactoring. In the other hand, if the refactoring is automated, then you should do it anyway.
But if your application is supposed to be used in the future, then sabotaging it to keep it in the past is a bad idea. You'll pay for it, someday. Each hour supposed to be won by avoiding maintenance will be paid twice or tenfold the day it will become unavoidable (you know, the day when you won't have time to do it properly because it is urgent...)
Keeping oneself up-to-date is not optional
This argument is for engineers, who have a career, and must keep their job: Like applications, software engineers can become obsolete.
And it means that the obsolete developer, when applying to another job, will lose, too. Because, hey, who wants to pay for someone who just don't get something as simple as namespaces?
Experience is a good thing when it is coupled with knowledge of current state-of-the-art. If not, then it's only dinosaur-old cynical and useless rambling about "how it was better(read: simpler), in my time, when we did not need all those gizmos like objects".
Keeping oneself up-to-date is not optional (manager side)
By refusing to adapt to new features of the language (usually because "we know better, you know?"), engineers are just putting on concrete shoes while the competition is probably putting running shoes. This mean the application produced by an obsolete team will eventually lose. Period.
In a similar fashion, the team will hire new engineers, who probably know about the features, and who will become surprised, and then frustrated about the fact they are just programing like their grand-mothers did decades ago. The obsolete team won't keep new engineers very long (at least, the ones worth their pay).
Note that working on an obsolete product make it easier for top-level managers to decide it would get easier to rewrite it from scratch... And possibly somewhere else, with less-paid engineers and managers...