See my more recent question: Is programming as a profession in a race to the bottom?

My last shop did not have a process. Agile essentially meant they did not have a plan at all about how to develop or manage their projects. It meant "hey, here's a ton of work. Go do it in two weeks. We're fast paced and agile."

They released stuff that they knew had problems. They didn't care how things were written. There were no code reviews--despite there being several developers. They released software they knew to be buggy.

At my previous job, people had the attitude as long as it works, it's fine. When I asked for a rewrite of some code I had written while we were essentially exploring the spec, they denied it. I wanted to rewrite the code because code was repeated in multiple places, there was no encapsulation and it took people a long time to make changes to it.

So essentially, my impression is this: programming boils down to the following:

  1. Reading some book about the latest tool/technology
  2. Throwing code together based on this, avoiding writing any individual code because the company doesn't want to "maintain custom code"
  3. Showing it and moving on to the next thing, "as long as it works."

I've always told myself that next job I'm going to get a better shop. It never happens. If this is it, then I feel stuck. The technologies always change; if the only professional development here is reading the latest MS Press technology book, then what have you built in 10 years but a superficial knowledge of various technologies? I'm concerned about:

  1. Best way to have professional standards
  2. How to develop meaningful knowledge and experience in this situation
  • 3
    What country is this?
    – user1249
    Commented Feb 3, 2011 at 16:59
  • 3
    Inevitable Dilbert reference: runningagile.files.wordpress.com/2007/11/…
    – nikie
    Commented Feb 3, 2011 at 17:07
  • 5
    <quote>Agile essentially meant they did not have a plan at all about how to develop or manage their projects</quote> This is not agile. This is not anything. Commented Feb 3, 2011 at 17:30
  • 4
    @Martin York: True, but some places seem to call themselves Agile when they lack a plan or a spec. It's sort of like playing the cello with no idea where to put your left fingers on the strings, and calling it atonal music. Commented Feb 3, 2011 at 18:17
  • 2
    I think people are missing the point of the question. My point is the dynamic I described here doesn't seem to actually require skill or lead to developers building skills. It seems to lead to developing a superficial level of knowledge that does not endure. Accountants, lawyers, etc. develop experience that makes their training more valuable. Given the dynamic I've seen here, I don't that being the case for us.
    – q303
    Commented Feb 3, 2011 at 18:22

13 Answers 13


You've indirectly stumbled on what I think is the key aspect to being a good developer: striking the balance between "as long as it works" and well-engineered, elegant code.

Just like in politics, it is much easier to stake your position on one end of the spectrum versus taking a nuanced position in the middle. The majority of developers I run into fall into one of two categories: coding cowboy hacks and architecture astronauts. I try to strike a balance between the two. It's not as easy as it sounds.

To more directly answer your question, yes, I think "as long as it works" is often the norm. But look at it another way: you're in an excellent position to educate your colleagues and try to introduce some better practices. But don't go to the extreme, and remember why we're all doing this: to solve our customer's problems.

  • 2
    +1 Especially, for: remember why we're all doing this: to solve our customer's problems. Commented Feb 20, 2011 at 7:49

>> At my previous job, people had the attitude as long as it works, it's fine.

