Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is a question that I often ask myself when working with developers. I've worked at four companies so far and I've become aware of a lack of attention to keeping code clean and dealing with technical debt that hinders future progress in a software app. For example, the first company I worked for had written a database from scratch rather than use something like MySQL and that created hell for the team when refactoring or extending the application. I've always tried to be honest and clear with my manager when he discusses projections, but management doesn't seem interested in fixing what's already there and it's horrible to see the impact it has on team morale.

What are your thoughts on the best way to tackle this problem? What I've seen is people packing up and leaving. The company then becomes a revolving door with developers coming in and out and making the code worse. How do you communicate this to management to get them interested in sorting out technical debt?

share|improve this question
"working with developers" "communicate this to management" Which are you asking about? Developers or managers? Who's behavior do you want to change? – S.Lott Feb 4 '11 at 23:53
Technical debt is like financial debt - it's much easier in the long run to simply not accumulate it to begin with. Pay all your technical bills once a week. – Lawrence Dol Feb 5 '11 at 4:25
Mike > I think you live in much less restrictive world as deadlines and limited budgets dominate the world I live in. If software doesn't adapt well to future needs and requires a lot of work to fix, then management are often more concerned with ignoring it and keep bolting on features. Now a lot of companines I've worked in put timesheets in place so developers need to record their work and if time isn't being invested in where management sees the potential business, then you are wasting your time. – Desolate Planet Feb 5 '11 at 11:00
I guess you could say it's a problem with short term benefits vs long term benefits. If a software team tidied up a system in such a way that new features took under an hour to implement instead of a day, that is an immediate benefit. If management see you trying to improve the code and going against what they want, you are being a bit of a rebel in their eyes. I dunno really what the best solution is, but it seems like such a common problem and I've seen what it does to teams. – Desolate Planet Feb 5 '11 at 11:03
Scott > To answer the question, it's managements attitude I'd like to change. Developers know the code and have first hand experience as to what code be improved upon to make things easier. In a previous job when we released a new version of an app, the number of bugs kept increasing at an awful rate. I've tried hard to get test strategies in place, but it often feels like a lost cause. – Desolate Planet Feb 5 '11 at 11:06

16 Answers 16

up vote 145 down vote accepted

When I met with my boss to discuss this, he said I should include refactoring in all my estimates. He said it's not a problem he wants to think about. Instead, I should handle it.

This isn't a problem that management in general wants to think about. They aren't the engineers, you are. Just make this an unspoken part of all of your estimates, and you'll find that the technical debt decreases.

It will never be perfect though. Technical debt, like credit card debt, is an investment in getting customers faster and gaining market share over your competitors faster. Like credit, if managed properly, it can make you quite successful.

share|improve this answer
my experience is generally along the lines of this. The technical debt gets cleaned up as new features are added. Sometimes the estimates for certain 'related' fixes/features are padded to include cleaning up these things. – Ken Henderson Feb 5 '11 at 3:28
+1 You share my sentiments exactly...except you expressed yourself much more diplomatically ;) – Michael Brown Feb 5 '11 at 4:10
Good answer. I'm yet to see a business who are happy to sign off a 'refactoring' project that would yield no benefit to the customer, only tidier code. Refactor-as-you-go. – JBRWilkinson Feb 5 '11 at 9:06
"When I met with my boss to discuss this, he said I should include refactoring in all my estimates." - This is the attitude I take and the stance many developers in teams I've worked in take. However, when these 9 till 5 developers as we call them are concerned with their reviews and pay rises, they aren't going to create more work for themselves. They are going to follow whatever management thinks, after all, that's who pays them. – Desolate Planet Feb 5 '11 at 11:27
@jmort253: there is one (slight) issue with this otherwise excellent policy -> it's not possible for extensive changes (ie, changing the database as said by the OP). Those must be explicitly addressed. – Matthieu M. Feb 5 '11 at 19:02

It's like Gandhi said when asked if his tactic would work with someone like Hitler. He said, "It would be difficult." But I think there's a fair argument that the answer really is "No." Sadly, I don't think what you are trying to do can be done. It's not that I'm trying to be pessimistic, but rather I'm trying to be honest.

