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.

Just curious, what kinds of temptations in programming turned out to be really harmful in your projects?

Like when you really feel the urge to do something and you believe it's going to benefit the project or else you just trick yourself into believing it is, and after a week you realize you haven't solved any real problems but instead created new ones or, in the best case, pleased your inner beast with no visible impact.

Personally, I find it very hard to not refactor bad code. I work with a lot of bad legacy code, and it takes some deep breaths to not touch it when I have no tests to prove my refactoring doesn't break anything.

Another demon for me in user interface, I can literally spend hours changing UI layout just because I enjoy doing it. Sometimes I tell myself I'm working on usability, but the truth is just I love moving buttons around.

What are your programming demons, and how do you avoid them?


locked by World Engineer Jun 15 '13 at 21:05

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

I find it humorous that nobody has been able to answer the second part of your question - "[and] how do you avoid them?". –  Craige Feb 24 '11 at 16:30
Has anyone noticed that this has been the top question on SE all day. –  msarchet Feb 24 '11 at 20:26

53 Answers 53

up vote 68 down vote accepted

Premature generalization is my big bugaboo; instead of solving the problem at hand first and waiting until there's an actual need to solve for the general case, I always go after the general case up front and wind up writing a ton of code that's more complex than it needs to be.


See "Sin #1 - Premature Generalization" for an in depth descripztion.

