Harmful temptations in programming

Question

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?

Answer 1

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

Answer 2

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?

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

My recurrent demons: Premature optimization and overengineering.

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

Answer 8

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!

Answer 9

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.

Answer 10

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

Answer 11

The very worst temptation:

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

Guess what, it does hurt. :)

Answer 12

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

Answer 13

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?

Answer 14

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

Answer 15

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

Answer 16

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

Answer 17

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

Answer 18

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.

Answer 19

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

Answer 20

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

Answer 21

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.

Answer 22

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.

Answer 23

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

closely related to

The Plugin Fetish

Answer 24

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

Answer 25

Well, sometimes programming drives me to the bottle.

Answer 26

Rewriting instead of refactoring.

Answer 27

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.

Answer 28

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.

Answer 29

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

Answer 30

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.

Answer 31

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

Answer 32

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

x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;

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

Answer 33

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

Answer 34

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.

Answer 35

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

Answer 36

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.

Answer 37

"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

Answer 38

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

Answer 39

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

Answer 40

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

Answer 41

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.

Answer 42

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

Answer 43

Very complete list: anti-patterns.

Answer 44

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.

Answer 45

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

Answer 46

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

Answer 47

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

Answer 48

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

Answer 49

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.

Answer 50

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

TODO: I need to document this properly.

Will _never_ happen

Answer 51

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.

Answer 52

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.

Answer 53

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.