The problem to me is not that managers need convincing. The better ones already understand that debt can be a killer if not managed. But whether they understand it or not, whether they're good managers or bad, they all face the pressure to deliver, and that delivery is judged by their bosses against a date. Quality only matters if it's extremely bad, in which case it's the developers' fault, or extremely good, in which case it's management brilliance that made it happen. Quality just needs to be "good enough."

I think I like what Renesis said in his answer, because it's one of the few that understands that management thinks very differently than engineering. And I think we've all seen the progression of companies to become date-driven and more project-managed as opposed to customer and quality focused. By this, I mean typical companies, not the really stalwart ones that have the guts to say "It'll be done when it's done" (like Apple Computer or id Software - and yes, I understand that sometimes people aren't at liberty to take that approach).

But here's the thing: companies that take the quality-first approach...what do you notice about them? That's right, they're run by engineers, not salesmen, marketers, project managers or accountants. Think of HP, Apple, id, Google, Microsoft, and IBM. All started and made successful by engineers, not salesmen, though salesmen certainly played a part, and I'm sure many would debate having Microsoft associated to quality :). And of those, the ones that went downhill got away from engineering-driven leadership. There's a whole host of arguments in that statement though, as there are plenty of technical companies that ultimately failed due to an inability to adapt to changing times and manage their own growth. I don't see engineering-based leadership as the cause for those failures, to me that's an issue of skills and business acumen that are independent of someone being a developer or an accountant. I think generally speaking, however, that there is a dedication in engineering to the rigors of accountability and discipline that benefits companies where engineering is a component.

Seriously, look around. IT leadership is sorely lacking. Focus is always on cost and time, and rarely on quality as long as it's good enough. IT leaders rarely report to the CEO anymore, now it's always the CFO. IT is stuck doing production support and increasingly beholden to project managers whose focus is on smaller, more digestible, and measurable chunks, not significant changes of revolutionary value (not that this is necessarily wrong; divide and conquer is a good thing, but the vision needs to be there for the big picture).

Sorry to take so long on this post, but in the end I think your question, about how to make management care about technical debt, is often better solved by finding the right leader, rather than changing the existing one. Explaining technical debt to standard thinkers means changing the focus to money and cost, as Renesis said, and I think that loses a lot in translation; even if you were successful at it, it would only matter if the top leader in the company bought it. Convincing your middle manager to do the right thing will probably only get him fired.

share|improve this answer

First thing to do is change the wording. Calling it "technical debt" gives management the idea that allowing it is an investment of some sort — when really it's more like a virus. (I'm like the Dave Ramsey of technical debt.)

Allowing it to go unpaid comes with a huge cost which can't be seen or easily quantified.

List problems such as the following for management:

  • New features estimates are way higher than they need to be. Or, impossible altogether.
  • Bad code spawns more bad code
  • Bug list grows even if developers are always fixing them
  • Team members are leaving (this itself can show that there is a problem as explained in this excellent answer)
share|improve this answer
+1, although I think the last bullet should be "The good/best team members are leaving" – Ken Henderson Feb 5 '11 at 3:29
Bit technical debt is an investment sometimes. If you're racing with another company and who launches first gets the market for themselves, then it makes sense to make shortcuts in the code to launch faster. Nobody will care that you have perfect code if you have zero paying customers. – quant_dev Dec 23 '11 at 10:59
@quant_dev if you see this as a dichotomy between "faster" and "perfect code" then of course you'll think that way. There is no reason why shortcuts can't be technically sound in which case they are not considered technical debt. – NickC Dec 23 '11 at 17:07
@Renesis "There is no reason why shortcuts can't be technically sound" -- that's just not true. – quant_dev Dec 24 '11 at 17:13
And sometimes it's not technical debt at all, it's just a mess:… – TrueWill Jan 13 '14 at 19:01

My management has actually started making a serious effort to address technical debt, which is one of the reasons I like working there, but it's a long term effort and it never hurts to remind them why the effort is worth it.

One way I keep the pressure on is whenever I am asked for an estimate, and time could have been saved if I didn't have to deal with specific technical debt issues, I include that in my estimate. For example, "This bug will take me 2-3 days to track down, but if we had already addressed these 2 other 'low priority' bugs that have been in the queue forever, it would probably take less than one." Often, the response will be to go ahead and fix those other ones while you're at it.