May be I'm a minority here but I have the same attitude and I strongly believe that to rewrite something there should be clear evidence why do we need this. And I don't mean something like "uf, I don't like how it was coded" - every developer has its preferences about the code. There should be some problems with the part we want to rewrite:

  • Performance problems
  • There were more bugs found than in any other parts of the system
  • Developers spend more time when they work on this part
  • etc.
  • 7
    +1 I strongly believe that to rewrite something there should be clear evidence why do we need this Commented Feb 3, 2011 at 17:20
  • 3
    +1. Most programmers seem to be so passionate about the code, it's beauty and purity etc. that they don't realize the code is actually just an artifact of the thing they're supposed to develop. In the end, all that matters is that it works. That's what your paying customers care about. Commented Feb 3, 2011 at 17:37
  • 9
    I have no problem with your answer, but this attitude is so often used by management to disagree with all the actually good reasons to rewrite code -- "That's not a real reason" and they move on.
    – Nicole
    Commented Feb 3, 2011 at 17:49
  • 4
    @Michael: Refactoring is extremely important. And so is that the code works. And so is that it gets done quickly, because else your competitors will win. It's also extremely important to get it done with limited resources because there's so little money and so many other things to do. There are quite a few things that are extremely important, and business is all about balancing between them. Not an easy task but the successful ones, such as Google, invariably seem to lean towards the "get something out quickly, polish later" attitude. Commented Feb 3, 2011 at 17:53
  • 3
    @Joonas Pulakka: That depends entirely on the market. For websites, being first is often more important than having the best product, so that's what google and others did. On the other hand, if you tried to "get something out quickly, polish later" with e.g. live-critical medical equipment, you'll probably not have your business for long.
    – nikie
    Commented Feb 3, 2011 at 18:11

Agile is not responsible for any human deciding to release buggy software; humans are.

That said, you give lot of importance to quality, and it's good. I'm sure you are a perfectionism and you are concerned about your own value if you don't catch up with the latest technologies.

The problem is that perfectionism leads to procrastination and procrastination leads to mediocrity.

That's why business will put priority in stuffs like time to market and use agile to deliver value quickly and at a predictable pace.

Since you did not describe the business strategy of your company, I think you should start by asking question about that to your managers.

By being aligned on their objectives and plans (they hired you to help them achieving them), you will be in better position to understand how you could contribute to them instead of focusing on your own and personal objectives.

I'm sure that by trying to understand their value, you will be able to share yours, and that will be the beginning of a fruitful collaboration.

And if you discover they don't know what they are doing, your only option will be to quit.

  • 2
    I especially like this line: The problem is that perfectionism leads to procrastination and procrastination leads to mediocrity. Commented Feb 3, 2011 at 17:17
  • 1
    Pierre is like the Yoda of this site!
    – ozz
    Commented Feb 3, 2011 at 20:44

It all depends on what you are building. If you're building a microsite that will only be online for a month, and you have nine days to build it: then yes, as long as it works will suffice.

If you're writing the fly-by-wire algorithms for the FA-18 system, then it better be built as perfectly as possible.

So as is the case with most technology answers... it depends.


It depends on the company. However, many companies have serious competition and time pressure. That's one typical reason. Another would be a large workload, potentially without enough staff. (Some very good reasons exist for being understaffed, that aren't necessarily the fault of the company.) That said, some organizations couldn't manage their way out of a wet paper bag.

I think the 80/20 rule applies here. Basically, you need to put up with the crappy 80% and work your way into the 20%. However, realize that even they will have to make trade-offs. In business, it usually doesn't matter that you have it absolutely right. It matters that you have it right now.


if the only professional development here is reading the latest MS Press technology book, then what have you built in 10 years but a superficial knowledge of various technologies?

That would be rather sucky but there may have been some spectacular failures to note in that decade. I've seen many places where I can remember rather specific things that I liked about working there or did not enjoy and thus would question having that again in my new workplace. Sometimes there may be the new practice to try like if a company tries to implement Scrum or adopt a Test-Driven Development approach those may be opportunities but not necessarily see as professional development as it isn't in a formal classroom setting.

I know various places where the "as long as it works" is common along with various cowboy coding strategies. In a couple of start-ups I have seen this kind of mentality which can make sense if the company is so young that they are still trying to flush out the idea of what are they really trying to do. At other companies I've worked there has been more process and a maturity that can be quite good though not necessarily easy to find I fear. Some places had some processes that I got to see and go, "I like that. I'll remember that for later work situations," and others where I'd go, "I really don't like that. I'll note to try to avoid that in the future." There is something to be said for finding a good job like finding the right treatment for some medical conditions where there may be dozens of different ideas but it isn't know which combinations will work for a specific patient.