I hate it when architecture astronauts do that! –  Ozz Feb 24 '11 at 18:19
Oh, the joy of metafactoryfactories :( –  user1249 Feb 25 '11 at 8:43
Have you heard about YAGNI (You Ain't Gonna Need It) Principle? –  Oscar Mederos Feb 27 '11 at 10:47
This. I put the blame on the fact that creating pretty, generalized and re-usable code is very satisfying, especially if the problem itself isn't very challenging and/or is just a rehash of what you've done before. Case in point, generic CRUD database operations (UI, respond to user action, do something with a DB, thar). –  Cthulhu Mar 19 '11 at 21:23

Fixing a bug that's been bothering you because it is "so simple", but never telling QC and/or the customer.

These fixes always crash production.


"There must be a better solution to this."

And you end up thinking and thinking, and letting your mind drift off to a far away land until you realized you were gone for too long. It should be fine, but not when you have a deadline.


Falling prey to trying to build everything in-house, when there are existing frameworks and libraries.

Sometimes the existing frameworks and libraries are marked Verboten in big red letters by IT legal. –  Christopher Mahan Feb 24 '11 at 17:09
And of course, the opposite tempation: using an unfamiliar framework or library and assuming that it will do what you need and everything will go smoothly. –  Carson63000 Feb 24 '11 at 23:27
@Christopher: Then that'd be a good reason to reimplement (or find a different library with acceptable license). But too often the reason for reimplementing is just NIH… –  Donal Fellows Feb 25 '11 at 10:10

Using a language feature, an idiom, or a design pattern not because it is the best solution to the problem, but purely for the sake of using it.


The very worst temptation:

Oh, well.. I guess one dirty little trick/hack/fix isn't gonna hurt.

Guess what, it does hurt. :)


"Gateway fixes" –  Mark C Feb 24 '11 at 15:33
Using a goto statement will result in a raptor attack. –  Maxpm Feb 25 '11 at 16:25
@Maxpm: Good thinking! Included. –  Goran Jovic Feb 25 '11 at 16:32
@Mark C, what is a gateway fix? My gøøgle-fu is not good enough. –  user1249 Feb 25 '11 at 16:59
@Thorbjørn Ravn Andersen: en.wikipedia.org/wiki/Gateway_drug_theory –  Jimmy Feb 26 '11 at 0:24

Being "Perfect"

While avoiding getting it right the first time is a problem, it's not near as bad as an undying focus on perfection. Just get it done, there is no such thing as perfect, and if there is, it's purely temporal, or already been done and not worth the time to do again.

* Calculates the return value for humptyDumpty
* return int modifiedHumptyDumpty
function awesomeWayToCalculateSomething(int humptyDumpty) {

TODO: I need to document this properly.

Will _never_ happen


Cleverness. Of course, not always. Some cleverness and conciseness will make your code look very nice and maintainable. But just because you can do


instead of a couple of lines of if statements, doesn't mean you should.

Btw, yes I know there is a bit of redundancy in my example... If you even caught it yourself :)


What are your programming demons?

Apart from what some of others have mentioned.

Prioritization : Ignoring the high priority work with respect to project and working on other things in the project first because, they are more interesting!

How do you avoid them?

With a little more self discipline. Seriously, self discipline and self motivation to do the right thing helps to avoid most of these "demons".


"I'll comment/document this later"

it never happens, the author moves on, and then you find out that they don't comment their code when the job has been assigned to you.


Using a framework while not fully understanding it. But then again. a framework is only fully understood by it's creators (most of teh cases). I don't have a real solution for that item but trying to understand as much as possible from a framework.


To find a comfortable sofa to work or work lying in bed.


Doing countless hours of extra work for the company in my off time only to find out "that wasn't the direction they were looking for."


Someone said premature generalization, but premature specialization can be just as bad. With premature generalization, you can get a software that works for 50% of the cases, but premature specialization can work for 5%, or none. In the end, management would rather have 50% than 5%.


Spending too long tweaking the editor. Trying to find the best font and colorscheme for programming.


Writing new code after code-freeze date.

Code freeze date must be set in stone. Any new code written after it must be moved to the future release, as it may require all kinds of regression testing.


"it's only the pilot, so there's no need to make it easy to maintain or expand".

In my experience it's more common to see the pilot enter production and the product it's supposed to be a pilot for to be scrapped than for the pilot to be scrapped and the actual product developed to production ready status.


over committing yourself to avoid in-house development, 90% of a wheel is not better than inventing one.


I think I have it in my head that enums are a lot more useful than they really are in Java. I tend to try and do too much with them, and then get bogged down because they don't really support polymorphism.


Very complete list: anti-patterns.


"It is much 'easier' to reimplement the functionality from the scratch than to understand the existing code."

Yes, c2.com/cgi/wiki?RewriteCodeFromScratch claims that this is one of the "Things You Should Never Do". –  David Cary Feb 26 '11 at 22:54

To start attacking a new project, without understanding it, and I usually avoid this by researching a little about the project domain before I actually begin to work with it, just to have a good starting point, and to prove the project is more complex than I initially through it was.

I also have the problem that I like to move around with buttons, they are so cool!! But maybe that's because I'm doing multimedia systems and user interface design... So for me the solution to this problem, was to actually include that in my curriculum and study something about it, so that I have a valid excuse if anyone sees me playing with the UI a lot. (And that includes putting the background green, the text orange, and the icons with a lot of yellow.)

  1. Add more features

  2. The competition has this feature. So this is a must have feature hence more programming than analyze strategy, positioning, etc.

  3. The competition does NOT have this feature. So this is a differentiating feature hence more programming than analyze strategy, positioning, etc.

  4. Solving a business problem with more programming. eg, better expertise in administering the linux server your website is hosted on cannot be gained via programming more features. Sometimes you just have to learn how to fix the problem rather than re-coding the whole thing into C#.Net

  5. Solving a marketing problem with more programming. eg, abusing Seth Godin's purple cow concept that you are indirectly solving a marketing problem by programming more features into your product to make it a "purple cow". Sometimes, its just a mutant monster.

  6. Solving a productivity problem with more programming arguing to yourself that the time spent writing this script will be saved back in hours in future instead of actually programming real important stuff

  7. Planning to code but not yet coding because you want to "get it right"

  8. Coding a dirty version and promising that you will "make it better later" but never went back to "make it better"

  9. Not doing a mockup or a sitemap because it is "so troublesome". I can just screenshot competitor's pages for mockups and freehand draw sitemap "later" which is never. And then just go straight into programming the first page i visualize in my mind.

Confession: I have personally made mistakes 1, 3, 7, 8. I have also made 2, 4, 5, 6 but often deluded to myself that i did not.

I am currently remedying 9.

EDIT Didn't realise the question requires us to put in solutions.

1) Add more features Just don't do it. Work with your business, marketing, founders, advisors, etc and strip your application to just 1 thing.

Go read about twitter, Groupon, etc about how they just strip things down to just 1 thing which led to their success.