I also agree with other answers about just considering improvements part of your job and doing them as you go if it's not too disruptive. My current task involves making additions to some very poorly designed code. Rather than adding to the mess by writing my new code to match, I'm spending a little time up front consolidating common functionality, so sending a packet becomes a one line function call instead of constantly repeating 15 lines of slightly modified copy-and-paste boilerplate.

I know for a fact it is going to save some maintainer's sanity further on down the road. I know because I'm that maintainer today. However, I also believe it's going to speed up my own current task of getting this feature in and debugged now.

Another technique I've used in the past and should do again is to keep a refactoring DVCS branch around in a separate working tree for that down time when you're compiling, waiting for a long test, or just need a change of pace for a bit when you're burned out on a bug. As long as you occasionally merge from upstream so you don't diverge too far, you can take as long as you want on refactoring changes with very little marginal effort. 15 minutes here and there per day can really add up over time.

share|improve this answer
I just adopted your approach. +1 – Adam Arold Jul 30 '13 at 11:06

You could try the credit card analogy. Ask them "do you feel comfortable leaving your credit card statements unpaid over an extended period of time?"

Managers understand costs and benefits, but (usually) not the technical terms used by us developers. The term "technical debt" was already invented to help overcome this communication barrier, but you may need to articulate it clearer. Most managers know very well (often from own experience) that overdue credit card payments grow with a horrible interest rate so it hurts to leave them unpaid. This may help them get the seriousness of the issue regarding software entropy.

But if this doesn't convince them, try to gather factual evidence and make some calculations. E.g. how much does it cost for the company - both in hard cash and lost time - to replace a leaving employee.

share|improve this answer

Nobody will give money for replacing something that works with something else that (with any luck) also works.

What you can do is to propose replacing it with something that does more, i.e. bundle the servicing of technological debt into an upgrade that brings instant and tangible business benefits.

Of course you should be open about it, we're not talking about "sneaking it in" a new project here.

I find the other side, that of the developers' harder to handle. Basically it boils down to this: for some developers, making sure your code is the best possible code you can come up with is a matter of professional pride. For others, this is just another job and the aim is to get it done quickly and go home.

No amount of convincing will change that situation, and if you introduce a mandatory code quality standard, your nine-to-five developers will find a way to work the system, while your dedicated developers will inevitably be annoyed by the whole procedure (which isn't aimed at them, but you can't say that developer X must obey the rules, while Y can do whatever he wants).

What works, but can still be very frustrating is to have your more dedicated and knowledgeable developers overseeing the codebase, probably a good tradeoff between going forward and tidying up what's alrady there.

share|improve this answer
+1 But those 9-5 developers, well, you want the revolving door for them, ideally with some form of accelerator. – Orbling Feb 5 '11 at 0:42
@Orbling: +1. If they don't care enough they really should be working somewhere else. Its GREAT having devs come to you with "I just had this idea...". – quickly_now Feb 5 '11 at 4:07
@Orbling In certain areas of development they can be useful. I'm not at all a fan of "developer snobbery", but you have to find everyone's niche for them to be of any use. The worst you can do is to assume everyone's like you. – biziclop Feb 8 '11 at 18:23
Personally, I think the industry is heavily overstaffed. Where I am based most software jobs get a good 300 candidates applying these days. With that level of competition, an employer can afford to hire employers who go the extra mile and are better than average. – Orbling Feb 8 '11 at 19:13
"Roll upgrades into a refactoring to offer tangible benefits (selling points)" is what I keep hearing from our Chief Architect so I'll have to second this. – Mario T. Lanza Jun 19 '14 at 15:36

The fact is, in a lot of companies, particularly given the current economic situation, every hour must be billed to someone.

Or they go down, fast.

Unless the existing clients are willing to pay for the refactoring, which is deeply unlikely unless it comes with significantly upgraded performance or features. Then it will not happen on the older codebases. You may be able to sneak it in to the budget for newer projects, if the clients have deep pockets, but unless you do not need to change the APIs in the refactoring, it will be of no use to older projects and may well introduce a situation where the company is supporting two codebases, which causes further headaches and cost.

As an engineer, I would love to refactor old code, which is no longer truly fit for purpose, every time something became obsolete or deprecated. But as my MDs in all companies I've ever worked in have said to me: "Who will pay?"

