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?

  • 19
    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
  • 3
    Has anyone noticed that this has been the top question on SE all day. – msarchet Feb 24 '11 at 20:26
  • +1 for "...spend hours changing UI layout..." I fall into that trap too far too often. – 7wp Feb 25 '11 at 17:56

53 Answers 53


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.

  • 6
    I hate it when architecture astronauts do that! – ozz Feb 24 '11 at 18:19
  • 13
    Oh, the joy of metafactoryfactories :( – user1249 Feb 25 '11 at 8:43
  • +1 "A study of great designers found that they were all good at anticipating change" (Code Complete 2). It's good to be able to tell what sorts of change are likely. Then you can decide whether there's anything to be gained by solving the more general case early on - whether it would save time later. Sometimes it's not worth it, it would be just as easy to modify the code later. – MarkJ Feb 25 '11 at 12:27
  • 1
    Have you heard about YAGNI (You Ain't Gonna Need It) Principle? – Oscar Mederos Feb 27 '11 at 10:47
  • 1
    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

"We will come back to this and fix it later. We just need it working now!"

  • 16
    This is the absolute devil. – alesplin Feb 24 '11 at 22:47
  • 6
    I'd give you +100 for this if I could. "Later" NEVER HAPPENS. Do stuff right the first time or not at all. – quickly_now Feb 25 '11 at 2:27
  • 12
    isn't this the complement of spending hours refactoring bad code? We can divide the world in to programmers who "will fix it later" but don't, and programmers who try to get it right the first time then spend hours "refactoring bad code". – Мסž Feb 25 '11 at 4:11
  • 6
    re-phrase this to " We will come back and fix this next iteration " and it sounds so much more structured – Chris S Feb 25 '11 at 11:11
  • 4
    You must do this. If you spend all your time making it perfect it'll never ship. Finish the project, then polish it. – Zan Lynx Feb 25 '11 at 21:54

The deadline is soooooo far away, I have more than enough time to do it, so why not spend a little time surfing the web?

  • 72
    replace "web" with "programmers.stackexchange.com" :) – davidhaskins Feb 24 '11 at 15:38
  • 1
    Is there anything else on the web worth reading? I had forgotten there was anything else! – James McLeod Feb 24 '11 at 15:45
  • 3
    aka 'Damn you, Minecraft' – johnc Feb 25 '11 at 0:08
  • 1
    @david, that's just the starting point on the web - question is how far you get... – user1249 Feb 25 '11 at 8:42
  • Id' say, this is not so valid anymore due to Agile. – vartec Feb 25 '11 at 10:04

"This is just throw-away proof-of-concept code. Once they like it, I'll really make it good."

  • 13
    This is called Rapid Application Development; and it never works in a business environment. :) – John Kraft Feb 24 '11 at 15:40
  • 12
    It's funny that for me it's the other way around—I just can't make myself write throw-away code even when it is exactly what is required. – Dan Feb 24 '11 at 16:19
  • 6
    I work in finance and RAD is still going strong, especially VBA/Excel stuff. There is a knack to it though, RAD does not have to mean sloppy. – Ian Feb 24 '11 at 17:00
  • 5
    And sometimes the application you spent two years perfecting winds up being throw-away code because someone higher up the ladder decided "oh, we can't do that" or some other version of "never mind". – PSU Feb 24 '11 at 18:02
  • 12
    This. Me: "This is just my proof-of-concept. If you like it, we'll write the production version." Manager: "Your version works, let's ship it!" Me: "Well it doesn't cover all the use ca...you already shipped, didn't you?" – user4051 Feb 25 '11 at 11:43
  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.
  • 1
    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
  • 2
    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
  • @quickly_now Cutting off the net probably works for mundane tasks such as data entry or routine fixes, where you don't need to look anything up. For many out-of-ordinary things (e.g. looking up API docs / example code), Google is your friend -- it takes 5x more time to figure it out on your own. Also, if people are not motivated and want to be distracted, they'll find ways. – dbkk Feb 26 '11 at 1:12
  • @dbkk - yes up to a point. It was all in Ada, there were no API's to look up, it was on specialised hardware, and national securoty classified. Putting unclassified internet connected machines into that environment was a security nightmare as well. – quickly_now Feb 26 '11 at 4:17

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

  • 6
    Sometimes the existing frameworks and libraries are marked Verboten in big red letters by IT legal. – Christopher Mahan Feb 24 '11 at 17:09
  • 22
    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
  • "but it'll only take a week to write and our framework will do exactly what we want, the free one online one is probably full of bugs" – Мסž Feb 25 '11 at 4:13
  • 2
    @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
  • @Carson: +1 :-) – Macke Feb 26 '11 at 17:05

