Is "as long as it works" the norm?

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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

Answer 9

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.

Answer 10

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

Answer 11

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.

UPDATE

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.

Answer 12

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?

Answer 13

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.