OT: Binary Search - Should They Know It?

[not_a_commie]

Applying UML and Patterns (preferrably)

I confess that I don't consider a knowledge of UML necessary. It's
something that can be looked up when needed. And most companies simply
don't use it or anything like it. I do, however, consider search and
sort algorithms, dictionaries, virtual method lookups, and pointer vs.
value vs. reference types as essential knowledge for any C# coder I
would hire.

 

[jehugaleahsa]

I think you need to ask yourself what meets your standard of good. To
suggest only 5% of developers are good suggests to me there is some flaw in
the way you percieve people, although it may be that you are that good we
all look poor.

To me someone is good when they time and time again deliver software to spec
and software that is relatively maintenance free. I have seen many people
that can do this, and not all of them guru's if you want to put it that way.

When I started working here, I was assigned to rewrite a smallish web
application. After 3 years I have come to learn how poorly it was
written. BUT, it has been stable for 3 years and is easy to enhance.
The architecture may have sucked and it may have a bunch of features
that don't do me any good, but the code works. Folks who get paid a
lot more than me in other regions are known for constant bugs,
emergencies and angry customers. I should know, I have to maintain
some them and the code is a nightmare.

Lets put it this way what % of the .net framework do you need to know to
solve most day to day business problems. Companies got by for years on
software written using VB. What ever you say about VB it solved lots of
problems for businesses globally and they got by very well, now look at the
functionality the .NET framework gives us we could get by probably by using
10-20% of that and solve most issues thrown at us.

You also have to weigh in the cost of upgrading those systems. It
might make a company 100K one year and then cost them 300K the next.
We have a ASP/VBA program that copies data into a Word document in a
label format. My company has probably spent close to 100K trying to
find another solution that doesn't require ActiveX and macros. Why the
hell isn't a mail merge good enough? In the long run, the small
savings will be overran by the maintenance costs. It costs a lot less
for a secretary to spend an hour doing a mail merge than it does for a
50K/year developer writing a program to do it automatically.

 

[jehugaleahsa]

I think you need to ask yourself what meets your standard of good. To
suggest only 5% of developers are good suggests to me there is some flaw in
the way you percieve people, although it may be that you are that good we
all look poor.

To me someone is good when they time and time again deliver software to spec
and software that is relatively maintenance free. I have seen many people
that can do this, and not all of them guru's if you want to put it that way.

When I started working here, I was assigned to rewrite a smallish web
application. After 3 years I have come to learn how poorly it was
written. BUT, it has been stable for 3 years and is easy to enhance.
The architecture may have sucked and it may have a bunch of features
that don't do me any good, but the code works. Folks who get paid a
lot more than me in other regions are known for constant bugs,
emergencies and angry customers. I should know, I have to maintain
some them and the code is a nightmare.

Lets put it this way what % of the .net framework do you need to know to
solve most day to day business problems. Companies got by for years on
software written using VB. What ever you say about VB it solved lots of
problems for businesses globally and they got by very well, now look at the
functionality the .NET framework gives us we could get by probably by using
10-20% of that and solve most issues thrown at us.

You also have to weigh in the cost of upgrading those systems. It
might make a company 100K one year and then cost them 300K the next.
We have a ASP/VBA program that copies data into a Word document in a
label format. My company has probably spent close to 100K trying to
find another solution that doesn't require ActiveX and macros. Why the
hell isn't a mail merge good enough? In the long run, the small
savings will be overran by the maintenance costs. It costs a lot less
for a secretary to spend an hour doing a mail merge than it does for a
50K/year developer writing a program to do it automatically.

 

[Cor Ligthert[MVP]]

"Paul"

I think you need to ask yourself what meets your standard of good.

That sentence was enough Paul.



Cor

 

[Cor Ligthert[MVP]]

"Paul"

I think you need to ask yourself what meets your standard of good.

That sentence was enough Paul.



Cor

 

[Larry Smith]

I think you need to ask yourself what meets your standard of good. To

suggest only 5% of developers are good suggests to me there is some flaw in
the way you percieve people

No flaw. A simple evaluation of most people's code will quickly substantiate
my claim.

To me someone is good when they time and time again deliver software to
spec and software that is relatively maintenance free. I have seen many
people that can do this, and not all of them guru's if you want to put it
that way.

