97
votes

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?

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

53 Answers 53

67
votes

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.

Update:

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

7
  • 6
    I hate it when architecture astronauts do that!
    – ozz
    Feb 24, 2011 at 18:19
  • 13
    Oh, the joy of metafactoryfactories :(
    – user1249
    Feb 25, 2011 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, 2011 at 12:27
  • 1
    Have you heard about YAGNI (You Ain't Gonna Need It) Principle? Feb 27, 2011 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, 2011 at 21:23
197
votes

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

17
  • 16
    This is the absolute devil.
    – alesplin
    Feb 24, 2011 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. Feb 25, 2011 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, 2011 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, 2011 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, 2011 at 21:54
105
votes

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?

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

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

9
  • 13
    This is called Rapid Application Development; and it never works in a business environment. :)
    – John Kraft
    Feb 24, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 11:43
74
votes
  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.
4
  • 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. Feb 25, 2011 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, 2011 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, 2011 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. Feb 26, 2011 at 4:17
55
votes

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

8
  • 6
    Sometimes the existing frameworks and libraries are marked Verboten in big red letters by IT legal. Feb 24, 2011 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. Feb 24, 2011 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, 2011 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… Feb 25, 2011 at 10:10
  • @Carson: +1 :-)
    – Macke
    Feb 26, 2011 at 17:05
48
votes

My recurrent demons: Premature optimization and overengineering.

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

5
  • 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, 2011 at 16:53
  • 8
    Premature over-engineering? Feb 24, 2011 at 17:07
  • @Chris "premature overengineering" applies too though. It's been mentioned in other answers too. I know it's one my banes. Feb 24, 2011 at 22:40
  • How about premature over-optimized mega-engineering...
    – Newtopian
    Feb 25, 2011 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, 2011 at 10:06
46
votes

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!

6
  • 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... Feb 25, 2011 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, 2011 at 1:39
  • 2
    Alternatively, try the SMBC approach.
    – detly
    Feb 25, 2011 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, 2011 at 1:11
  • 2
    Evidence-based scheduling might help with this problem: joelonsoftware.com/items/2007/10/26.html Feb 26, 2011 at 11:43
33
votes

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.

2
  • 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, 2011 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. Mar 18, 2011 at 13:08
32
votes

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

1
  • 2
    I always love when stackoverflow is the answer to one of these questions Feb 26, 2011 at 16:30
31
votes

The very worst temptation:

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

Guess what, it does hurt. :)

goto

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

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

1
  • +1 I thought you were leaning in the direction of surfing the orbit architecting until I read the article. Good stuff... Mar 18, 2011 at 13:16
23
votes

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?

1
  • 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. Mar 18, 2011 at 13:16
20
votes
  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.

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.

End EDIT

4
  • +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, 2013 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, 2013 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, 2013 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, 2013 at 1:05
17
votes

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

10
  • 11
    Wait...you mean it doesn't? (xkcd.com/323)
    – Craige
    Feb 24, 2011 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. Feb 24, 2011 at 16:17
  • 4
    @adam, it took you a year of drinking to become an engineer?
    – user1249
    Feb 25, 2011 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. Feb 25, 2011 at 9:36
  • 1
    @Kitsched: Yep! Especially if you have someone else's pre-existing design to rip off. Feb 25, 2011 at 22:39
16
votes

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

1
  • 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, 2011 at 16:15
16
votes

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

4
  • 2
    If a test is hard to write, you might not be programming it right :) Feb 25, 2011 at 6:39
  • 2
    @Merylyn Morgan-Graham, quite true. But there are some areas, such as concurrency, that is just plain harder to test. Feb 25, 2011 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, 2011 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). Nov 6, 2011 at 18:39
15
votes

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.

2
  • Clarification... By, "optimistic task estimation" you mean 'shit's easy syndrome' right? :) Mar 18, 2011 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. Mar 18, 2011 at 20:43
13
votes

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

2
  • 2
    Yes, c2.com/cgi/wiki?RewriteCodeFromScratch claims that this is one of the "Things You Should Never Do".
    – David Cary
    Feb 26, 2011 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. Mar 18, 2011 at 17:00
10
votes

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

10
votes

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.

4
  • 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, 2011 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, 2011 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, 2011 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, 2011 at 3:43
9
votes

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.

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

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

closely related to

The Plugin Fetish

2
  • 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, 2011 at 13:59
  • Easy to find a library - Hard to find a library that has good unit tests built in
    – Dan
    Feb 28, 2011 at 9:27
8
votes

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

2
  • 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. Feb 25, 2011 at 0:45
  • Depends how you define perfection and what level of it you're aiming for.
    – Svish
    Feb 26, 2011 at 12:11
7
votes

Well, sometimes programming drives me to the bottle.

7
votes

Rewriting instead of refactoring.

2
  • 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". Feb 25, 2011 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, 2011 at 2:07
6
votes

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.

5
votes

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.

1
  • I can agree with this in principle, but I have never seen excessive automation in practice. Still, that could just be my experience. Feb 25, 2011 at 0:52
4
votes

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

3
votes

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
  • 2
    Take on a policy where you don't start development until you have a client's signature.
    – Ben L
    Feb 24, 2011 at 18:19
  • 1
    @Ben: If only that was under our control! Feb 25, 2011 at 1:15

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