My recurrent demons: Premature optimization and overengineering.

And I still can't avoid them 100%...

  • 10
    +1 for overengineering. I once wrote an entire "configuration framework" with "config parameter adapters" for .ini files, XML files, database tables and network sockets (because everyone wants to host a configuration web service, right?) – TMN Feb 24 '11 at 16:53
  • 8
    Premature over-engineering? – Christopher Mahan Feb 24 '11 at 17:07
  • @Chris "premature overengineering" applies too though. It's been mentioned in other answers too. I know it's one my banes. – Matthew Scharley Feb 24 '11 at 22:40
  • How about premature over-optimized mega-engineering... – Newtopian Feb 25 '11 at 1:46
  • 4
    This is mine. I place the blame in management giving me free reign / far-future deadlines and not giving myself deadlines for specific components. – cthulhu Feb 25 '11 at 10:06

Overly optimistic estimates

When your manager is staring you down, and you feel the burning feeling to give a lower estimate than your gut is telling you... don't do it!

After all, your gut is probably too low already!

  • 13
    When they ask you if it will really take that long, just say yes and then sit in silence until they feel the awkwardness... – PeterAllenWebb Feb 25 '11 at 0:39
  • 4
    My college professor once told me to, "Figure out your best estimate, then double it." It's worked for me so far. – zzzzBov Feb 25 '11 at 1:39
  • 2
    Alternatively, try the SMBC approach. – detly Feb 25 '11 at 6:29
  • 4
    One of my old bosses tripled developer estimates, then negotiated down to double with the clients. Clients thought they got a deal, developers got the time they needed even if they didn't know it. Win-win! – DaveE Feb 26 '11 at 1:11
  • 2
    Evidence-based scheduling might help with this problem: joelonsoftware.com/items/2007/10/26.html – Rei Miyasaka Feb 26 '11 at 11:43

To use a technology/tool/language in your project purely because you had just learned it.

To try to prove how good a developer you are.

To consider code you've written to be yours.

  • If I could only upvote it each time I did so. Luckily, half of the solutions turned out to be pretty good. Half didn't. – Dan Feb 24 '11 at 15:29
  • Or one that you haven't learned at all yet. Just don't forget to strap on your spurs cause it's gonna be a long ride. – Evan Plaice Mar 18 '11 at 13:08

I'll just take a break and look at stackoverflow.com ;)

  • 2
    I always love when stackoverflow is the answer to one of these questions – Bill Leeper Feb 26 '11 at 16:30

The very worst temptation:

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

Guess what, it does hurt. :)


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