I disagree completely. A program isn't a success just because it seems to
handle most of its mainstream cases correctly. Often it has many latent
problems but that's beside the point. Look objectively at the code of most
people and ask yourself. Is the code cleanly written and well designed - not
likely. Is it easily extensible - not likely. Is it reusable - not likely.
Are there common (generic and application-specific) libraries that everyone
can contribute to and rely on - not likely. Are programmers repeating the
work of their peers because there's no emphasis on reusabilty - very likely.
Do programmers even care about reusability - not likely. Is there code bloat
because of these issues - very likely. Is there coherent and standardized
error checking that everyone is following - not likely. Are people
religiously checking for all errors and properly backing out when an error
does occur - not likely. Is the code well documented - not likely. Is the
program far more expensive to support than it otherwise would be because of
these and other issues - very likely.

Your claims that you've seen many people who can write code that is
relatively free from these problems is either a (very rare) aberration or
you're not assessing the situation honestly.

Lets put it this way what % of the .net framework do you need to know to
solve most day to day business problems. Companies got by for years on
software written using VB. What ever you say about VB it solved lots of
problems for businesses globally and they got by very well, now look at
the functionality the .NET framework gives us we could get by probably by
using 10-20% of that and solve most issues thrown at us.

The language or platform doesn't matter (VB or otherwise). Some are more
susceptible to problems like C++ but even most VB code I've seen suffers
from serious problems. In fact, I recently completed some work for a very
large and well-known Fortune 500 company with a huge VB program that's rife
with the problems I mentioned (fortunately I didn't work on it). Note that
..NET is not a panacea either. It's a matter of degree but it still has the
same issues as any other platform. Skilled programmers are still required.
Until a new simplfieid paradigm comes long to replace symbolic languages as
the means for programming computers then this will always be the case.

I'm starting to think your just trolling.

Why, because I disagree with you?

 

[Larry Smith]

I think you need to ask yourself what meets your standard of good. To

suggest only 5% of developers are good suggests to me there is some flaw in
the way you percieve people

No flaw. A simple evaluation of most people's code will quickly substantiate
my claim.

To me someone is good when they time and time again deliver software to
spec and software that is relatively maintenance free. I have seen many
people that can do this, and not all of them guru's if you want to put it
that way.

I disagree completely. A program isn't a success just because it seems to
handle most of its mainstream cases correctly. Often it has many latent
problems but that's beside the point. Look objectively at the code of most
people and ask yourself. Is the code cleanly written and well designed - not
likely. Is it easily extensible - not likely. Is it reusable - not likely.
Are there common (generic and application-specific) libraries that everyone
can contribute to and rely on - not likely. Are programmers repeating the
work of their peers because there's no emphasis on reusabilty - very likely.
Do programmers even care about reusability - not likely. Is there code bloat
because of these issues - very likely. Is there coherent and standardized
error checking that everyone is following - not likely. Are people
religiously checking for all errors and properly backing out when an error
does occur - not likely. Is the code well documented - not likely. Is the
program far more expensive to support than it otherwise would be because of
these and other issues - very likely.

Your claims that you've seen many people who can write code that is
relatively free from these problems is either a (very rare) aberration or
you're not assessing the situation honestly.

Lets put it this way what % of the .net framework do you need to know to
solve most day to day business problems. Companies got by for years on
software written using VB. What ever you say about VB it solved lots of
problems for businesses globally and they got by very well, now look at
the functionality the .NET framework gives us we could get by probably by
using 10-20% of that and solve most issues thrown at us.

The language or platform doesn't matter (VB or otherwise). Some are more
susceptible to problems like C++ but even most VB code I've seen suffers
from serious problems. In fact, I recently completed some work for a very
large and well-known Fortune 500 company with a huge VB program that's rife
with the problems I mentioned (fortunately I didn't work on it). Note that
..NET is not a panacea either. It's a matter of degree but it still has the
same issues as any other platform. Skilled programmers are still required.
Until a new simplfieid paradigm comes long to replace symbolic languages as
the means for programming computers then this will always be the case.

I'm starting to think your just trolling.

Why, because I disagree with you?

 

[Cor Ligthert[MVP]]

In fact, I recently completed some work for a very large and well-known

Fortune 500 company with a huge VB program that's rife with the problems

You know all those with well written Algol programs that don't exist
anymore.

You comes with statements like that a potato is for millennia the food of
humans.

However, forgets to tell that it was only in America.

Cor

 

[Cor Ligthert[MVP]]

In fact, I recently completed some work for a very large and well-known

Fortune 500 company with a huge VB program that's rife with the problems

You know all those with well written Algol programs that don't exist
anymore.

You comes with statements like that a potato is for millennia the food of
humans.

However, forgets to tell that it was only in America.

Cor

 

[Registered User]

It is very hard to find the right questions. The question I hate is
this: What is Object-Oriented Programming?

OOP is the implementation of an object-oriented design.

It is so generic. Even a lot of really good object oriented
programmers have a hard time defining it. I work with architectural
and design patterns all day and I still have a hard time defining it
in a single sentence. I want to hear about encapsulating data behind
functionality, design patterns, single responsibility, blah, blah,
blah. I usually don't get this.

I find these sort of topics to be more design-related than anything
else. Too often the design originates in the code rather than coding
to a design. Seat of the pants design places all the value in the code
rather than in the wetware and the various abstractions which can
produced before a line of code is ever written.

Learning is our job.

In a way we're jacks of all trades, in a good way I mean. We have to
be able to select the proper tools and technologies and learn how to
use them efficiently. We are fortunate that these things are more the
same than different so the learning curves can be rather shallow.
There are a great many transferable skills. When I first looked at WWF
I saw flowcharts from my Fortran IV days long ago.

One of the most important things I've learned is that when something
is hard to do, I'm probably doing something wrong.

Thanks. Nurturing is very important to me; it is the only reason I
have the job I do.

One of the most important skills a designer/programmer needs is the
ability to create their own types. Rather than ask what OOP/OOD is I
would ask potential candidates to abstractly design an invoice object
or something similar which has many real world models to draw from. I
would expect the initial thoughts to include some sort of collection
of invoice item objects along with a member pointing to a customer
object.

regards
A.G.

 

[Registered User]

It is very hard to find the right questions. The question I hate is
this: What is Object-Oriented Programming?

OOP is the implementation of an object-oriented design.

It is so generic. Even a lot of really good object oriented
programmers have a hard time defining it. I work with architectural
and design patterns all day and I still have a hard time defining it
in a single sentence. I want to hear about encapsulating data behind
functionality, design patterns, single responsibility, blah, blah,
blah. I usually don't get this.

I find these sort of topics to be more design-related than anything
else. Too often the design originates in the code rather than coding
to a design. Seat of the pants design places all the value in the code
rather than in the wetware and the various abstractions which can
produced before a line of code is ever written.

Learning is our job.

In a way we're jacks of all trades, in a good way I mean. We have to
be able to select the proper tools and technologies and learn how to
use them efficiently. We are fortunate that these things are more the
same than different so the learning curves can be rather shallow.
There are a great many transferable skills. When I first looked at WWF
I saw flowcharts from my Fortran IV days long ago.

One of the most important things I've learned is that when something
is hard to do, I'm probably doing something wrong.

Thanks. Nurturing is very important to me; it is the only reason I
have the job I do.

One of the most important skills a designer/programmer needs is the
ability to create their own types. Rather than ask what OOP/OOD is I
would ask potential candidates to abstractly design an invoice object
or something similar which has many real world models to draw from. I
would expect the initial thoughts to include some sort of collection
of invoice item objects along with a member pointing to a customer
object.

regards
A.G.

 

[Paul]

I disagree completely. A program isn't a success just because it seems to

handle most of its mainstream cases correctly. Often it has many latent
problems but that's beside the point.

But if its handling its use cases correctly thats what the software is for.
Software is not for developers to show off their skills and how clever they
are but to satisfy a business/customer need. Yes it can be made maintainable
and given the ability to react to business change but only where the person
holding the purse strings is willing to pay for that.

 

[Paul]

I disagree completely. A program isn't a success just because it seems to

handle most of its mainstream cases correctly. Often it has many latent
problems but that's beside the point.

But if its handling its use cases correctly thats what the software is for.
Software is not for developers to show off their skills and how clever they
are but to satisfy a business/customer need. Yes it can be made maintainable
and given the ability to react to business change but only where the person
holding the purse strings is willing to pay for that.

 

[Paul]

I hate to say it, but you are right in a sense. 50% of programmers are
not formally trained. How many of those simply haven't taken the time
to keep educated? You have to read, be part of forum discussions,
search on new techniques and technologies, etc.. Most people aren't
willing to do this and would rather spend their evenings playing WOW.

Again I disagree. Formal training is overrated. Some of the worst offenders
are those that have their MCP/MCTS. Like the MCTS I knew who decided it was
fun to create an application and re-write the configuration stuff because he
thought the standard configuration file functionality in .net was messy.
Anyway it was a complete mess, I even flagged it with his team leader who
was a muppet and ignored me (I was on a different team). Proof that crap
floats guy is now director of IT somewhere mind you can prolly do less
damage there. All developers have rushes of blood and you are no doubt the
same taking into account your bridge pattern. BTW we have all done that, and
yes it is an improvement to those that can follow the patterns, and those
that don't call it crap unmanagable code, trust me trying to force
startegies, factories, proxy's and facades down developers throats takes
time, but they soon see how they can actually finish development projects
without having to totally restart when those pesky analysts come back with
changed requirements. Business tends to move faster than development
unfortunately. Much prefer to spend my time on the X-Box, or out shopping
with the wife. Or maybe not. ;-)

 

[Paul]

I hate to say it, but you are right in a sense. 50% of programmers are
not formally trained. How many of those simply haven't taken the time
to keep educated? You have to read, be part of forum discussions,
search on new techniques and technologies, etc.. Most people aren't
willing to do this and would rather spend their evenings playing WOW.

Again I disagree. Formal training is overrated. Some of the worst offenders
are those that have their MCP/MCTS. Like the MCTS I knew who decided it was
fun to create an application and re-write the configuration stuff because he
thought the standard configuration file functionality in .net was messy.
Anyway it was a complete mess, I even flagged it with his team leader who
was a muppet and ignored me (I was on a different team). Proof that crap
floats guy is now director of IT somewhere mind you can prolly do less
damage there. All developers have rushes of blood and you are no doubt the
same taking into account your bridge pattern. BTW we have all done that, and
yes it is an improvement to those that can follow the patterns, and those
that don't call it crap unmanagable code, trust me trying to force
startegies, factories, proxy's and facades down developers throats takes
time, but they soon see how they can actually finish development projects
without having to totally restart when those pesky analysts come back with
changed requirements. Business tends to move faster than development
unfortunately. Much prefer to spend my time on the X-Box, or out shopping
with the wife. Or maybe not. ;-)

 

