Reply to: C# course

[russell]

Lol, yeah apologies too.

We are in agreement then!

There are various good software development methodologies that work well, the real problem is the people trying to execute them are usually incompetent fools (i.e. managers).

[jmo21]

To put the record straight I'm not against agile and we all know the issues with traditional methodologies.

However your point illustrates very well a risk with agile projects. We agree that requirements aren't fully defined before development starts. In your example, after development has started the customer realises they have overlooked a key requirement(s) and whilst you state this can be prioritised at the expense of another, in reality this is never that straightforward and the project can become a runaway train or diluted e.g. the missed key requirement(s) grab a large chunk of development time or even worse not identified, so a solution is delivered not fit for purpose and back to the drawing board and already over budget.

Hence, the value of the business analyst to extract the key information from the customer asap not half way through development.

Apologies to the OP if this thread has gone slightly off track.

Lol, yeah apologies too.

We are in agreement then!

[oscarose]

I've worked on way more traditional waterfall driven projects that have been badly project managed and had the exact same scope creep issues.

In situations where the requirements cannot be nailed down 100%, this is EXACTLY when Agile is very good at dealing with things like scope creep.

The "thing" that creeps into scope after the start might be entirely valid. It might be more important than something else. So instead of, with waterfall, telling the customer they'll need to wait til phase 2 or having he project run past the nd date, you can prioritise the new thing at the expense of the other.

Now if you can't drop the other thing then you'll end up going past the end date anyway, but Agile can help you manage the fluidity of requirements very well.

To put the record straight I'm not against agile and we all know the issues with traditional methodologies.

However your point illustrates very well a risk with agile projects. We agree that requirements aren't fully defined before development starts. In your example, after development has started the customer realises they have overlooked a key requirement(s) and whilst you state this can be prioritised at the expense of another, in reality this is never that straightforward and the project can become a runaway train or diluted e.g. the missed key requirement(s) grab a large chunk of development time or even worse not identified, so a solution is delivered not fit for purpose and back to the drawing board and already over budget.

Hence, the value of the business analyst to extract the key information from the customer asap not half way through development.

Apologies to the OP if this thread has gone slightly off track.

[jmo21]

I agree that getting something in front of the customer quickly does help facilatate a collaborative approach and no doubt certain type of projects are suitable for agile.

However on an agile project, requirements aren't fully defined before development begins and are wide open to the damaging effects of scope creep and needs very strong project management. In my experience this has been lacking in some of the agile projects that have either failed or been heavily diluted.

I've worked on way more traditional waterfall driven projects that have been badly project managed and had the exact same scope creep issues.

In situations where the requirements cannot be nailed down 100%, this is EXACTLY when Agile is very good at dealing with things like scope creep.

The "thing" that creeps into scope after the start might be entirely valid. It might be more important than something else. So instead of, with waterfall, telling the customer they'll need to wait til phase 2 or having he project run past the nd date, you can prioritise the new thing at the expense of the other.

Now if you can't drop the other thing then you'll end up going past the end date anyway, but Agile can help you manage the fluidity of requirements very well.

[oscarose]

That is exactly what agile is supposed to be good at dealing with.

I'd say agile can help this lack of clarity by getting something in front of the customer sooner, helping things crystallise sooner.

I agree that getting something in front of the customer quickly does help facilatate a collaborative approach and no doubt certain type of projects are suitable for agile.

However on an agile project, requirements aren't fully defined before development begins and are wide open to the damaging effects of scope creep and needs very strong project management. In my experience this has been lacking in some of the agile projects that have either failed or been heavily diluted.

[jmo21]

I’ve seen mixed results from Agile projects mainly due to the lack of clarity of the business requirements.

That is exactly what agile is supposed to be good at dealing with.

I'd say agile can help this lack of clarity by getting something in front of the customer sooner, helping things crystallise sooner.

[Robinho]

I am BASIC to the core for 25 years. MS Quickbasic onwards. Currently Excel VBA, small amount of VB6, so VB.NET would be the sensible way to go but it just isn't as popular as C# currently. I am finding that a whole heap of the contract specs I am being sent are C# based, just because I have done odds and ends of enhancement work and mention it in my CV. Not happy to pursue a role where primary skill requirement is C#.

There are really 2 skills to the .NET family, primarily the .NET framework and then whatever language you stick on top of it.

In general if you are using VB.Net at a company you will be work on a horrible old codebase.

