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.

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.

share|improve this question
Doubt I'm the only one that hasn't read the article mentioned at the beginning: joelonsoftware.com/articles/fog0000000332.html –  DKnight Apr 12 '11 at 17:15
@DKnight I see URLs like that and I've got to wonder, did Joel foresee a day where he'd written 1 billion articles? :) –  NickC Apr 12 '11 at 18:10
Ultimately I ended up being fired July 2012 for constantly pushing quality and craftsmanship (and ironically the reason why the CIO told me I was being let go was that my development skills weren't very strong!). I'm now in a non-developer position at another company (well a tiny bit of SQL but it's mostly using proprietary applications), and it's doubtful that I'll look at another software job because I'm so tired of dealing with situations like this. When you're the only one who sees a problem, you BECOME the problem... –  Wayne M Feb 25 '13 at 12:25
@WayneM "it's doubtful that I'll look at another software job" - that would be a shame, from what you've written here. Just a little amount of due diligence before applying/accepting goes a long way. –  AakashM Apr 29 '13 at 15:28
What happened to Wayne is exactly why I tell every new hire (unless they were specifically brought in to make changes) to spend the first 6 to 12 months just learning how things are done at the new company and building your credibility. You can be absolutely correct, but with no credibility, that means nothing. Also, while practices at a particular company may seem wrong, many times there are very good reasons that they do them that way. If you don't pay attention and pick up on those reasons then you lose your credibility by suggesting alternative ways that don't fit that particular company. –  Dunk Apr 29 '13 at 19:26

7 Answers 7

up vote 7 down vote accepted

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.

share|improve this answer
A lot of it just seems to be ignorance and unwillingness to "man up" an tell management that things can't be done as quick as they want (what I call "Company Man" syndrome, where people just agree with everything management says as though it was liquid gold from the voice of God). For instance, management decided they wanted to offer a "non-branded" version of our own website with some features to clients. What did the developer do? Copy all of the code and paste it almost verbatim but stripped out the styles. Not enough time to make it modular, just copy + paste to get it done for the boss –  Wayne M Apr 13 '11 at 13:44
Also, the code is littered with comments like "Why is this here?" or "This is the same as <other method above it> not sure if they both need to be here" but nobody dares fix it. –  Wayne M Apr 13 '11 at 13:45

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.

share|improve this answer
+1 Technical Debt is a great way to explain to non-technical people: express the problem as having a cost which refactoring seeks to reduce –  HorusKol Apr 12 '11 at 23:41

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

share|improve this answer
You're right, that is a good read. I find myself thinking exactly like the "Bill" character in your post :) –  Wayne M Apr 12 '11 at 18:51
Don't tell anyone but Bill is really me ;) That is pretty much a summary of what happened on a project I was on. –  Mike Brown Apr 12 '11 at 22:56
the link you gave doesn't lead to the blog post anymore, would you mind updating it? preferably along with a brief summary of the post. "Link-only answers" are not quite welcome at Stack Exchange –  gnat Apr 29 '13 at 6:00
@gnat you're right, I updated my answer to provide more clarity. –  Mike Brown Apr 29 '13 at 15:23

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
Thing is, if I tried to fix a bug the way I see fit, I would be reprimanded for changing code in other places (from what I was told the previous Development Manager was fired for doing just that; fixing issues that were "wastes of time" i.e. refactoring code when there wasn't a bug there and there was new features to be done...) –  Wayne M Apr 12 '11 at 18:48
So you have code in place "A" that has a bug. The code was copied to place "B" and there is no bug? Or maybe a bug no one discovered yet? –  JeffO Apr 12 '11 at 18:56
No, there is usually the bug but it's considered a "waste of time" to go on my own and spend, say, a day or two refactoring the code in A, B and C to use a common module instead of duplicating the code. My co-workers would handle the problem by just copying the fix to A/B/C. –  Wayne M Apr 12 '11 at 19:23
I suppose I could just say the task will take a bit longer and use that "extra" time to clean it up, but when my checkin is looked at by the manager he will ask why I changed all the code, and if I say so we don't have duplication and can fix bugs easier, I will be told not to do that. –  Wayne M Apr 12 '11 at 19:25
Find the spots where you can think smaller... even where that's replacing 5 lines of the copy/paste A B C with one simplistic method. This way you can slowly, very slowly progress with improving - but your refactoring (and associated unit tests) will start to become visible, hopefully in a good light. –  Matt Apr 12 '11 at 21:33

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.

share|improve this answer

Your Answer


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.