Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Let's say we have a winform application with a buttonclick event. The buttonclick handles everything from the UI configuration to the database call and data manipulation. So you end up with a method that is 100's of lines of code long. Outside the fact that this code can't be considered test-able for various reasons, this style of programming is fragile to change.

I can talk bout OO, Anti-patterns, etc. The problem is that any distinct topic I can dream up requires a great deal of explanation to understand the potential benefits.

Outside of finding a new job (lots of businesses program this way), how can I teach these kinds of developers how to write better code? Obviously we can't sit around a round table and discuss pro's and con's all day due to time constraints and real work that has to be done. Although, training and intense training is the only thing I can think of to fix these problems.

Not to say I write perfect code, I most certainly do not. I do believe there are certain best practices that should be followed as a rule E.G. OO in the context of .NET.

The most common excuse I hear is "we can't write code fast enough if we do it like that".

share|improve this question
1  
1  
1  
1  
3  
People write clean, readable, efficient and abstract code in a procedural paradigm just fine. Choice of programming paradigm has nothing to do with it. –  tdammers Apr 4 '12 at 18:43

3 Answers 3

up vote 3 down vote accepted

Find a suitable paradigm like Model-View-Controller, and discuss it specifically.

I think you will find that your developers will immediately see the benefits of following a pre-defined architectural standard. You will also be talking about something concrete, rather than pie-in-the-sky abstract concepts.

ASP.NET MVC has complete code walkthroughs in their NerdDinner sample project.

share|improve this answer
    
Actually, that is what I have been doing. The problem I'm running across is that we do winform dev, zero web. I'm familiar with MVC and have written apps using MVC3. Unfortunetly, I know of no direct transfer to offer the team. MVVM I believe is close. Do you have any code walkthrough's, demo's etc for this? I subscribe to Pluralsight, but once again their MVVM demo is tailored for web. Anything similar that works in the WinForm world (preferably with a project type OOB) that also has training available is what I require. –  P.Brian.Mackey Apr 4 '12 at 20:05
1  
See stackoverflow.com/questions/595469/…. Winforms requires more discipline than many other software environments, because it's very easy to write a big ball of mud in it. Then all the time you saved hacking together "quick" code easily gets eaten up in productivity losses. –  Robert Harvey Apr 4 '12 at 20:13

This is going to require a time investment. If people are committed to practices like "duct-tape programming", avoiding unit tests, writing static-procedural code in an OO language, etc, speeches about decoupling and test seams are not going to sway them. Speeches about anything probably won't sway them.

Keep to yourself, and do things your way, and then explain your methodology when the inevitable questions start to come your way such as "why are you able to absorb changes so much better than the rest of us?" or "why are your defect counts lower than the rest of us?" At this point, you'll have someone's ear - either developers if they're genuinely engaged but skeptical of your ideas or managers if the developers are checked out.

To put it more succinctly: talk is cheap, but results aren't. Get the results and you'll be asked to talk. :)

share|improve this answer

One way you get junior developers to learn a paradigm is by not letting them touch the architecture. You design the architecture and then spell out the portions of code that they will write. Make sure they participate with all of the other developers and see how everything fits together as they write the code. Each week do a code review, and slap wrists for breaking the pattern and so on... This is a great way to learn, and they learn it by doing.

Over time, they will learn the way of thinking necessary to design things themselves.

Another way is to give them projects to do where the only way to solve the problem is to use a certain pattern. As they stumble through it, they will discover the pattern and/or see its wisdom and use.

I have tried sitting people down and explaining architecture to them, and it just flies over their head. Give them a project to do using it, and they catch on much easier.

IMHO, the best book for designing still is http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=cm_cr_pr_product_top. However, it is a book for a person who is already trying to write good code. To teach, you design, let them implement. Then over time, include your good programmers a little more in the design process.

Also,

"we can't write code fast enough if we do it like that".

is the dumbest excuse for poor work. Kindly explain to the offender that it takes exponentially more time to debug and maintain a poorly written program than it does to just write it correctly to begin with. A person who says such a thing has obviously never had to see a piece of code through from development to production to revision ad infinitum.

share|improve this answer
    
Can you give me an example or reference of a problem that requires use of a certain pattern? –  P.Brian.Mackey Apr 4 '12 at 19:20
    
@P.Brian.Mackey Yes, to teach a developer the observer pattern, I had them write a component that sent log.write() calls across the network to clients who were registered to observe the server. The client would be another class which was listening for those incoming log messages which then had to notify the user of the class via a callback. –  Jonathan Henson Apr 4 '12 at 19:25
    
@P.Brian.Mackey You can come up with all sorts of useful components that you can give people to write where if you spec the project right, they will be forced to use the pattern or it will not be possible. –  Jonathan Henson Apr 4 '12 at 19:26
    
I see what you are saying. I agree that design patterns are a good tool in the shed. I can't say that learning 1-2 patterns is going to be enough to get this team moving in the right direction. Now, if you consider MVC a design pattern (I dunno if it is that or a paradigm?) and have a project that requires MVC to solve then I could see that as being an answer. Because in my experience, getting MVC off the ground requires a decent knowledge of decoupling. –  P.Brian.Mackey Apr 4 '12 at 20:03
    
@P.Brian.Mackey MVC or MVP for .NET is a design pattern. You can come up with creative projects to teach it. Anyways, from what I can see, most design patterns are all about different ways to do decoupling. If they start playing with one, they will start to develop a consciousness for expecting clean and decoupled patterns. –  Jonathan Henson Apr 4 '12 at 20:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.