share|improve this answer

I always try to clean up as I go. I am not done until the code is clean. The problem with technical debt is that most people do not understand it. The best way to tackle it is to not accumulate any of it. If your managers trust your developers to decide how to solve a problem you can make code hygiene part of every programming task. If you never check in bad code you do not accumulate debt. If you also follow the Boy Scout Rule (always leave code cleaner than you found it) your existing debt will vanish slowly.

I don't see refactoring as a task separate from implementing features. It is an integral part of it.

share|improve this answer
I could not agree more: "Technical debt is like financial debt - it's much easier in the long run to simply not accumulate it to begin with. Pay all your technical bills once a week" – Lawrence Dol Feb 5 '11 at 15:12

If you're dealing with non-technical managers, it would help if you can cast your discussion into terms they understand. If you can construct a realistic case for a positive ROI on the work spent to pay down the technical debt, you might get somewhere. That exercise will depend on your circumstances, but an example might be something like this:

Analyze how much time developers are forced to spend helping Support with production issues, then make the case that fixing crufty old code would A. reduce the number of support issues, B. make it easier for Support to resolve issues without escalating to Development, and C. reduce the time Development spends on production issues when they do arise. Put it in terms of dollars saved by not having developers tied up doing support work. Also point out that every hour a developer spends doing support is a "double whammy" because not only are you paying a developer to do support, but you're burning the opportunity cost of what that developer could be doing (adding new features, etc.)

Yeah, some of the numbers will be voodoo / smoke-and-mirrors... that's OK, the dirty secret of management is that they know that the majority of the numbers they sling around are total B.S. Just as long as you give them something seemingly concrete to work with, so they can get it in their heads, you have a fighting chance.

share|improve this answer

After this explanation of technical debt, your management should be convinced to pay it off :

Imagine that you have a very dirty kitchen full of crap. Before preparing a meal, you have to first spend one hour cleaning. And it is like that every time you want to eat. Also, when preparing a meal, you have to be extra careful, to make sure the crap does not fall in your meal.

The kitchen is your code, meal is your product, and eating is selling your product.

If they can afford to wait longer for a change to be implemented, without a safe-net of unit tests, then there is something wrong in your company.

share|improve this answer

"Technical debt" can be a tricky subject to present to management as they may not see the need for it. The question could be framed as whether or not there is a champion in the company to state, "Look, we are taking X% time to work on the technical debt here. Give us 3 months to show you this works well," or something similar. There is a claim towards autonomy there but also a time frame as otherwise management may wonder how long until they see some results which is rather dangerous territory.

The first point though is whether or not they see this as a problem. If the person with poor vision knows nothing of eyeglasses and what kinds of changes they can provide, how are they to understand why an eye test could be valuable? Same idea here where the subject is rather technical and not easily quantified unfortunately.

share|improve this answer
I agree with this fully and find it more and more. Recently, I've been gathering up a a list of defects that have been reopened because a proper fix wasn't put in place or defects of a similar nature. Hopefully the developers put in time spent. Sometimes they do, sometimes they don't, but this kind of data is a useful foundation for showing management how an unhealthy product is impacting their business. – Desolate Planet Apr 6 '13 at 19:07
In my current workplace, overtime is allocated for the wrong reasons. If time was invested in keeping the app healthy instead of firefighting problems, money would be saved on overtime and developers would be more empowered rather than burnt out and annoyed at management. – Desolate Planet Apr 6 '13 at 19:09
But the management (in most cases correctly!) sees it this way. I have a 1980s magimix which still works and your telling me to replace it just because its old and the color is unfashionable! – James Anderson Aug 15 '14 at 5:06

It has to be a very convincing argument, in terms of the original product and business case, that I couldn't use that money now to do something more important to me. Like it or not, your management or your customers are paying for this and you need to be able to sell to aka convince them.

Let's rephrase this to position yourself as a customer. Good old role play.

Suppose you were buying a refrigerator. And you could buy a fridge for $1000 that worked OK from Acme Corp. Or a fridge for $2000 from Acme Deluxe Fridges that looked the same on the outside and had the same technical specs, but had lower maintenance costs due to a cleaner internal architecture.

As a customer, which would you yourself buy?

And what do Acme Deluxe's engineers think is the better answer?

