[Help] How to wake up a bunch of dinosaurs ?



  •  Hello folks.

    First, let me introduce myself (quickly):

    I've been a developer for 5 years.
    I coded some winforms/webapps/console apps in VB6, then a lot web applications in Java and now I'm just using .NET (mostly C#).
    I'm NOT a "powercoder".I'm... let's say, probably slightly below average in terms of code quality, but I'm curious.

    The situation:


    I now work for a small company (the IT dept. is about 12 persons) wich holds several r.e.n.t.a.l websites (its SEO politic is so badly implemented, I don't want this post to show up before our main website as a result of a Google query).
    After a year of coding new "modules" and handling some maintenance tasks, I'm asked to be "Mister Quality" for the entire IT dept.
    In fact, during my first annual review (I'm here since June 2007) I said the code is a little bit... perfectible .
    After looking together (with the CIO) at a bunch of code lines, he agreed someone should try to restore peace in this chaotic mass of... hmmm... things ?

    But:

    • The company hired ".NET gurus" some months ago.

    They came with neat stuff like SVN, CruiseControl, NUnit... but they leave before theses concepts reach the brain of our older developers.
    So right now, everybody agrees that these are wonderful tools but no one really use them (except SVN, but in a poorly way).

    • this company is a real WTF factory (an happy mix of vbs scripts, ASP & ASP.net web pages, .net backoffice, trying to interact each other without any log...)
    • Our CIO is schizophrenic (he wants more "quality" but still commits 30 uncommented source files into our SVN repo, breaking the build before leaving for the week end)
    • Developers are getting older (35+) and don't really want to change their habits. In fact, most of them LIKE to maintain a buggy application.


    My question :

    I must help people using fxCop, TestDriven, log4net and Tortoise SVN, code re-use and so on...

    They f*cking don't care about quality and prefers coding the old way, quick & dirty, reinventing the (square) wheel for every new project.


    They say it's easier for them to add/remove 10 lines of code everyday on the same application in order to fix some random bugs than thinking of the big picture of a problem a coding
    a solid solution once and for all (well, at least, until the client change it's mind).

    So : what should I say to motive old dinosaurs to step into the 3rd millenium, and stop coding like a bunch of anarchic and almost blind code monkeys ?

    Please, any help/answer would be really, really appreciated...

    Thanks.

     



  • I think the most important task is that you dont "overload" them.

     

    - Only try to enlighten them 1 step at a time!

    - Dont force unit tests on them by forcing to write tests for a legacy application If you want them to start using unit tests, then let them use them on a NEW project. Writing tests for legacy code is hard as hell... So dont start with "hard as hell" 

    - Implement the continious build server

    - Dont work with "negative feedback". Try to showcase good work.

    - Try to implement pair programming (hard to do...). Switch the pairs often. Try to "inject" a solid style when you work with them.

    - Get them to read (also hard to do ;) )

     



  • Thank you for your answers, rdrunner.

    They all sound good and... logical !

    I didn't think about pair programming as a solution. That's an incredible idea.

    I don't think the pairs will switch so easily, but it might be a good start.



  •  35+ = dinosaur? Oh, thanks. (I'm 38)

    Anyway, forget it. Simply forget it. The mess you are in is, in some respect, a local maximum. No time and energy is wasted on quality, so all available resources go into "productive" work, as bad as it may be. Little steps to more quality will not improve anything, in fact, they will just leave the local maximum, see that e.g. unit tests don't help them in their way of programming (because a unit test requires a testable unit) and they will soon abandon whatever you tried to introduce to them. You would really need a big bang architectural change, a new start from zero, to get that done. But in your position, you simply won't be able to do that.

    The best you can do is find a few among them who share your ideas, form a team with them that makes good software. If it works out the way you expect, those other projects might in the long run fade away, and some of the dinosaurs with them. It will take many years, but if you succeed, the remains of those projects will be called legacy.

    P.S. Always remember that quality is ultimately defined by the client. Don't be too strict with "good practices" if the clients want something different. "I can't implement that feature, it's procedural, not object oriented" is nothing a client ever wants to hear. But of course all clients (yes all of them) want reliable products. Therefore, quality, as perceived from within, is a seller in the long run.



  • sounds like yall need some coding standards there... And the pairs could work on their own sections and then do code reviews on completion.



  • Well they are using SVN, so hook it up to a mailinglist system so you can easily track code going into it. Then bitch slap anyone who commits bad code.

    Alternatively, you can write a svn pre-commit hook script that checks for simple things and redjects them when they fail.

    I'm not sure about ths one, but i think its also possible to do a hook that will run all the unit tests you ahve and if anything fails will revert/reject the last commit.

     

    It's evil and will probebly make them ditch SVN, but at least you tried :)



  • @stratos said:

    Then bitch slap anyone who commits bad code.
     

    Code reviews are nice, but you have to do them right. i.e.

    - Focus on good code, not just bad code. This will go a long way to show people nice ways of handling problems.

    - Absolutely no personal attacks (very easy to get into that)

    - To avoid the above, the author of the code can't comment on it (there should be no need to defend anything)

    - No managers present. (As they may interpret problems discussed with a code with poor performance of the employee.)

    http://en.wikipedia.org/wiki/Code_review

     



  • @ammoQ said:

     35+ = dinosaur? Oh, thanks. (I'm 38)

     

     Well thank you for your answers and your intersting point of view..

    My bad, I misused the word "dinosaurs".

    I only mean they enjoy old fashion coding style and seems too heavy to move to something else.

    Even if I'm "only" 30 y.o., I don't think 35 is old enough to have seen the dawn of civilization.



  • @Darth Developer said:



    I only mean they enjoy old fashion coding style and seems too heavy to move to something else.

     

    No, that's not "old fashion". By all chances, it was already "bad style" when they started their career. Remember that e.g. the OO concept is about 20 years old!



  • @ammoQ said:

    No, that's not "old fashion". By all chances, it was already "bad style" when they started their career. Remember that e.g. the OO concept is about 20 years old!

     

    AFAIK the first version of Smalltalk came out in 1971, so it's more like 35 years.

    I don't think the situation is quite as hopeless as you say. It is certainly possible to introduce unit tests without having code designed as testable units. Look for frequently recurring problems and see if you can develop tests for those. Ideally, do some minimal smoke testing on the entire application that will reveal show-stopper bugs that keep the app from starting up. When people see that these minimal tests can save them work and embarassment, then at least some of them will see the potential and be willing to invest effort.

    But the crucial thing is management support. If management only pays lip service to the quality goals but doesn't really want to change anything or invest any developer time, your efforts are indeed doomed.



  • @brazzy said:

    AFAIK the first version of Smalltalk came out in 1971, so it's more like 35 years.
     

    According to wikipedia, the first publicy available version was Smalltalk-80.



  • @ammoQ said:

    @brazzy said:

    AFAIK the first version of Smalltalk came out in 1971, so it's more like 35 years.
     

    According to wikipedia, the first publicy available version was Smalltalk-80.

     

    Which probably explains why the OO concept is still far from ubiquitous - something that took 9 years to be considered publically releasable can't be expected to be picked up by the whole world in just 1 or 2 decades, now can it? 



  • @ammoQ said:

    @brazzy said:

    AFAIK the first version of Smalltalk came out in 1971, so it's more like 35 years.
     

    According to wikipedia, the first publicy available version was Smalltalk-80.

    Fine, how about Simula in 1967?



  •  @bstorer said:

    Fine, how about Simula in 1967?

    Hmm.. correct. The concepts are twice as old than what I said.


Log in to reply