[Paul]

Don't take this the wrong way but it sounds simple. I'm sure its not tho.

Considering you are having problems it would be advisable to design the app
to the n'th degree, this way anyone coming in especially a code monkey can
just follow design and you then have a something to check their progress
against.

I would also start designing and implementing common components early and
consider putting these in GAC so the other developers cannot change these
items but develop around them.

This way you should get a head start before your requirements are fully
realised. basically follow the Agile method in Larman but be more flexible.
Core supporting functionality can be created early or even poached from
other projects, re-use is king.

I have a library for Data Startegy, Custom Permission objects for CAS, MSMQ
Provider, Error Handling Startegy, Logging Strategy to name but a few. These
only change where a new project requires slightly different functionality
but then as they are strategies I can creat a new concrete strategy based
around an abstract class and still not affect other projects with the
changes made for the new project, the apps are so specific that it is rare
if ever that the interface would change, whereas apps that do everything are
more likely to have interface chnages which becomes a problem.

Looking at your design it is also obvious there is potential for your
calculation engine to change so you may want to look at the
strategy/composite patterns for this with the ablility to add new
calculations in the future, but Im sure you have all this in hand.

Sometimes it is easy for people to get bogged down in semantics,e.g thats
not a factory its an abstract factory etc etc. Does this really matter?
Nope. Has it added value? YES. Thats what matters.

