Why is there Lots of controversy on vb/vb.net

[Affiliate60]

Yes, I just created this account...

Anyway, the title says it all. Why?
Many people say that it has bad syntax, and its too verbose.
Because of all this hate, I feel like I should switch to another Programming language.

I like VB.net, I've been Programming in vb.net since 2013 or 2014, and its cool.

Should I continue with VB.NET, or should I switch?

[jmcilhinney]

Anyway, the title says it all.

No, it doesn't really.

Should I continue with VB.NET, or should I switch?

Noone can decide for you but, if you like VB, you should probably stick with it. That said, if you're looking to get a development job then it might not be a bad idea to at least learn something else too. I learned VB.NET first and then C# afterwards. Already knowing all the general .NET stuff makes learning C# easier, because it's just syntax overlaying all the same principles.

[Affiliate60]

No, it doesn't really.

Eh, Well I said "The title says it all" because what I'm wondering is pretty much in it..You're probably right though.

That said, if you're looking to get a development job then it might not be a bad idea to at least learn something else too.

I am planning on Learning Java one day. Once I'm Not lazy, I will start some Java. I might or might not get a job as a software engineer or whatever, I probably will get a Job as doing Computer repairs... or something. Not quite sure yet.

[NeedSomeAnswers]

Anyway, the title says it all. Why?

There isn't that much controversy really, it just that some old VB6 programmers dont like .Net for various reasons, some reasonable many not but if you want the details then there have already been many threads on this forum on this subject which you could search for.

Many people say that it has bad syntax, and its too verbose.
Because of all this hate, I feel like I should switch to another Programming language.

I like VB.net, I've been Programming in vb.net since 2013 or 2014, and its cool.

There is nothing wrong with the VB syntax and if you like the language i would just ignore those voices

That said, if you're looking to get a development job then it might not be a bad idea to at least learn something else too.

Yeh i don't see development as picking one language and sticking with it, but evolving your skills and learning whatever tools are necessary to get the job done.

I have been developing for many years now and i have learnt 6 languages to some degree of other, currently i am doing more and more web stuff which involves lots of CSS and JavaScript. I have never moved from a language i have just learnt new ones when i needed to.

[FunkyDexter]

it just that some old VB6 programmers dont like .Net for various reasons

I'm not sure this one's part of the old 6 vs net debate. I read it as VB vs Rest of the World. Not sure though.

There's always been snobbery toward VB, whether it was toward the old school VB6/VBA flavour or the newer .Net flavour. I think a lot of that criticism is rooted the fact that it's very easy to pick up in comparison to other languages.

It's largely written in plain English, it's GUI design tools were always way ahead of the curve, it had a fully integrated ide when C programmers were still using notepad (or vi, more likely), it had source control plugging into the ide when other languages were still requiring you to work from a separate file explorer...

The combination of instinctive language and strong tooling made it much easier for beginners than, for example, Java or C and that meant beginners adopted it in spades. Personally I view that as a very good thing but it did have the unfortunate side effect of giving C programmers an excuse to sneer at VB programmers, portraying them as amateurish. Taken as an average VB programmers probably are more amateurish than programmers of some other languages but that's only because VB enables the bottom end of the spectrum, not because it limits the top.

None the less, the perception sticks. I personally switched to C# years ago because the industry tends to take me more seriously as a C# programmer than a VB programmer... which is ridiculous because they're functionally all but identical. But I'm a pragmatist and I make more money this way.

The one criticism I would make of the VB world was made by SittenSpyne in another thread a while back: I notice a general reticence amongst VB programmers to advance their software engineering skills. Walk into a C#, Java or Python forum and you'll see discussion on patterns, abstraction, extendability and the Open Closed Principle... Walk into a VB forum and you'll see discussions on how to format a text box. Again, I think this is probably a function of enabling the bottom end rather than limiting the top but it does seem to be a trap that many more advanced VB programmers fail to escape until they migrate to/adopt different languages and find themselves exposed to those conversations.