Forgetting that writing code is the last resort for solving a problem.

  • +1 I thought you were leaning in the direction of surfing the orbit architecting until I read the article. Good stuff... – Evan Plaice Mar 18 '11 at 13:16

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?

  • Leaving the spec unfrozen and open as a concession because the first PM (who was now fired) knew nothing about software development and designed a completely unrealistic release schedule. Worst idea ever. – Evan Plaice Mar 18 '11 at 13:16
  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.


  • +1'ed this answer, but I found it a bit difficult to read. I don't really understand the context of the first 9 points. Would you mind clarifying? Still, nice job. – user39685 Jan 17 '13 at 22:57
  • @MattFenwick Hi there, thank you for your +1. Points 1-5 usually applied in the scenario of creating a product to sell, though you can also apply it to scenarios where your tendency to find the best answer leads you to research extensively on prior art. E.g., in research. – Kim Stacks Jan 19 '13 at 1:00
  • Points 6-9 pertain more to the neurotic tendencies of a programmer. I read somewhere (can't find it) that a designer would always approach any problem with a design solution; a marketer with a marketing solution; and a programmer with a code solution. Yes, the dreaded "When you have a golden hammer, all you see are nails syndrome". THis is particular evident in point 6) Solving a productivity problem with more programming – Kim Stacks Jan 19 '13 at 1:02
  • @MattFenwick sorry if you got confused with my name. I changed my nickname after writing this answer. I see that your background is more in research. My answer derives largely from my experience of developing solutions to sell. But I am sure, there are certain similarities between my line of work and yours since we both do programming. – Kim Stacks Jan 19 '13 at 1:05

A couple of beers will help me work better and longer.

  • 11
    Wait...you mean it doesn't? (xkcd.com/323) – Craige Feb 24 '11 at 16:15
  • 4
    @Craige: after 21 years of experience with drinking and 20 years of experience as a professional software engineer, I am still working on the calibration part. – Adam Crossland Feb 24 '11 at 16:17
  • 4
    @adam, it took you a year of drinking to become an engineer? – user1249 Feb 25 '11 at 8:43
  • 17
    Coding while drinking beer helps you create wildly popular social networks that'll worth billions in a couple of years. It's true, I saw this in a movie. – janosrusiczki Feb 25 '11 at 9:36
  • 1
    @Kitsched: Yep! Especially if you have someone else's pre-existing design to rip off. – Mason Wheeler Feb 25 '11 at 22:39

"Yeah, I can refactor this gigantic mess of 2000 lines spaghetti in one day..."

  • 13
    Alternatively: "the new guy [who knows absolutely nothing about the software or the structure of its code] is doing nothing, he can fix it". Bonus points when the guy has never even used the language in which the code is written. – wildpeaks Feb 24 '11 at 16:15

"I can get by without a test for that. It's too hard to test."

and it's evil brother,

"I must have a test for that, no matter how hard the test is to write or understand."

  • 2
    If a test is hard to write, you might not be programming it right :) – Merlyn Morgan-Graham Feb 25 '11 at 6:39
  • 2
    @Merylyn Morgan-Graham, quite true. But there are some areas, such as concurrency, that is just plain harder to test. – Wayne Conrad Feb 25 '11 at 13:21
  • 1
    @Merlyn: If you find yourself writing an instruction simulator so that you can force a context switch in just the right places, then you've probably gone way too far in your concurrency testing. :) – Zan Lynx Sep 30 '11 at 21:11
  • 1
    @Zan: I agree - at the point that is required, I'd push back on devs and attempt to get them to refactor their code and let me insert mocks. Tho I work against high level langauges where we look at Big-O, optimize bottlenecks, need to think about concurrency mostly for integrity of data rather than raw speed, and ship (and often none of those because it's just plain fast enough out of the box). – Merlyn Morgan-Graham Nov 6 '11 at 18:39

Procrastination and optimistic task estimation are my biggest sins.

Stretching, push-ups or pull-ups (or any other physical exercise) for the first one and pessimistic mood before giving estimation for the second.

  • Clarification... By, "optimistic task estimation" you mean 'shit's easy syndrome' right? :) – Evan Plaice Mar 18 '11 at 16:56
  • @Evan Plaice - exactly. Like "oh, it's so trivial" and then googling every letter of your code after you started actual coding. – Nikita Barsukov Mar 18 '11 at 20:43

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

  • 2
    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
  • Working on open source helps this tendency. I've personally stared at patches before cross-eyed, then gone ahead and wrote my own implementation only to realize that it was near identical to the patch (even after improving/refactoring my code). It's funny how that works. – Evan Plaice Mar 18 '11 at 17:00

One massively harmful temptation that the project I am on has suffered from is the 'Inner Platform Effect'. This is an approach that Architects, who have now long gone, have set down in their infinite wisdom which has created a project that generates around 20 million dollars per year but costs 60 million to update and maintain (rough figures obviously but this is the magnitude of the problem).


NIH - Not Invented Here

I have a really hard time giving third-party solutions a fair chance. Everyone should be naturally skeptical of third-party solutions that weren't tailor-made for them, but I have a hard time being 100% objective about it.