Why not mix your questions up. Techie questions are ok but you also need
to
be shown that someone can apply that knowledge. Why not create scenario's
in
which applying the system.collections namespace is required. Now there are
always more than one way to skin a cat, so get their solutions and ask
them
to explain it to you. You may find they have found issues in the scenario
even you did not consider.

The problem is that we hire through a contractor, to do the filtering.
Most of our conversations take place over the phone. It is really hard
to know whether you should even both with an in-person interview. We
are pretty remote and very busy, so flying people in and taking a day
to test them needs to be done with caution.

IMHO you can always teach people .net or patterns by laying the
foundations
for them and nurturing them, in fact how many of us have the time to learn
all the new Framework additions. What you cannot do is impart business
acumen, IMHO design is a Lead Developers role and not a junior/developer
role and there should always be a lead developer with these skills in a
team.

Our system is currently preparring to enter a new phase. Currently, it
only serves one region and there are only 10-12 users who input all
the data, which is generated by other large groups. It will soon be
serving the entire company, serving closer to a hundred users. There
are also some new business rules coming down the line changing how we
charge our customers, which will require a new calculation engine.

With all the extra work just a few months away, we really don't have
time to teach someone good programming practices along with the
business and .NET. I've be here for 3 years and I still don't have all
of the process figured out, let alone the business. My lead developer
has a much better grasp than I do, but he's not a hard-core programmer
either. We need support - good support.

 