[JuggaloBrotha]

I am planning on Learning Java one day. Once I'm Not lazy, I will start some Java.

Honestly if you're planning on learning Java I would do that before learning anything .Net. Java and .Net (C# is far closer to Java syntax) are very similar but different enough to become frustrating after doing things the .Net way.
What I mean is Java's been around for a very long time and while it and .Net are both OOP with full fledged frameworks backing them .Net was created much more recently and has a lot more conveniences that Java hasn't been re-written and upgraded to (yet, I'm hopeful they will create Java 2.0 someday) so if you learn .Net first you get used to instinctively using concepts like Properties and Collections, neither of which exist in Java so when you work on Java tutorials (or take a class) it's frustrating to not be able to make a property for your class and having to step back and write two separate functions (one for get, one for set) for everything in your class. I also tend to use Collections (called generics) for most everything in .Net and what Java calls generics is a poor layer they threw on top without actually implementing it in the language so it's quirky at best.

Just a heads up with my experiences and my friends around the world whom have learned .Net first, then tried to learn Java years after.

[Sitten Spynne]

Long story short: programmers bicker about everything, but the "controversy" around VB almost exclusively revolves around people trying to create a hierarchy of "good" programmers and "bad" programmers. It's a waste of time, and mostly the people who have qualities I agree are associated with "good" programmers don't participate.

The main problem is a bit of VB history. It was, in all of its forms, marketed as a programming language for "people who aren't programmers". I don't know why that appeals to bosses. Would you hire a "plumber who isn't a plumber" when remodeling your bathroom? Would anyone hire an "accountant that isn't good with numbers"? It's a goofy concept.

That was a stupid marketing buzzphrase though. At the time VB was gaining popularity, you really only had C/C++ if you wanted to develop Windows applications. C and C++ are difficult to use, and require a lot of discipline. Doing very complicated things takes careful, slow work and even more careful, slow design. VB offered an environment where you could be effective without so much discipline or thought. That meant a lot of people who would never finish a C/C++ program could be effective and finish even complicated jobs in VB.

Obviously, this hurt the feelings of the C/C++ developers of the time. They were rightly proud of their talents, but wrongly defensive of their Old Boys Club. Programming SHOULD BE hard, they said. VB CAN'T BE capable of doing what they did, they said. They were wrong. VB6 is probably the best way I can imagine to write a Windows application in the timeframe of the 1990s. Sure, there were things it couldn't do: there's always some level of complexity where you have to bite the bullet and get closer to C/C++. Whatever.

But this also meant there were a lot of people using VB who didn't really care or know there was a concept of writing "clean code". These people weren't hired to be programmers, they just happened to have some proficiency and needed a program to help them do their job. Newbie programmers write bad code, and if they aren't motivated to learn how to write good code they never advance. Since they tended to be the only person in their company/team who knew anything at all about programming, they didn't have a way to get better, so they stayed stagnant and eventually their increasingly-important code became unmanageable.

Those people are the people that are held up as "examples of VB programmers". That's a selection bias. There's terrible developers in every programming language, and if we only look at them we'd certainly wonder why programmers get paid so much. There's also really good VB developers out there, and they're largely ignored. But, due to the habits of successful developers, they also tend to be known for work in many other languages than VB!

"Successful developers", the people who continuously improve, learn early that every programming language has limitations that make it unsuitable for certain tasks. So they learn multiple languages, trying to cover their own weaknesses with languages that make the problems they need to solve easier. It turns out that VB .NET has identical weaknesses to many other popular languages today, and few advantages. So not a lot of these programmers specialize in VB .NET or even claim proficiency. If you know C#, you can read some VB .NET, so for most people that's "good enough".

Now, there are some ways that VB has earned this reputation, and I was mentioned for having made this argument before.

If you are a newbie in Ruby, Python, Java, C#, Go, Swift, or dozens of other modern languages, you will be encouraged early and often to start learning about software engineering practices. Their tutorial materials try to teach you that programming is hard, so you need to learn practices that make sure you are doing things consistently well. They advocate for very small, single-purpose units of code that are very easy to test and PROVE function correctly. And they encourage you to join the still-lively discussions about the "best" way to solve many common problems.

If you are a newbie in VB .NET... life is hard. You can't even do a web search for a random problem and only get VB .NET results: what you'll get is a mixture of VBA, VBScript, and VB6 that may not even be functional in VB .NET. When you do get VB .NET results, often its one of the "less motivated" programmers who found a way to hand-edit some VB6 to kind-of-sort-of work in .NET. When motivated programmers suggest the software engineering practices that all of the other languages hold dear, their carefully-written posts are ignored in favor of copy-paste mishmashes that work with no explanation. Read a few dozen topics on this forum. How many people answer a question about a 100-line function that does 12 different things with, "Well, first let's split apart your 12 concerns, so we can understand if each is working"? If you even MENTION the concept of creating a new class, your post is ignored, and dozens of people encourage this behavior.

Also, read through the posts on this forum. I have no doubt this exchange has happened dozens of times:

Hello sirs! I need a codes such that if I give it two numbers like 3 and 4 it adds them together to make result 12. Here is a screenshot of my form, my professor hasn't explained this to me.

So, TL;DR:

Lots of people want to get "better" at programming. They like to hang out with people who try to find the "best" way to do anything. Historically, VB was marketed to people that "don't care" about getting better. So while VB is capable, it attracted more people who don't care about software engineering than any other language. That means it's easier to find a "bad" VB developer, and when you try to help make them better people will fight each other to disagree with you and say you're overcomplicating things.

So for a "good" developer in today's world, there's more value in ignoring VB .NET entirely. And if someone says they specialize in VB .NET, "Why?" is a very good question. I can tell a lot about a person's answer. The next-best question is, "If you had to use C#, would you learn it?" I would never work with a person who would say, "No."

[FunkyDexter]

Long story short

That was your idea of short?!

[szlamany]

This all pre-dates VB6 and the PC world.

I did PDP-11 and VAX-11 BASIC programming in the early 80's on mini-computers with green screen dumb terminals.

Our group was looked down upon by the C-folk. They did more driver code - more real-time processing stuff.

We did line-of-business app's.

I believe that's a bit of arrogance and a whole lot of self-importance.

[Sitten Spynne]

That was your idea of short?!

I spent something like an hour paring it down! I think there's a lot of reasons VB ends up being a scapegoat, and it all boils down to the divide between people who are "driven" and "not driven", and the mysterious attraction VB has for those who aren't.

At this point, VB is more or less a clone of C#, but the old rumor that it's designed to be easy keeps a constant flow of newbies coming in. This, combined with most people having no clue how to hire a programmer, leads to some really interesting evidence people use to hate VB.

I'll bet Java's got just as much of a cesspool of know-nothings, probably bigger, because it's also accessible and used as a common "starter" language. But there's technical reasons to really not like Java, so it tends to get flak for those instead of the "please sirs write this code for me, I'm in over my head and don't even know it" posts.

I don't even know what keeps bringing me back to VB forums, other than rarely I see someone have a lightbulb moment and it makes me feel really good.

[techgnome]

So for a "good" developer in today's world, there's more value in ignoring VB .NET entirely. And if someone says they specialize in VB .NET, "Why?" is a very good question. I can tell a lot about a person's answer. The next-best question is, "If you had to use C#, would you learn it?" I would never work with a person who would say, "No."

Statement - I've specialized in VB.NET
Q: Why?
A: Because I can. I've been working with VB since the days of VB3.0 I've seen it go through a lot of incarnations and over that time, learned how to work with & around it. It's what I'm strongest at. I've thought about moving to a different language a few times.
Q: If you had to use C#, would you learn it?
A: In a heartbeat. Even though I already know most of the fundamentals (had to learn C# when .NET first came out since ALL of the examples at the time were in c#) there are still a few things to learn. But I'd roll with it and add it to my arsenal of dev tools.

Now, I realize I'm an aberration of sorts. I didn't come up through the traditional model for developers. I didn't go to school for it. It's something I came across our of curiosity, it stuck, I had a knack for it and I've managed to figure out how to parlay it into first a hobby, then a career that has spanned most of my life - since the summer of 82. I didn't even own a computer, or ever really used one. I don't even remember what lead me to choose that class.

Anyways, I do more than just VB too... and VB is not my first language. I originally started with Apple BASIC, then PC/GW-BASIC, ADA, learned SQL somewhere along the way (using dBaseIII), ASM, Pascal, some C/C++, HTML, Javascript (those last 2 are arguably "languages", but they are part of my programming tool kit), C#, VB3-VB.NET ... I'm sure there's more that I've worked with. It goes back to what Sitten was saying about constantly evolving and growing. I rolled with things over time.

While it's easy to blame the language - VB does let you get away with somethings that other languages don't (Option Strict anyone?) But that's like blaming the gun for shooting yourself in the foot. It's the lack of discipline on the part of the programmer. Granted sometimes it's because they're not a developer by trade. sometimes it's just due to a lack of understanding on their part. But as long and people continue to just feed out solutions with no explanation or even attempting to understand the problem and get the poster to work through it properly, we're just reinforcing that behavior. Some languages have very strict constructs. VB's history with BASIC loosens a lot of that up. If BASIC hadn't been what it was, VB wouldn't be what it is. And the forums would be called CSharpForums and we'd be having fights over C# vs C++ ...

-tg

[techgnome]

I don't even know what keeps bringing me back to VB forums, other than rarely I see someone have a lightbulb moment and it makes me feel really good.

Yeah, I've wondered about that too... not what keeps you here, but what keeps me...

Posts like this:

Hello sirs! I need a codes such that if I give it two numbers like 3 and 4 it adds them together to make result 12. Here is a screenshot of my form, my professor hasn't explained this to me.

Scare the bejeebeez outta me... makes me wonder if there is hope for the next generation...

-tg

[FunkyDexter]

makes me wonder if there is hope for the next generation

None at all. Picard will never live up to Kirk's standards.


sorry

[JuggaloBrotha]

None at all. Picard will never live up to Kirk's standards.


sorry

#1 I order you to take a #2 -Capt Picard

[Gruff]

How many Vulcans does it take to screw in a light bulb?

Approximately 1.00000000000000000000000000000000

[Affiliate60]

Sorry for bumping a 2 day old thread, I barely do things here.

Also, I may change my mind later, And learn C#... Atleast THAT language doesn't have lots of HATE..

Also, I know there are Other threads similar to this one, but the results I've gotten are all from 2005-2008(or 2009?), And I thought I could make a latest version of a thread like those.

I was also wondering why lots of people hate vb, so that's what made me create this thread.

Okay(if this becomes long, oh god.),

techgnome,

If BASIC hadn't been what it was, VB wouldn't be what it is. And the forums would be called CSharpForums and we'd be having fights over C# vs C++ ...

True...very true.

Sitten Spynne,

(Very long answer you got there.)

If you had to use C#, would you learn it?

I would.

"Successful developers", the people who continuously improve, learn early that every programming language has limitations that make it unsuitable for certain tasks

Many haters would also say that VB say too many painful Limitations. Which is ONE OF THE REASONS WHY PEOPLE IGNORE VB.

I forgot the some things I was about to say, If I can remember, I will post it here.


OTHER STUFF:

There is nothing wrong with the VB syntax and if you like the language i would just ignore those voices

Other people also say that VB.NET is bad Because it is mostly English, and like what FunkyDexter says, its a Very Easy language to pick up.

I do more than just VB too

Which is good, because Some people who program in VB says you should also use C#, for libraries and things.

VB does let you get away with somethings that other languages don't

Some haters also say that VB Doesn't have any ways of getting away with other things, But I think that is just over-reactions.
Which is what also confuses some people:
Why do some people learn VB, then later they say that is a garbage language that can't do anything?
"CAN'T DO ANYTHING", I mean really, VB Can do things, That's also a sign of over-reaction.

Which leads me to another question: Can VB be used for some "advanced" stuff? Can it?
Many haters would laugh at that question, and they would probably say that VB is a beginner language, and it can't do "advanced" stuff.

I am not sure what else to say here, due to the fact I forget things randomly at times. >:(

[jmcilhinney]

Why do some people learn VB, then later they say that is a garbage language that can't do anything?
"CAN'T DO ANYTHING", I mean really, VB Can do things, That's also a sign of over-reaction.

Yes, people do enjoy hyperbole.

Which leads me to another question: Can VB be used for some "advanced" stuff? Can it?
Many haters would laugh at that question, and they would probably say that VB is a beginner language, and it can't do "advanced" stuff.

VB6 was built with ease of use in mind. It was considered by many to be a programming language for non-programmers. It could do a lot and was very productive for many things, particularly GUI stuff. Many people found ways to make it do "advanced" stuff but they often had to implement hacks or mess around quite a bit to do so. To those who don't really use either, VB.NET still looks like VB6 and is viewed with the same disdain by many. VB.NET has been built from scratch to overcome the need for those VB6-style hacks to do many more advanced things though. In reality, anyone who thinks that C# is somehow much better than VB.NET simply doesn't know what they're talking about. Unless you're making use of pointer support in C#, which very few people do, VB.NET is pretty much exactly the same except for the syntax. That's really what it comes down to though: C# uses a C-based syntax and VB.NET uses a BASIC/VB6-based syntax and many people judge them on that and their existing perceptions of those rather than on the languages themselves.

[digitalShaman]

tha!! c++, c#, vb.net, Java... all Bullocks! These are no real programming languages and all Limit you in your possibilities!!! here is what real programmers go for:
http://www.ninisworld.com/oddsends/j...ogrammers.html

[FunkyDexter]

here is what real programmers go for

That made me smile and does illustrate the point quite well.

Languages tend to be pitched at a certain level and tend to operate best at that level. VB.Net, VB6 before it and c# are high level languages which are really good for building applications. It's very easy to describe an algorithm, design a GUI etc. They're not so good for writing performant engines which want you to directly manage your memory and chip resources. ASM or even machine code are the ultimate goal if your writing something that's got to be performant and small and can exist bang up against the chip but writing a Gui would be sheer hell. C sits somewhere in between.

Note that direct memory allocation is available in .Net and was available in VB6 if you really wanted to use it. And it's perfectly possible to write a GUI in ASM if you really want to. But in either case you'd have to ask yourself why your doing it the hard way.

People who operate at the bottom of the stack tend to sneer at those above them because they feel that what they're doing is somehow more pure and elegant but, in truth, the only person who should be doing any sneering is the guy who used the right tool for each job. I've had the good fortune to be around some embedded developers at the moment they've had that realisation.

[Sitten Spynne]

That made me smile and does illustrate the point quite well.

Languages tend to be pitched at a certain level and tend to operate best at that level. VB.Net, VB6 before it and c# are high level languages which are really good for building applications. It's very easy to describe an algorithm, design a GUI etc. They're not so good for writing performant engines which want you to directly manage your memory and chip resources. ASM or even machine code are the ultimate goal if your writing something that's got to be performant and small and can exist bang up against the chip but writing a Gui would be sheer hell. C sits somewhere in between.

Note that direct memory allocation is available in .Net and was available in VB6 if you really wanted to use it. And it's perfectly possible to write a GUI in ASM if you really want to. But in either case you'd have to ask yourself why your doing it the hard way.

People who operate at the bottom of the stack tend to sneer at those above them because they feel that what they're doing is somehow more pure and elegant but, in truth, the only person who should be doing any sneering is the guy who used the right tool for each job. I've had the good fortune to be around some embedded developers at the moment they've had that realisation.

All of this.

A good developer isn't the person who finds the way to write the code the fastest, or with the fewest cycles, or in the least amount of RAM. A good developer is the person who finds the way to write the most correct software using the least of these resources that matter:

• Time
• Money
• People

Sometimes that means picking the "wrong" language for a job, because using the "right" language puts one of those budget categories in jeopardy. Often, picking a .NET language over C saves so much time/people/money it's worth the memory/speed losses. Customers are often happy with "any results", and don't much care if they're getting "optimum results". When you have results, you have the luxury of time to find better ways to get them!

[digitalShaman]

A good developer is the person who finds the way to write the most correct software using the least of these resources that matter:
•Time
•Money
•People

i'm not sure if i agree with that. maybe its depending on what you mean with "most correct software"? time, Money, People are all relevant ressources, but someone who slaps some stinky code together that somehow works in almost Zero time, and therefore wasting Little Money and People isn't a good programmer in my eyes. For me there are also other things that matter, like is the code readable, stable, maintainable, performant etc. something that a Client or Sponsor will never see, but still it defines a good programmer. ok, i also slap some stinky code together sometimes, but only when i know that this is a one shot Thing and will never be used again and after considering the tradeoff between what it takes to make it clean and the Revenue in Terms of what benefits a clean code in this Szenario has.

but, yes this is not related to the Technology used.

[Gruff]

I sometimes wish I worked with a team so I could be exposed to a broader spectrum of software development.
As the only developer in house I have no immediate need to learn anything more than VB.NET or VBA.

That of course could change if I get hired elsewhere so I am trying to find time to learn other languages.
Finding the time is the hard part.

[Sitten Spynne]

i'm not sure if i agree with that. maybe its depending on what you mean with "most correct software"? time, Money, People are all relevant ressources, but someone who slaps some stinky code together that somehow works in almost Zero time, and therefore wasting Little Money and People isn't a good programmer in my eyes. For me there are also other things that matter, like is the code readable, stable, maintainable, performant etc. something that a Client or Sponsor will never see, but still it defines a good programmer. ok, i also slap some stinky code together sometimes, but only when i know that this is a one shot Thing and will never be used again and after considering the tradeoff between what it takes to make it clean and the Revenue in Terms of what benefits a clean code in this Szenario has.

but, yes this is not related to the Technology used.

In my book, software can't be "correct" if it isn't maintainable and doesn't have a test suite that proves it meets its requirements. Professionals don't deliver less.

Sometimes the code isn't as clean as we want it to be, but there's no real code quality yardstick. On one end of the spectrum there's code that's REALLY bad and easy to spot, but the other end of the spectrum's very fuzzy. The best measure, really, is "How hard is maintenance on the program?" Because that's really just a time/money cost further down the road, and extra effort today can multiply the benefits tomorrow.

[techgnome]

In my book, software can't be "correct" if it isn't maintainable and doesn't have a test suite that proves it meets its requirements. Professionals don't deliver less.

I'd like to work in your utopia... 1) our products team does use automation testing for what they pump out. 2) as some one who then consumes their code for customization, it doesn't always make sense and has been known to look like crap at times. 3) the customization team doesn't use automation testing (we have an actual QA dept that checks everything) but we do subscribe to a strict coding standard that allows the code to be handed off to support for maintenance and we rarely ever see it again. 4) we deliver once... products releases patches monthly, with quarterly service packs ...

So who's the professional here? Either neither dept is, or both are, because according to your yardstick, neither dept is professional.

-tg

[Sitten Spynne]

This argument, and the supporting evidence, is another form of the "What's wrong with VB?" argument. Tests don't make code magically good, and it's easy to write tests that don't prove anything but still meet silly metrics like "coverage". Good code can be written without tests, so it leads one to wonder why we need them at all. Testing is a valuable and very difficult skill, and it's a shame we treat it like something you learn AFTER you spend years perfecting your craft. The truth is, writing good code with good tests is harder than just plain writing good code, and starting after you already have habits means unlearning a lot of things. So it's better to just learn how to do them both from the start, and feel a little icky about code that doesn't have them.

Some contractors are licensed and bonded. That means they've gone through a process to prove they do things the right way, and if they screw up and an accident damages your property while they're working, they've got someone willing to compensate you for that and they might lose their license. But everyone makes mistakes, and even if you only hire licensed and bonded contractors you are at their mercy. They might be shady, and know they can cut this or that corner without anyone noticing. This doesn't make the licensing process bad: they are putting their career at risk to make a buck. On the other hand, I don't really care to listen to a contractor who /isn't/ licensed or bonded tell me that the process isn't worthwhile. My homeowner's insurance won't cover any damage done by a contractor that isn't, so I won't consider them. The risk is too great.

I don't really think no professional releases code without automated tests. (I also seem to believe in triple negatives.) But I do question anyone who believes they have no value. It's OK to say "It's hard to do them right, and if done wrong they make things worse". But when someone says "My code's great, I don't need to prove it", I get scared. That's the contractor I don't want to hire.

If you have a process for verifying your code, you pass the bar. But that process is seat belts, and automated tests are air bags. If properly written, automated tests tell you if it's even worth bothering with the hours-long manual tests. If properly written, they tell you within 5 lines where the error is. If properly written, they mean you never accidentally re-introduce a bug when fixing unrelated things. They answer questions like, "Did restructuring this class break component B?"

But there's a million ways to get them wrong, or use them as a false promise of quality. That erroneously turns a lot of people off.

[Sitten Spynne]

Bleh. Ugh. I wish I could blame that post on something. I got to thinking more and more and in hindsight, I think you're right. I shouldn't say things like "professional code requires automated tests", because it's inherently designed to ruffle feathers. It sure as heck doesn't open you up to my side of that equation.

I think they're valuable, but I've written some pretty good large-scale projects with everything from no tests to terrible tests that were a waste of time. Some of my best work was an API that had 8 or 9 redesigns over its lifetime, and somewhere around #4 or so I realized 80% of the effort was adapting the test suite to the new API, so I dropped everything but the integration tests and got a lot pickier about what I tested. The next-coolest thing I ever wrote was an inherited API that I never got around to writing tests for, because it was 2 weeks late when I inherited it and it never got any less late.

Time vs. quality's rough. I like people that have some bar they never drop under for quality, or at least feel really bad if time constraints force their hand. It's not my place to make sweeping generalizations, and it's as stupid to say professional code requires automated tests as it is to say it requires C#.

[FunkyDexter]

I shouldn't say things like "professional code requires automated tests",

I don't think you did. The message I got from you was that you would consider someone who said "automated test have no value, my code surely wouldn't benefit from them" to be a bad developer. That's not quite the same thing and it's also something I agree with.

TG's deliverables (nb not necessarily code) probably would benefit somewhat from automated testing but that's not the question. The question is whether it would give a benefit to the customer that would outweigh the cost of restructuring the team, updating the process, developing new skills (though I suspect TG already has them, at least 90%), etc when they already have a way of working that is producing the results they need. By the sounds of things they've looked at it and decided it wouldn't - and they're probably right.

Automated testing and TDD is no silver bullet and, despite some high profile failures and a lot of proselytising from the Agile lobby, an awful lot of good product got delivered before they were introduced. They surely provide some benefit and I personally have found it a more comfortable way of working once I got used to it and when I've been allowed to (I'm a contractor so I generally have to follow whatever procedures my client dictates) but as long as your deliverable is fit for purpose I don't really care how it came into being.

Maintainability may or may not be part of the definition of "fit for purpose". I think many of us who work with big business apps forget that an awful lot of the time the requirement is for a something rough and ready that will likely be thrown away in a years time. Here's the story of what I think is possibly the best fitting piece of development I've ever been involved in:-

I used to work for a company that sold shutters and blinds. These would be delivered to a customers premises in boxes which were actually quite expensive so we wanted to reuse them. A lot of the installers weren't particularly careful about the way they opened the boxes and would ruin what would otherwise have been a perfectly reusable box. The boss decided he wanted a way of ensuring every box got used at least 3 times and, if it didn't, he wanted to know which installer had the box last. We proposed a system that printed barcode labels to itemise each box, a barcode scanner the depot could use to track the boxes in and out and a backend system that would tally exactly where every box had been over the course of it's life. In the meantime they kept a tally on the boxes using a marker pen.

The finest piece of development I've ever seen was not our all singing, all dancing barcode scanning system (which took about 6 months to deliver due to technical hitches, lack of user engagement etc.), it was the marker pen. That marker pen delivered every bit of functionality the business needed for about 50 pence.

Our job is not to deliver the best possible system. Our job is to solve the problem the customer needs solved.


edit> Just reread post 23 and you kinda did say that. I think I understand the context you meant it in though.

[Sitten Spynne]

Maybe if I do outline form it won't be a wall of words, how I feel is sort of:

• Adding tests after a project exists is very hard, and often involves a lot of refactoring just to facilitate the tests. So it's best to start with tests if you plan on using them.
• If you don't plan on using automated tests, you should plan on using some form of manual verification. If you aren't planning at least that, I feel very sorry for your customer.
• Projects that are intended to be used short-term and thrown away and have a tight schedule probably spend more effort on testing than they should.
• I've worked on a lot of short-term projects that suddenly turned into business-critical 10-year systems. Isn't that the story behind every "horrible VB6 application" ever?
• Even some short-term projects have catastrophic results if they fail: I like to make sure I test those catastrophic cases even if I'm not committed to full-blown unit tests for everything else.

That third point hurts badly this year. In April, I got called aside to do a "quick integration project for a customer demo, we want to get them off their old system and on our new system." I was told "We might do this kind of thing for other customers, so try to be a little general". What they actually meant by "demo" was "a demonstration that they don't have to use our new system", but that was a surprise I didn't get for 3 months. Then I was asked to add a "quick trial feature", that's now a "sales contract" with "quality of service" guarantees. I found that out 4 months in, when in a meeting someone asked, "Why do you keep calling this a demo?"

So heck no, from now on when I get told to do a "quick tool" I'm either getting it put in the problem definition that there is a decommissioning date, or I'm taking the effort to write tests for it. My untested code has a bad habit of becoming my legacy, and by "my legacy" I mean "the things I work on instead of what I want to do because no one else can tell if they broke it."

This is turning into a wall again, but a note:

I see a lot of questions on this forum that look like the poster needs to climb a mountain like "parse 50 different HTML files." The sensible thing, and a thing that a test-driven approach would make one do, is to start with 1 file, then move to the 2nd file when that works, and so on. You slowly accumulate victories until you have the whole solution.

Instead, most people sit down and write the code for all 50 files, then are bewildered when it doesn't work. Which file is failing? They don't know. Is it more than one file? They don't know. Which parts are working? They aren't sure. And when you ask them to pare down to just one file at a time, they look at you like you're from Mars.

If you would approach the problem one file at a time, even if you're not writing unit tests, you are thinking in terms of them. Writing testable code is about decomposing the system into "small" units, with varying granularities of small, and ensuring those units work before writing other units. I strongly feel that if you don't write your code this way, your rate of success will be dramatically lower. Having automated tests is a sign that you're thinking that way, and for me they were the thing that taught me to think that way at all times.

Something about the way VB and C# are taught encourages people to think big picture, not small picture. VB is pitched as letting people have a lot of success quickly, but decomposing problems is slow, thoughtful work. When we teach people to sprint as fast as possible, we set them up for failure as the scale of their projects increase. That's why there's controversy around VB. It feels like the culture around the language is to teach people, "Programming isn't hard, if you are having to think you're doing it wrong. Somewhere out there is an API call that does everything you need."

Nothing could be further from the truth. If it were true, you wouldn't have a job.