share|improve this answer
I'm having a hard time determining your stance on this. I think your answer is "it depends on what the customer wants". The problem is, not every customer understands that the lower cost refrigerator is going to leak melted, nasty gunk from the freezer section, make loud noises, and eventually stop working after 5 years, while the other one will run smooth and quiet for 20 years and not be replaced until it's deemed out of style by owners that will resell it in exchange for a new model. Still, I like the question you posed. It's thought provoking. +1 – jmort253 May 23 '12 at 3:10
First line - "It has to be a very convincing argument [] that I couldn't use that money now to do something more important to me." I use the fridge example as frankly, I don't care about what goes on inside my fridge. I just want an outcome. (cold food at a reasonable price). To be blunt, I don't care if the fridge engineers think it's a better product internally. I might consult them but it's really not their decision. – jasonk May 23 '12 at 21:56

You should just stop complaining about it.

Here's why:

  1. They never plan to use the software longer than a year
  2. it's just waste of time tweaking it if their plan is to dump it afterwards
  3. there's some real problems that need fixing now
  4. programmers just need to learn to deal with maintainance, even if it's not always fun
  5. complaining that you know better what needs to be done is arrogant - someone else makes the decision, and you should be happy about it
  6. They anyway trust you to write good code

So best way forward is:

  1. When they give you new task, try to implement it as well as possible in the given time
  2. Write it perfectly the first time. If you need to change it afterwards, you made a mistake the first time and any change is always going to wrong direction - and it's a learning opportunity for programmers when you make mistakes.
  3. Don't ask extra time for it, you wont get it, there are deadlines you know.
share|improve this answer
I mostly agree except that it is well-known that even crappy software has a tendency to survive far longer than its creators expect. But you're right, it is better to not complain. Instead, if you see some limited-scale re-factoring that will help the comprehensibility of the code it might be worth it to go ahead and make the changes WITHOUT PERMISSION during your maintenance/bug-fixes (and incur a risk doing so). – Angelo Oct 22 '11 at 23:32
@Angelo - Would it not be better to voice your concerns rather than allow the team to suffer in silence? I've seen what this problem does to team morale and also with the amount of time/money wasted on overtime. I don't see it as "moaning" as such. You are simply pointing out project risks and if your ideas can speed up delivery times and streamline processes, then why not at least try to voice your concerns? If this falls of deaf ears, then at least you know where you stand. – Desolate Planet Apr 6 '13 at 19:13
You must complain about it loudly, otherwise it's your fault if other people's code break ("You knew this was a mess and didn't tell anyone ?"). Standing up and going "Hey boss, this shit will sooner or later hit the fan" is vital to keep a dev team functional. – Alex Aug 7 '14 at 13:41

I take it you have never been involved in a project to re-write/replace or even upgrade and existing system.

These are some of the hardest projects to complete successfully. Some of the problems you will come accross are:

  1. Business rules are lost in time.
  2. Documentation and implementation are totally out of sync.
  3. What you see as a bug the users see as a feature.
  4. Conversely many "features" will be viewed as defects by the users.
  5. You will not get user buy in -- they will regards your "fact finding" as "nerds asking stupid questions", they will regard the testing effort as a waste of time, they will insist on adding new features thus lengthening a project will will already be behind schedule.
  6. Chances are the source code does not match 100% with the running executable.
  7. While your department is messing around refactoring development the business actually wants is not being done.
  8. Chances are that your re-factoring will involve "cleaner improved interfaces" thus dragging other projects into your quagmire of late delivery and failed tests.
  9. After the project is canned (well over 50% of these efforts fail completely) you will have lost all creditability -- you will need to move to another company in another town to find someone prepared to listen too you.
  10. If the project "succeeds" everyone will remember what a nightmare it was -- you will .......

I urge you to avoid any re-writes/refactoring projects like the plague, they can be some of the most dispiriting experiences in any professionals career.

There is much wisdom in the phrase "If it ain't broke don't fix it".

share|improve this answer
"I take it you have never been involved in a project to re-write/replace or even upgrade and existing system" - Wrong, 7 years of it. – Desolate Planet Aug 22 '14 at 18:16
I completely agree that a full re-write is often a disaster. But I have three examples over the last 8 years of my career. One was a long slog that resulted in us being able to maintain the product better but provided no business value; another was a short rewrite that was a total success; the third was a decision not to rewrite, which ultimately killed the company. Choose your poison. – Tom Harrison Jr Dec 31 '15 at 19:52