[Paul]

Don't take this the wrong way but it sounds simple. I'm sure its not tho.

Considering you are having problems it would be advisable to design the app
to the n'th degree, this way anyone coming in especially a code monkey can
just follow design and you then have a something to check their progress
against.

I would also start designing and implementing common components early and
consider putting these in GAC so the other developers cannot change these
items but develop around them.

This way you should get a head start before your requirements are fully
realised. basically follow the Agile method in Larman but be more flexible.
Core supporting functionality can be created early or even poached from
other projects, re-use is king.

I have a library for Data Startegy, Custom Permission objects for CAS, MSMQ
Provider, Error Handling Startegy, Logging Strategy to name but a few. These
only change where a new project requires slightly different functionality
but then as they are strategies I can creat a new concrete strategy based
around an abstract class and still not affect other projects with the
changes made for the new project, the apps are so specific that it is rare
if ever that the interface would change, whereas apps that do everything are
more likely to have interface chnages which becomes a problem.

Looking at your design it is also obvious there is potential for your
calculation engine to change so you may want to look at the
strategy/composite patterns for this with the ablility to add new
calculations in the future, but Im sure you have all this in hand.

Sometimes it is easy for people to get bogged down in semantics,e.g thats
not a factory its an abstract factory etc etc. Does this really matter?
Nope. Has it added value? YES. Thats what matters.

Why not mix your questions up. Techie questions are ok but you also need
to
be shown that someone can apply that knowledge. Why not create scenario's
in
which applying the system.collections namespace is required. Now there are
always more than one way to skin a cat, so get their solutions and ask
them
to explain it to you. You may find they have found issues in the scenario
even you did not consider.

The problem is that we hire through a contractor, to do the filtering.
Most of our conversations take place over the phone. It is really hard
to know whether you should even both with an in-person interview. We
are pretty remote and very busy, so flying people in and taking a day
to test them needs to be done with caution.

IMHO you can always teach people .net or patterns by laying the
foundations
for them and nurturing them, in fact how many of us have the time to learn
all the new Framework additions. What you cannot do is impart business
acumen, IMHO design is a Lead Developers role and not a junior/developer
role and there should always be a lead developer with these skills in a
team.

Our system is currently preparring to enter a new phase. Currently, it
only serves one region and there are only 10-12 users who input all
the data, which is generated by other large groups. It will soon be
serving the entire company, serving closer to a hundred users. There
are also some new business rules coming down the line changing how we
charge our customers, which will require a new calculation engine.

With all the extra work just a few months away, we really don't have
time to teach someone good programming practices along with the
business and .NET. I've be here for 3 years and I still don't have all
of the process figured out, let alone the business. My lead developer
has a much better grasp than I do, but he's not a hard-core programmer
either. We need support - good support.

 

[jehugaleahsa]

Again I disagree. Formal training is overrated. Some of the worst offenders
are those that have their MCP/MCTS. Like the MCTS I knew who decided it was
fun to create an application and re-write the configuration stuff becausehe
thought the standard configuration file functionality in .net was messy.
Anyway it was a complete mess, I even flagged it with his team leader who
was a muppet and ignored me (I was on a different team). Proof that crap
floats guy is now director of  IT somewhere mind you can prolly do less
damage there. All developers have rushes of blood and you are no doubt the
same taking into account your bridge pattern. BTW we have all done that, and
yes it is an improvement to those that can follow the patterns, and those
that don't call it crap unmanagable code, trust me trying to force
startegies, factories, proxy's and facades down developers throats takes
time, but they soon see how they can actually finish development projects
without having to totally restart when those pesky analysts come back with
changed requirements. Business tends to move faster than development
unfortunately. Much prefer to spend my time on the X-Box, or out shopping
with the wife. Or maybe not. ;-)

