Is there a resource that explains the benefits of layered programming?

Question

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".

Answer 1

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.

Answer 2

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. :)

Answer 3

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.