I worked at a shop like this for a while just at the point where it was catching up to them. There were two or three year old applications with known bugs that they literally could not solve. Think of a 4,000 line long loop with a running calculation for layout widths and heights. Fixing a piece of code to repair an issue in one instance would result in twenty issues elsewhere because prior developers had band-aided similar issues by arbitrarily adjusting calculation results with magic numbers. The code could not be described as anything other than toxic.

I finally was handed a new project that my boss told me could use this existing code to handle layouts. Somehow I convinced him to let me "alter" it so he gave me some extra time. I used the time to instead write a well designed library to assist with the layout. Bugs in this new project literally took me 10 seconds to solve. I could identify issues before even looking at the code to see what went wrong.

I thought this would result in a turning point for my manager but all I got was a pat on the back and he essentially told me that "Your way works too I guess."

I've since began working for another shop and things are better here. Point is, you can't change their minds. Just go work somewhere else.

  • 2
    Agreed... There's no point in trying to change anyone's minds at a place you work unless you were brought in as a senior / lead developer where they are expecting this from you. I feel like I'm working at the place you described you first worked at and I'm about ready to jump ship to hopefully greener pastures Commented Feb 7, 2011 at 22:46
  • Same thing; I always seem to find jobs with ignorant co-workers that are literally incapable of doing things right, and when I try to explain better ways I kind of just get this "Huh?" look or some excuse why they can't do it (e.g. we don't have time to refactor code, it needs to be done), so nothing changes and I get frustrated having to deal with poorly-written stuff. Commented Apr 21, 2011 at 14:56

I still have hope, that in economy there is a kind of evolutionary process, that sooner or later kicks such companies out of business. But maybe the high pace of technological progress produces too many new niches, so even weak competitors can still find enough "food".

If you want to increase your chances to work in a good place, look for a company that has a product they sell to many customers instead of writing something new every few weeks. There should be more interest in having a good code base and being able to add new features without breaking existing code all the time.


Reminds me of my major-mate from college. He was taking a VLSI design class, and for his first homework came up with a component that was on the order of micrometers wide and a mile long. The simulations passed perfectly.

His reply to his critics was: "All I know is that my shit works.".


A quite good norm is Pareto principle

I have experience from a project with 80-20 rule and it worked very well. I think answers to this question "Where do you draw the line for your perfectionism" can also be helpful.