You have to make time for life as well. We unfortunately live in a
profession where it is easy to fall behind. I work in shop where I get
to work on the same platform day in and day out (2.0). If I don't take
the time to learn about C# 3.0, I will never learn it. That goes even
more for non-MS platforms. My grump wasn't against people who refuse
to keep up (although it is a problem). My problem is that there are a
lot of IT folks out there who try to get a job as a .NET programmer
when their main emphasis has been in Python or Perl. Sure, these are
great programming languages, but C# has its own paradigms, etc. that
someone coming in without a background isn't going to know. I know a
lot of really great .NET programmers who aren't familiar with
Nullables. I use Nullables every day! The point is that I've been
programming in .NET for 3+ years, coming from a C++ background, and it
took me over a year to shed my old-school coding practices with more
object-oriented ones. Look at all the C++ programmers who try to
implement the STL in C#!

When I was job hunting, I was constantly frustrated by how many jobs
out there called for a .NET developer ("Hey, that's me!") but when I
went into the details they wanted a VB .NET programmer. I know I don't
know how to program in VB, and honestly I'd prefer not to (I like
statically typed languages). I usually just overlooked these.
Honestly, I am skeptical whether I'd be willing to work in C++
anymore... and I used to be a wiz.

And you're absolutely right about most people not wanting to learn
design patterns. I don't think it is beyond people. I just don't think
some people are comfortable with the level of abstraction that they
provide. Most programmers simply aren't comfortable with polymorphism,
which pretty much _every_ design pattern hinges on. But frankly, large
scale applications can't and shouldn't be written without them. Small
web forms, what have you, are really the only thing that can run
without them. But I've found that even most small applications can
benefit from a few architectural or design patterns.

Finally, I don't think most C# training courses are worth the money
people are paying for them. I find that you can get more out of
reading one of O'Reilly's nutshell books than you will from sitting in
a classroom. Some people need that hands-on training. Personally, I
can sit down and read a chapter a day and be further along in a month
than I think I would be from watching some webinar. As an example, my
coworker took some training at MS using some support hours we had. The
test he took at the end was a piece of cake, but all the training he
took didn't prepare him for them at all. As far as I'm concerned, the
certificate isn't worth the money I'd pay for it. I can prove to
someone in 5 minutes over the phone that I know more than some piece
of paper can show.

 

[jehugaleahsa]

Again I disagree. Formal training is overrated. Some of the worst offenders
are those that have their MCP/MCTS. Like the MCTS I knew who decided it was
fun to create an application and re-write the configuration stuff becausehe
thought the standard configuration file functionality in .net was messy.
Anyway it was a complete mess, I even flagged it with his team leader who
was a muppet and ignored me (I was on a different team). Proof that crap
floats guy is now director of  IT somewhere mind you can prolly do less
damage there. All developers have rushes of blood and you are no doubt the
same taking into account your bridge pattern. BTW we have all done that, and
yes it is an improvement to those that can follow the patterns, and those
that don't call it crap unmanagable code, trust me trying to force
startegies, factories, proxy's and facades down developers throats takes
time, but they soon see how they can actually finish development projects
without having to totally restart when those pesky analysts come back with
changed requirements. Business tends to move faster than development
unfortunately. Much prefer to spend my time on the X-Box, or out shopping
with the wife. Or maybe not. ;-)

You have to make time for life as well. We unfortunately live in a
profession where it is easy to fall behind. I work in shop where I get
to work on the same platform day in and day out (2.0). If I don't take
the time to learn about C# 3.0, I will never learn it. That goes even
more for non-MS platforms. My grump wasn't against people who refuse
to keep up (although it is a problem). My problem is that there are a
lot of IT folks out there who try to get a job as a .NET programmer
when their main emphasis has been in Python or Perl. Sure, these are
great programming languages, but C# has its own paradigms, etc. that
someone coming in without a background isn't going to know. I know a
lot of really great .NET programmers who aren't familiar with
Nullables. I use Nullables every day! The point is that I've been
programming in .NET for 3+ years, coming from a C++ background, and it
took me over a year to shed my old-school coding practices with more
object-oriented ones. Look at all the C++ programmers who try to
implement the STL in C#!