If you think it only works if you want to build big companies, think again. Ctrl+F for this line "The more features I add to the software, the worse it sells. (This is, needless to say, highly unintuitive to most software developers.)" in this link

2) The competition has this feature. So this is a must have feature

See solution 1

3) The competition does NOT have this feature. So this is a differentiating feature

See solution 1

4)Solving a business problem with more programming.

If you need to hire someone to teach you, give consultation, or do it for you and then document how he did it, so that you can do it yourself next time. JUST DO IT!! Do not rewrite code, do not pass GO, do not collect $200.

5) Solving a marketing problem with more programming.

If people don't understand what you are selling, it IS a marketing problem. Go back to solution 1 and pivot.

6) Solving a productivity problem with more programming


Wait until you feel that your productivity has suffered from a particular productivity problem for a period longer than 2 weeks and it reasonably will happen for another 2 weeks.

Now, evaluate the amount of time spent to program a script to solve this problem. Remember to take your worst estimate and multiply by 2.

Multiply your estimate by your hourly rate.

Now review alternate solutions: outsource, buy a solution off-the-shelf, don't do anything about it, etc

Choose the most cost-effective solution.

Stick to it.

7) Planning to code but not yet coding because you want to "get it right"

Go exercise. You will feel a rush of endorphins that will motivate your ass and make you plan to act. I know this because I just did 5x5 benchpresses and 5x5 squats.

8) Coding a dirty version and promising that you will "make it better later" but never went back to "make it better"

Set up a tickler file system in GTD. and aggressively follow up. Follow up all promises to yourself and others.

9) Not doing a mockup or a sitemap because it is "so troublesome".

Go spend USD75 on a balsamiq mockups desktop edition. I know this because i bought it 3 weeks ago. It has made me redo my mockups because i feel like an artist, architect and visionary all in 1 even though my drawing in real world sucks. The font used in balsamiq unconsciously reminds you that this is just a mockup, not set in stone which helps you in RAD.



My brain's worn out from this project. I'll just take a quick break on this short side project to rejuvenate it.

I do this all the time... should probably stop. –  Ben Feb 25 '11 at 14:07

The There is gotta be a library that does that somewhere syndrome.

closely related to

The Plugin Fetish

I always seem to be able to find the library that "does it" My problem is often getting them to work as advertised. :( –  Ben Feb 25 '11 at 13:59

What are your programming demons,

Everything that's already been mentioned, particularly the urge to refactor like mad.

and how do you avoid them?

Before starting any nontrivial edit, take my hands off the keyboard for 5 seconds and quickly weigh possible outcomes of changing vs. leaving it. Then again before committing, weigh the same consequences for about a minute.


Feature Creep

Make a plan, stick to it, and deploy. And then go back and add the stuff that people are asking for.

I have seen this over and over. You sit down, work out the design, and start coding. The users hear some confused nonsense about their favorite feature being "missing" and they start lobbying for it. Your boss demands that you add it at the 11th hour, it fouls the deployment, it introduces bugs everywhere, and 3 months later, once everyone has settled down, you're asked to remove it, because no one can figure out why you put that crappy retro feature in in the first place! Couldn't you tell that the rest of the design made it pointless?


To answer the question about avoiding them: Familiarise yourself with Anti-Patterns so you can call them out when you recognise them.

  1. Refactoring part of the code a few day before the release.
  2. Internet: The biggest distraction of all.
  3. New technology: Can't keep my hands off new technology.
  4. Optimize: Optimize, Optimize. .. and more Optimize
  5. Perfection: Never been satisfied with the code.
  6. TODO: Lack of time todos that never will be done.
  7. Time estimation: Many PMs doesn't take this as "estimate". They take as fact.
  8. Promises: Giving too many promises.
Once worked on a project that had 100 people in a big room, and only 2 shared PCs had internet. Productivity was very high. The management gave everyone internet and wondered why work output halved. –  quickly_now Feb 25 '11 at 2:29
Regarding Time Estimation... so many managers take it as starting point in negotiation (like bargaining for a price). Ones who take it as a fact misguided but actually above average... –  dbkk Feb 25 '11 at 6:45

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