The time savings can be so huge that even if 9 times out of 10 the third-party solution should be avoided, I need to be objective enough to realize the one that will work.

  • 1
    I see your point and have to live with it all the time. I am squarely in the opposite opinion sometimes to a point where it would deserve an answer right next to yours. However I have a hard time believing that I can do better in a week than a group of experts on the matter that have been at it for years. Of course you have to ensure that the people behind said third party are indeed experts. Good investigation on the surrounding environment of the component greatly helped choosing correctly between adopting or coding. – Newtopian Feb 25 '11 at 2:04
  • 1
    @Newtopian the "correct" way is definitely somewhere in the middle. My issue with third party libraries is not whether I can do better than a team of experts with months or weeks of time, but that I rarely, maybe never find a library that is exactly what we need. There's always adapting to do, and then I often find myself and others spending as much time wrestling with that as writing a solution that is exactly what we need. – Nicole Feb 25 '11 at 2:07
  • Myself coming from the opposite end of the spectrum was just curious to know how you managed to try and achieve this "just middle" if at all. Also was curious as to what makes you not want to use third parties in trying to understand what makes me over use them as I am sure both are equally harmful to productivity. – Newtopian Feb 25 '11 at 3:39
  • @Newtopian does my explanation above make sense as to why? My attempt to try to achieve the middle is simple to be more objective when evaluating and looking for third-party solutions. – Nicole Feb 25 '11 at 3:43

Designing, coding and or unit testing against supplied "sample data" instead of analyzing a copy of the customers actual database. The deadline was short and they kept saying it's coming but it never did. When it was deployed the explosion was spectacular. Really, who would have expected a customer to have 3 parent customers.

I will never again start a project until I have a copy of the real data.

  • If there is no product yet, will there be any data to copy? – Svish Feb 26 '11 at 12:10
  • If there is no data, there is always paper. Company records would help here too. – Dan Feb 28 '11 at 9:25

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

closely related to

The Plugin Fetish

  • 2
    I always seem to be able to find the library that "does it" My problem is often getting them to work as advertised. :( – Ben L Feb 25 '11 at 13:59
  • Easy to find a library - Hard to find a library that has good unit tests built in – Dan Feb 28 '11 at 9:27

Perfectionism kills; probably the greatest reason projects don't succeed.

  • I guess it's possible that this is true, but I have never been on a project that failed, or was even late, for this reason. – PeterAllenWebb Feb 25 '11 at 0:45
  • Depends how you define perfection and what level of it you're aiming for. – Svish Feb 26 '11 at 12:11

Well, sometimes programming drives me to the bottle.


Rewriting instead of refactoring.

  • Agree. If you're willing to commit to the amount of effort required for a re-write, it is almost ALWAYS better to refactor. It will still take longer than you thought, but you're doing the refactoring incrementally, right? You can stop before it's "perfect". – PeterAllenWebb Feb 25 '11 at 0:51
  • 1
    as a corollary.... writing again elsewhere instead of re-factoring. Our code base has so many different implementations of the same things it's impossible to get any kind of consistency. – Newtopian Feb 25 '11 at 2:07

Thinking there has to be a better way to do this. I'm not going to settle for something that may be "good enough." I'm taking nothing less than perfection! Usually this is avoided by talking to others that may have a different perspective on a problem or seeing a solution from a different angle.


Automating everything to the point more time is spent on maintaining the tools than on actual work.

Solution: just like with code optimization, first find productivity bottlenecks and only after they are discovered, cure them with some good automation.

  • I can agree with this in principle, but I have never seen excessive automation in practice. Still, that could just be my experience. – PeterAllenWebb Feb 25 '11 at 0:52

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


We haven't gotten approval from the client yet but the deadline is approaching so here are some preliminary comps so that you can get started...

Later, after you've finished building the project to match the comps...

Oh, here's the client's revisions, they just want to change a few minor things*

(* major functionality is entirely different)

Then you keep refactoring your original code, based on the original flawed model instead of just starting from scratch because you're under the pressure of a short deadline and assume that those were the last revisions.

I get bit by this one all the time. It's hard to avoid as a web developer. My best advice is to push for more time so that you can make the changes the correct way.

  • 2
    Take on a policy where you don't start development until you have a client's signature. – Ben L Feb 24 '11 at 18:19
  • 1
    @Ben: If only that was under our control! – sevenseacat Feb 25 '11 at 1:15

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