Attention: We are retiring the ASP.NET Community Blogs. Learn more >

PDC 2008 here I come and btw, can we teach old developers to sit?

I will attend the PDC 2008 this year, only two weeks left.. I hope see as many of you as possible at the conference.

Until PDC I will try to figure out a good way "how to teach old programmers to (sit) use OOP", there are too many developers that still uses method with hundreds lines of code, no encapsulation, they repeat them self, have huge condition statements etc, they are more function oriented  (uses functions only in classes and use them as they all was helper methods) than object oriented. Some developers don't even try or want to understand OOP, they love a method with hundreds of like of code and large condition statements etc, they are used to it because when they started as a developer there was no OO support in the language they used, so can we teach those old "stubborn" people to use OOP? What do you think, should we just give up and let them be and focus on developer that want to know if there are different ways to write code?

7 Comments

  • One major function code is where the regions come in handy :)

    public static void THEFunction(Object[] theInStuff)
    {
    #region "the first part - parse the objects"
    #end region

    #region "the second part - do the Stuff"
    #end region

    }

  • The functional programing will always have its fans. We still even see some trends for functional programing even from Microsoft. We have F# and there is a trend to have some handy functional styles in C#. Dynamic Languages is more functional-like languages so in most of the cases OOP is not the choice of these languages developers. I like OOP and I really get nervous when seeing functional style code but still programmers like to do what they are comfortable with and it seems that many developers especially dynamic languages ones like this style and it seems more comfortable for them to do it like that.


  • @Mohammed Nour:
    Yes, I agree.. but something I notice is that people still write code that is impossible to understand because they use only functions with hundred of lines of code mixed with condition statements. It's almost impossible to maintain and read. By using refactoring and OOP, we can reuse code, make it more readable and easy to maintain.. but that part is hard for some people to understand. They think it IS complicated and doesn't even want to try to understand or make the code easier to read. Maybe because they are afraid of changes, or stuck to bad habits. Can it be lack of logical thinking? Hmm, I don’t know… But it so sad to see code that is so bad written that even the one that wrote don’t understand it, I don’t say that OOP will make it better, but we can easier reuse code etc.

  • Since I´m working as a consultant, I have to work with many different projects at different organizations, and they have one thing in common.. The ugly code! No refactoring, no OOP etc.

    I guess it´s because they just don´t know how to do it. I have spoken to some other developers and asked them why they write the code that way, and the answer is almost always "because that´s the easiest way". Is it really the easiest way? What if they have to use the function again?

    I have seen web forms where the Page_Load method can be several hundreds of lines and where all the logic is in the code behind files, and that´s just the beginning..

    It´s hard to be a developer these days.

  • Regarding your comments on functional programming, Mohammad Nour, I have to say we need to differentiate between using functions or procedures of several hundreds of lines' length, as opposed to functional programming, as F#, Scheme, Lisp, and ML represent. These are two different beasts alltogether.

    When Fredrik N. speaks about functions in his original blog posts, I don't suppose he's talking about functional programming per se, but functions as in methods, procedures, operations, with hundreds of lines of code, as opposed to using classes, inheritance and polymorphism to differentiate in behavior between different kinds of objects.

    Other than this, I agree with Fredrik on the problem of teaching old dogs new tricks... We have a couple where I work as a consultant as well. On first read, a long method with lots of if-else-s can seem easy to read, however, when maintaining the same code years after, and trying to make it do something a little different (due to change in business loging, e.g.), it's a nightmare to maintain, opposed to cleanly written OO-code.

    Just my $.03 (thought they were worth a bit more than $.02)

  • Funny, I'm 55 and I have the same problem with many young, and not so young, developers.

    I'm talking a lot about the importance of high quality and efficiency in software development and that we today have a lot of methods and tools to accomplish this, which includes agile and object oriented principles, patterns, DDD, TDD, IoC, ORM, Continuous Integration, automatic testing, and so on.

    My experience though is that for many professional developers, young and old, these are still more or less unknown principles.

    Maybe it's not correlated to age? I don't think so, I think it's a matter of lacking knowledge and experience.


  • @Jan Stenberg:
    The word Old in my context is kind of wrong.. it shouldn't be old people like people over 45 of age etc. More like developers that have over 10 years of programming experience and stuck in old habits.
    It's not about the age, it is probably lack of knowledge and experience, but that is not the whole truth.. Some people are good at mathematic, and some aren't, some people need more help than others.. We all have brains, even though, some people understand directly, and some need more examples, more studies before they understand.. Some people are good at painting, some aren't, even if we are humans.

Comments have been disabled for this content.