The term "Pareto principle" can also refer to Pareto efficiency. The Pareto principle (also known as the 80-20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes. Business management thinker Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he developed the principle by observing that 20% of the pea pods in his garden contained 80% of the peas. It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients". Mathematically, where something is shared among a sufficiently large set of participants, there must be a number k between 50 and 100 such that "k% is taken by (100 − k)% of the participants". The number k may vary from 50 (in the case of equal distribution, i.e. 100% of the population have equal shares) to nearly 100 (when a tiny number of participants account for almost all of the resource). There is nothing special about the number 80% mathematically, but many real systems have k somewhere around this region of intermediate imbalance in distribution. The Pareto principle is only tangentially related to Pareto efficiency, which was also introduced by the same economist. Pareto developed both concepts in the context of the distribution of income and wealth among the population.

Link to Source

  • That's great but how does it relate to the question? Are you saying 20% of the workplaces generate 80% of the bad software? Commented Feb 8, 2011 at 1:55
  • No, if software works 80% it's fine. The accepted error rate is 20%. Commented Feb 8, 2011 at 7:37

When I asked for a rewrite of some code I had written while we were essentially exploring the spec, they denied it. I wanted to rewrite the code because code was repeated in multiple places, there was no encapsulation and it took people a long time to make changes to it.

No offense, but as a manager I read that statement somewhere along the lines of:

"When I asked to be paid twice to rewrite some code I've already written, my company didn't want to pay up. I wanted the extra money to clean up the mess I made when I wrote it the first time, and my colleagues were mad at me for making their lives difficult."

If it's your own code you're complaining about - you don't have much to stand on.


I understand that this POV is unpopular. But, I don't think it's at all incongruous with a professional developer's responsibilities and attitudes, either.

If you write clean code to begin with (and there's a multitude of reasons to do this - regardless if you think your code is going to see production use or not), then you will have this problem a lot less regularly.

If you include clean code and refactoring time in your estimates, you'll also have the schedule to keep the codebase tidy. If, because of schedule pressure, you don't get the needed time - your future estimates should go up as a result of dealing with the incurred technical debt.

At some point, your future estimates (or uncertainties surrounding your estimates) will give you leverage to argue for a rewrite (when your manager is begging you to make the process go faster). If not, then accept that the business has accepted your estimate and would rather pay the ongoing cost than for a replacement. That's purely a business decision - not a technical one.

Remember, the time to negotiate schedules is before you've written the code - not after. After the code is written (and "works"), customers, managers, and executives don't want to see another bill for "maintenance" that approaches or exceeds the original cost. If you feel as strongly about it as you think the business should, feel free to rewrite it on your own time - that's what you're asking the business to do.

From your manager's point of view, giving you schedule to rewrite puts his ass on the line. When you fail to deliver, or increase productivity by as much as you say - then he's the one left holding the bag. Compared to the relatively minor inconvenience of listening to you complain, guess which one he's going to prefer.

  • 2
    Notice that "essentially exploring the spec." If, as a manager you provide me with a detailed spec and I need to do a rewrite, my fault. If you DON'T provide a spec and evolve it as I write, I will need to refactor because I won't have known all of the requirements in earlier parts of the code.
    – q303
    Commented Feb 3, 2011 at 18:17
  • 8
    I want to downvote this answer so much it hurts. But I can't... this REALLY IS how managers think. It is up to the development team to put it in terms that managers can accept. Saying "rewrite" even though the thing works is going to trigger Mark's reaction every time. Perhaps saying "solidify" or "stabilize" or "finish" will be less jarring. Managers have to realize that they have gone into production with incomplete code, and it is up to them whether they want to finish the job; it is up to developers to convince them of the costs of not doing so. Commented Feb 3, 2011 at 18:52
  • 1
    @jeff - spot on! A wise colleague once said to me "don't give them the opportunity to say, it all depends on how you phrase the question".
    – ozz
    Commented Feb 3, 2011 at 20:43
  • 2
    Your stance as a manager works until the original developer leaves. Someone else then has to pick up his code and either a) spends 10x as long working on changes than they should have done, or b) produces changes that introduce awful bugs. Then it's not a coder complaining about his code; it's a new developer complaining about problems that you prevented from being solved when they could have been fixed more easily. The idea that developers are interchangeable "resources" is a very naive viewpoint.
    – Ant
    Commented Feb 4, 2011 at 12:28

If that's the kind of job that you can get, just focus on writing better code each time, rather than going back and rewriting old code. There is still a quality range that you can move in within the realm of gluing together third party packages.

If you have time and want to improve the code of an existing component that you maintain, can't you just do it without asking for permission, as long as what you do works? Factor the time into your estimates for the next project that uses the component.

For lower level programming, if you can't get learning satisfaction from your work then maybe it's time to look at an open source project?

  • Typically a major reason that people don't like touching existing, ugly code is that it works through many iterations of bug fixes / bandaids. To go and rewrite it - without permission - is like throwing out all those bug fixes. You're swapping out battle-tested code for something fresh out of the factory. I wouldn't do that without asking for permission. Commented Feb 8, 2011 at 2:03

q303, I found your question interesting and felt you might find this Programmers question worth a read, about how to convince managers to let developers address technical debt.

I think generally, yes, it is the norm. Understand that working but less-than-optimal software is a lot better than non-working software. There's also the argument that the definition of "working" could vary based on each individual's perception and biases. When you implement a new system, there's always someone that will say they felt the old system was better. And when you talk to a developer, he or she is likely to be reluctant to admit to having worked on crappy software.

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