When I was job hunting, I was constantly frustrated by how many jobs
out there called for a .NET developer ("Hey, that's me!") but when I
went into the details they wanted a VB .NET programmer. I know I don't
know how to program in VB, and honestly I'd prefer not to (I like
statically typed languages). I usually just overlooked these.
Honestly, I am skeptical whether I'd be willing to work in C++
anymore... and I used to be a wiz.

And you're absolutely right about most people not wanting to learn
design patterns. I don't think it is beyond people. I just don't think
some people are comfortable with the level of abstraction that they
provide. Most programmers simply aren't comfortable with polymorphism,
which pretty much _every_ design pattern hinges on. But frankly, large
scale applications can't and shouldn't be written without them. Small
web forms, what have you, are really the only thing that can run
without them. But I've found that even most small applications can
benefit from a few architectural or design patterns.

Finally, I don't think most C# training courses are worth the money
people are paying for them. I find that you can get more out of
reading one of O'Reilly's nutshell books than you will from sitting in
a classroom. Some people need that hands-on training. Personally, I
can sit down and read a chapter a day and be further along in a month
than I think I would be from watching some webinar. As an example, my
coworker took some training at MS using some support hours we had. The
test he took at the end was a piece of cake, but all the training he
took didn't prepare him for them at all. As far as I'm concerned, the
certificate isn't worth the money I'd pay for it. I can prove to
someone in 5 minutes over the phone that I know more than some piece
of paper can show.

 

[jehugaleahsa]

Don't take this the wrong way but it sounds simple. I'm sure its not tho.

Considering you are having problems it would be advisable to design the app
to the n'th degree, this way anyone coming in especially a code monkey can
just follow design and you then have a something to check their progress
against.

"Plan to throw one away." -- Frederick Brooks. We recently upgraded
the application from C/C++ to C#. The first time we rewrote the code,
it was very nasty C#. I'm talking, redundant SQL, SQL in the code-
behind, DataTables getting used all over the place, resource leaks,
bad UI binding and bugs everywhere. I got tired of living in the
garbage, so I started burrowing my way out. Within the past 3 months,
I have formalize and standardized, refactored and applied design
patterns, etc.

There is practically a document for how to write anything, and its
usually a small document. The problem is really whether that person
will be able to see the system as a whole. If they can see the pieces
of the architecture, they should have no problem keeping the
complexity low. Design patterns aren't as common as architectural
patterns. I mean, we have some code that generates reports using a
builder/iterator/composite pattern and a state pattern for tracking
the state of our data objects, but nothing super complex. Probably the
most complex pattern we use is bridge to work with Crystal Reports.

For instance, my lead developer isn't too keen on modern code design.
The system relies a lot of dependency injection and strategies. When
he is trying to find some code, he gets frustrated because "Go to
Definition" takes him to the interface definition. "I just want to see
the code," he complains.

I would also start designing and implementing common components early and
consider putting these in GAC so the other developers cannot change these
items but develop around them.

Here is the problem I ran into with that. According to Bob Martin's
book, you should try to break up your DLLs such that code that changes
together appear in the same DLL (The Common Closure Principle) and
classes that are used together should be packaged together (Common
Reuse Principle). This means that you should be able to break you code
up into DLLs such that the code inside either form a working unit -or-
that the classes inside the DLL are unlikely to change but are reused
by various other classes in other DLLs.

We have an ICustomer interface that is used by just about every
subsystem. We also use a bunch of other classes, all with their
varying appearances across the subsystems. Then there are some that
only appear here or there. It would be nice to to follow the packaging
principles here, but it would result in an explosion of DLLs. Instead
we have DLLs broken out like this:

Interfaces - This holds the interfaces for the data objects in the
system. It also has code for enumerations, converters, etc.
DataObjects - This holds implementations for the interfaces.
Commands - This holds SQL wrapped in command objects.
Factories - This hold facades that indirectly call on the commands,
allow for sorting, etc.
SubSystem - This is the DLL for a particular sub-system. It is
independent of the input and output.
Application - This calls the subsystem DLL and presents it to the user
or whatever.

With all the tables in the system, the interfaces DLL gets new code
all the time. Since it is at the bottom of the DLL dependency tree,
this forces almost every DLL above it to be recompiled. Eventually,
we'll have all of the interfaces implemented and these changes will
come less often. Which calls on the DataObjects DLL, whose sole
purpose is to provide implementations for the interfaces. Early
investigation into the future needs of the system revealed the need
for separating the data objects from their interfaces. Who knows at
this point?