If you know .Net converting to C# is very easy. My advice would be to simply do a small project at home and use this...

VB.NET and C# Comparison

You can learn it within a weekend and be up to speed within a week.

A few tips for converting which may well catch you out at first...

Methods have (), the intellisense won't put them in for you. Properties don't have () and won't be taken away by intellisense
You have to specify ToString() if you want something to be a string, the compiler won't guess for you.
Don't forget the ;

You reckon? Depends what your background is I suppose, I have to work in both but just find VB to be so much more readable at a glance than C# with its curly brace garbage all over the shop. Same with Java, I find that a 'messy' language to read.

VB is awful. Keywords are far too long with the worst offender AndAlso vs && and Nullable(Of int) vs int?. The amount of implicit conversions is the worst thing about VB though. The only thing i like in VB vs C# is that you can implement an interface and give the concrete-class methods different names.

[oscarose]

But Agile anarchists want to do away with BAs

I’ve seen mixed results from Agile projects mainly due to the lack of clarity of the business requirements.

[amcdonald]

If you want a easy guide into C# and .Net books I'd recommend Murachs books

http://www.amazon.co.uk/Murachs-C-Jo.../dp/1890774227

[amcdonald]

Save your money; the work is going to the Indian imports.

Train in BA.

But Agile anarchists want to do away with BAs

[rsingh]

I am BASIC to the core for 25 years. MS Quickbasic onwards. Currently Excel VBA, small amount of VB6, so VB.NET would be the sensible way to go but it just isn't as popular as C# currently. I am finding that a whole heap of the contract specs I am being sent are C# based, just because I have done odds and ends of enhancement work and mention it in my CV. Not happy to pursue a role where primary skill requirement is C#.

There are really 2 skills to the .NET family, primarily the .NET framework and then whatever language you stick on top of it.

Knowing your background and industry, I'd go for C#. I found that my VB knowledge wasn't easily transferrable to .NET as they are both so different.

[Durbs]

I am BASIC to the core for 25 years. MS Quickbasic onwards. Currently Excel VBA, small amount of VB6, so VB.NET would be the sensible way to go but it just isn't as popular as C# currently. I am finding that a whole heap of the contract specs I am being sent are C# based, just because I have done odds and ends of enhancement work and mention it in my CV. Not happy to pursue a role where primary skill requirement is C#.

There are really 2 skills to the .NET family, primarily the .NET framework and then whatever language you stick on top of it.

With your background, if you learnt C#, you'd have absolutely no problem turning your hand to VB.NET anyway.

Agree C# is the best way contract-wise, far more work and its a very saleable skill to have but I find (and this probably goes against the language vs rates stats out there) that the VB.NET roles command a little more cash as there are simply less people who could fill the role.

Most .Netters I've worked with can comfortably use either but the majority of the newbies are solely using C# hence a bit of market saturation.

[Scrag Meister]

You reckon? Depends what your background is I suppose, I have to work in both but just find VB to be so much more readable at a glance than C# with its curly brace garbage all over the shop. Same with Java, I find that a 'messy' language to read.

To the OP, seriously, dont bother with formal training, just get a couple of books and set yourself an actual app to write. Choose say, a Twitter client. Sit down and write one referring to your books or Google when you get stuck. It wont take you long to write and at the end you'll have learnt 1000% more than any class could teach you. Then go over your code now you understand it better and re-code it to make it better, then repeat and repeat.

I am BASIC to the core for 25 years. MS Quickbasic onwards. Currently Excel VBA, small amount of VB6, so VB.NET would be the sensible way to go but it just isn't as popular as C# currently. I am finding that a whole heap of the contract specs I am being sent are C# based, just because I have done odds and ends of enhancement work and mention it in my CV. Not happy to pursue a role where primary skill requirement is C#.

There are really 2 skills to the .NET family, primarily the .NET framework and then whatever language you stick on top of it.

[garethevans1986]

You reckon? Depends what your background is I suppose, I have to work in both but just find VB to be so much more readable at a glance than C# with its curly brace garbage all over the shop. Same with Java, I find that a 'messy' language to read.

I feel the opposite way around, VB/VB.NET is "blocky" and C# flows alot better and is easier to read IMHO.

GE

[d000hg]

A class which is built around project work could be OK though, you basically just want someone to review what you've done and point out any horrible things so you don't learn them as a habit.