Introducing design concepts/patterns/principles to co-workers

Question

I've read Joel's article about getting things done when you're a "grunt", several times in fact, but I've never been able to do any of the things it mentions.

I work as part of a small development team; we are now 5 strong (they recently expanded; started with two guys for a few years, and then added the rest of us - I have been here about 3 months now and two others were added after me) with a web designer that is kind of part of our group. The app we work on started out as an in-house system and was recently retrofitted to be software-as-a-service. From what I've been told, it went through several revisions and was outsourced twice, then brought entirely in-house.

I come from environments that focus heavily on the use of design patterns, bits of Agile design, and a strong desire to write quality code. Because the current environment has changed so often, the code is a bit of a mess; logic is often just copied and pasted across various files (this includes HTML, Javascript and C# code). Almost everything is done in code-behind files with very little separation of logic. There is a common set of classes but they tend to just incorporate various mismatched logic that only slightly relates to the class. There are no coding standards and developers write code as they please (for instance, some code uses Hungarian notation, some doesn't, some classes begin with underscores, some don't). There is little object-orientation used; all the data is passed around as raw Datasets executed via stored procedures. The few domain objects have misleading and confusing names.

We are almost always working on new features, and have no time to refactor since refactoring code isn't viewed as adding business value in lieu of adding new things. I have raised some issues with the manager about taking the time to go back and fix the application, extract and refactor code to be more modular and reusable, but he expressed concern that management wouldn't allow us to spend days (or more if necessary) working on old features instead of new. My co-workers don't seem too concerned with this and seem to not be as concerned as I am about the quality of the code we are producing. Also there are no unit tests (testing is done manually by poking around the app) and I wouldn't be able to take the time to test everything.

This produces a dilemma for me because I find it frustrating to fix code in one place, only to be reminded it also needs to be fixed in several other places due to being copied across files, and I find it increasingly hard to stay enthusiastic about the code since I have to continually drop back to the existing style (or lack thereof) when fixing bugs; for new modules I write I try my best to keep the code as modular as possible within reason and without introducing radical changes (e.g. trying to incorporate Linq to Sql). Even this causes some concern because I am introducing a different architectural style (albeit one that is better than the style we have now) than the other developers are using.

How, if at all, should I go about explaining these things to my co-workers and try to introduce some order to chaos? I look at the code and see how much better it can be with application of design patterns and real code re-use, but it seems like a daunting task because we are constantly inundated with new tasks and cannot just take a week or two out to refactor the code smells away. I know that I cannot ever get us to fix all the code that needs to be fixed since it would be a total rearchitecting of the application (and management would never approve that), but I feel that the code could be much more stable and robust for the future if something was done.

Answer 1

You've had some excellent advice from other guys here about how to try to improve matters, but here's the alternative option that you need to keep in mind:

Ultimately, if you're in a situation where you have an untenable codebase, and as you said in a comment, the last guy got fired for trying to improve things, it may be time to say "this is not a company I should be working at." Life's too short to work in a job where, of all things, management won't allow you to even try to do a good job. That's insane! We're not talking about bad coffee or uncomfortable chairs or annoying muzak or even money here, we're talking about an employer that says "you will do a bad job, because I think that doing a good job is a waste of time that could be spent billing clients for a bad product."

This explains a lot, by the way, about the lack of concern shown by your co-workers: this blog post on "the Dead Sea effect" may be illustrative. "My co-workers don't seem too concerned with this and seem to not be as concerned as I am about the quality of the code we are producing"? Like Webster wrote in that article, "What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers." You want to be the guy moving onwards and upwards.

Answer 2

We were in a similar situation where there was some fuzzy uneasy feeling about our codebase's quality, but yet it still seemed to work "just good enough" so that nobody wanted to allocate resources for a cleanup.

What helped us was that we were able to get key managers infected with ideas in their language, specifically

• Technical managers: The Big Ball of Mud was a pretty good diagnosis of the situation we were in, and it also hints what ways can lead out of the mess.
• Non-technical manager: The term Technical debt just rang a bell there.

The key was to transform the fuzzy feeling into something we all could name. That made it much easier to discuss the real issues.

Answer 3

I've seen variations on this question a number of times. The simple answer to your problem is to follow the boy scout rule (always leave a campsite better than when you found it). When you estimate a task, take into account the time it will take to refactor the code in question to be better designed/organized. Don't ask permission to do a good job, do a good job because it's part of your job.

As you slowly improve code that you encounter, you can point to that code as examples of how it provides benefits to the team(future changes are easier, it's easier to understand the code as a reader). You'll never get permission to stop writing new functionality so that you can "clean up the code". But if you clean the code as you write new functionality, you create a win-win situation (you introduce better design to the team, and you make future changes to the code easier).

Answer 4

One idea is to start by adding unit tests to those areas that can be tested (perhaps that "common set of classes" you mentioned?)

If you have to run it by your manager, you can remind him that testing needs to be done anyway, and it eventually will save time if the testing is actually automated. Maybe add the tests as you go - to whichever module you're maintaining or modifying at the time. If other types of automated tests would help, see if you can get your manager to sign off on those as well.

Perhaps once your colleagues see how great it is to have a set of tests that can be easily run when you make changes, they'll at least come around to unit testing and possibly test driven development, which may be the best route to ultimately re-factoring the entire code base.

Answer 5

I think you're in a rough spot because the company seems to be in a mode that it is willing to trade technical debt for speed to completion. A false economy, for sure, but one that companies are often willing to engage in because the ultimate decision makers are those concerned about the bottom line, and the short term gains.

One strategy I could think of would be to smart small. Perhaps introduce a coding standards guideline that addresses the top 5 or 10 themes that tend to pop up in the code. Another thing you could do is push for "refactoring sessions" where the team, or particular members, could stop new development for a day or two to refactor some of the weakest code.

Ultimately, what I'm getting at is shifting the culture to think more about code weakness and technical debt, and get more people in the organization thinking about it.

The business argument is that there is a thresshold at which technical debt will arrive that will make new development (and even maintenance) very costly.

I think that only once code has been refactored to be more readable, reusable, and safe can you really take the next step, which is to integrate design patterns into the code base - crawl, then walk.

Answer 6

There is nothing in the article about fixing your team. If you try to start there, you'll just drive yourself crazy. They don't think there is a problem why would they think you have solutions? Write tests for the new features you're implementing. When asked to fix a bug that has been copied all over the place, fix it the way you see fit.

You can't find someone in the hall to do a quick user test? I don't buy that.

Eventually, you should become more productive and someone is going to take notice. Will you release fewer bugs due to testing?

I'm not recommending you go 'rogue' but you could do a lot more and no one on your team will notice or care.

Answer 7

Be a leader among your colleagues. You already know what's wrong, you already know what needs to be done, you already know the benefits.

Your first step is to show your colleagues what you consider is wrong, explain what needs to be done and show examples, and I cannot stress enough the examples part. People that are not aware of design patters, for example, won't understand them no matter how much time you take to explain. Show them how it's done, and compare to the current code. Little by little they will get new ideas, new concepts that will help in refactoring the application. Take the first 45 minutes before you all start working and do that. Invite them to your fort.

Your second step is break down the changes into manageable pieces so everyone could work on a piece. All of you should work as a team and you should fix an aspect of the application at a time and not everything. Collaboration is key and communication is paramount. Do it without the knowledge of the top management. Do it after work if you have to. The benefit for you and your team is invaluable even if you dedicated some private time.

Your third step is to repeat your first and second step until you have an application that you can look at, you can work with and you can test.