We do use the GAC, but at this point the DLLs change too often. We are
also a very small shop, so whoever comes in is going to need to work
at all levels of the system. Especially for our new code.

This way you should get a head start before your requirements are fully
realised. basically follow the Agile method in Larman but be more flexible.
Core supporting functionality can be created early or even poached from
other projects, re-use is king.

I agree. Reuse has been the cornerstone of the newest edition of the
system. It might have some performance problems associated with it,
but they are negligible. The reuse has also been the catalyst that
allowed me to standardize so much of the system.

I have a library for Data Startegy, Custom Permission objects for CAS, MSMQ
Provider, Error Handling Startegy, Logging Strategy to name but a few. These
only change where a new project requires slightly different functionality
but then as they are strategies I can creat a new concrete strategy based
around an abstract class and still not affect other projects with the
changes made for the new project, the apps are so specific that it is rare
if ever that the interface would change, whereas apps that do everything are
more likely to have interface chnages which becomes a problem.

I have done this in the past. It takes about 3 tries to find a set of
classes that are resistant to change. I have a bunch of reusable code
sets, too. I think every veteran programmer has a collection of
snippets or libraries. However, in the project, everything has to be
written from scratch. We only write code we need, to prevent code
bloat. We also document and test every line of code that is
implemented. It is really hard to take a piece of code you wrote for a
small web application and make it enterprise ready. I did have some
success doing so on some smaller features, such as a COM library I
wrote for integrating with Novell's GroupWise (email) client. I
experienced the opposite effect with Crystal Reports.

We have a fairly agile approach at my work place, which is pretty
impressive considering it's the gov't. We tend to evolve our code more
often than doing a lot of up-front analysis. We write the code so that
it is easy to refactor later on and we always make the first version
easy to throw away if it totally doesn't work. On the opposite end, we
have a very hard time getting users to test, so our iterations are
short, but not nailed down until a few weeks go by and our users find
issues. We have gotten pretty good at testing in production (yuck) and
working on new requirements at the same time. Fortunately, we have an
awesome automated test setup so most issues are UI-related.

Looking at your design it is also obvious there is potential for your
calculation engine to change so you may want to look at the
strategy/composite patterns for this with the ablility to add new
calculations in the future, but Im sure you have all this in hand.

Our calculation engine is a monster. Essentially, it works like a
batch calculator working on the lines in a report. Each of the lines
holds values that are then added, subtracted, divided or multiplied by
another line's values. Most of the code is the same based on a few
fields from each line, so we have an ILine interface. Then, there is
an abstract Calculator class that takes a list of TLines and then uses
template method to do line-specific operations. Nothing like mixing
template method with generics! There is a calculator for every level
in the calculation. All of the calculation engines rely on the same
Calculator class; they just use it differently (template method).

I've found that the calculation engine isn't something you can explain
in five minutes. There about 12 distinct operations (even two versions
of multiplication). I attribute this to the poor design of the
original system. There is no good reason why the code has to
distinguish between floating point numbers and integers, especially
when a "places" field is provided to specify rounding.

Sometimes it is easy for people to get bogged down in semantics,e.g  thats
not a factory its an abstract factory  etc etc. Does this really matter?
Nope. Has it added value? YES. Thats what matters.

Absolutely. One thing we're careful not ask for is the name of a
design pattern. We might ask, "What are some design patterns you have
worked with? Give us an example." They some times refer to
architectural patterns, but that's all right. There are about 10
different names for the Observer pattern (events, Listener, etc.). By
having the question we are expecting the programmers we interview to
have some experience with them. It's hard these days to program even
medium-sized projects without running into a couple of them. I don't
think we're eliminating any deserving candidates that way. IMHO.

If the system weren't so large, I wouldn't be so concerned. Our my
coworker (who recently left) came in with a business degree and "kind
of" picked up programming. He was pretty good by the time he left. His
deal was that he didn't want to get into the code, but concentrated
more on the UI. Our system doesn't revolve around the UI and his
resistance resulted in him rushing through the code. He could have
asked me for some guidance but he didn't like to ask questions. It
took him months to implement things that were scheduled to only take a
few days.

Whoever comes into this system really needs to be willing to dedicate
all of their coding skills to it. They have to know how to code! Our
system doesn't require much in the way of complex algorithms, they
when to use what. They need to understand the system and the code that
makes it all work.

Thanks for you input!