For the life of me I can't understand why some people are so blindly afraid of change--it smacks of lacking confidence in your own abilities.

I watched a show last night on Yosemite National Park and it was remarked that from 1940 through the late 1990's not a single new Sequoia tree sprouted. It was discovered that the reason why was that there was a strict policy against letting forest fires to burn and that Sequoia pine cones needed the heat from fire to open and release their seeds.

You see, a fire every ten years or so was healthy. It cleared out all of the accumulated deadwood and bramble to keep healthy the existing trees (processes) and make room for new ones (features).

I am on a project right now that has a clear case for rebuild: The legacy software was written entirely using .NET webforms. Almost all of the business logic is co-mingled with HTML/server tag view logic and can not be extended into other applications now that the business has grown.

Management is behind the task because they have an appropriate amount of trust in their developers which, I realize, is a rare luxury.

Yes, ask yourself if a rebuild is truly necessary. Do your best to reuse existing code that works where you can. Integrate that code into the rebuild if necessary. Just don't let anyone convince you that being afraid of making bold changes is the only way to exist as a software developer.

Good luck!

share|improve this answer
how does this answer the question asked, "How do you communicate this to management to get them interested in sorting out technical debt?" – gnat Nov 11 '14 at 19:17
@gnat: How do most of the "answers" answer that question directly? See, for example, answers by James Anderson, tp1, or any answers at the top with the most votes. But to answer your question, I provided an alternative analogy the OP can use. Seems to me that you simply disagree with my opinion on the matter. That's fine, but no reason to downvote. – Matthew Patrick Cashatt Nov 11 '14 at 19:48
per my reading, top answer you refer appears to directly address the answer asked, based on relevant experience "When I met with my boss to discuss this..." As for your opinion I rather tend to agree with it, but I vote based on content quality, not on whether I support particular opinion or disagree. Stack Exchange Q&A voting model is quite poor when (mis)used for opinion polls – gnat Nov 11 '14 at 19:58
I recommend reading it again, then. Describing a conversation had with one's boss regarding a method for covering technical debt by padding estimates for future work does not answer the question, "How do you communicate this to management to get them interested in sorting out technical debt?" either. Nonetheless, I didn't down vote the answer because it added to the conversation. So, all you have succeeded in doing is muting an opinion on the matter with which you agree for no substantial reason. "Programmers" should be a place where we can have a conversation. Not everything is binary. – Matthew Patrick Cashatt Nov 11 '14 at 20:04

You need to give your management a financial reason to deal with technical debt, and a framework for managing reducing that technical debt.

Maintaining a technological roadmap is one such framework. Starting out with a roadmap will help you keep you from piling on technical debt, and can also help you reduce existing debt as well.

Many successful long-term projects have associated steering committees and roadmaps to guide development. These are especially helpful when there are multiple development teams and stakeholders involved.

My suggestion is that you discuss this strategy with your managers (and if possible those who make decisions on where money gets spent).

The general approach to creating and managing a roadmap are straightforward, but it does require the support of your management team. First, define a goal. Define the elements of the technical debt, and develop a target system architecture that reduces elements of your technical debt. Remember, it doesn't have to be perfect, just workable and better than what you currently are. Take into account software, development tools, hardware platforms, major new features that may be added to the system. Do a cost analysis. If you have the desired architecture, what are the tangible benefits of performing the refactoring? (Benefits would include reduced test time, more reliable software products, more predictable development cycles, etc.) If you can show enough benefits to performing refactoring, you can get management support.

Once you have a roadmap and management support, develop a series of steps (also called a plan) that you need to take to get to this desired state. It may be a good idea to put together a steering committee that maintains the roadmap, trains and educates the development teams on the roadmap, and periodically reviews changes for architectural integrity.

Roadmaps are really useful, and perhaps the 13th question on the Joel Test should be "Do you have a roadmap?"

Here is a video of the first hour of a recent Red Hat Linux roadmap session.

share|improve this answer

protected by maple_shaft Feb 25 '13 at 16:19

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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