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?

share

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.

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

53 Answers 53

up vote 67 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.

Update:

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

share
6  
I hate it when architecture astronauts do that! –  jmo21 Feb 24 '11 at 18:19
13  
Oh, the joy of metafactoryfactories :( –  user1249 Feb 25 '11 at 8:43
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

The very worst temptation:

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

Guess what, it does hurt. :)

goto

share
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

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

share
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

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

share
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

My recurrent demons: Premature optimization and overengineering.

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

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

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?

share
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

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.

share

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

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

Well, sometimes programming drives me to the bottle.

share

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

share
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. –  kitsched 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
  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.
share
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

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

share
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

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.

share

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

share

All of the others plus feature creep: "It would be really cool if it did this, and I know the customer will love it and would have put it in the spec if they'd thought of it". I try to avoid this by asking where in the real spec the requirement exists for this real cool feature.

Then again, I don't often get written specs.

share
  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

share

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

share
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

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

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

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.

share
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. –  NickC Feb 25 '11 at 2:07

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!

share
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

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.

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

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.

share

Rewriting instead of refactoring.

share
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

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.

share

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

share

"I have been assigned a feature that interfaces with [software/eg: sharepoint]. I should probably know everything there is to know about that software."

Then you spend weeks researching that product, when the feature could have been written and tested in a day or two. The hunger for knowledge has a dark underbelly. rawr

share
2  
Yup, but for me SharePoint is not the case here. On the opposite, I want to spend as little as possible of my time reading or learning about it. –  Dan Feb 24 '11 at 20:05

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.

share

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

share

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?

share

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