97

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?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Dan
  • 2,902
  • 1
  • 25
  • 30
  • 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 Answers53

197

"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
  • I have even filed "fix this later" cases in case-tracking systems. They get pushed to later development cycles time after time. In any one of those given cycles it makes sense to push it until later. But the total drag of the problem over a dozen cycles is more than the cost of fixing it. What can you do? – PeterAllenWebb Feb 25 '11 at 00:57
  • 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 02: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 04:11
  • 1
    IMHO, this is a bit almost a corollary to premature optimiation – Everyone Feb 25 '11 at 05:19
  • I've found that the 'fix this later' technique is the absolute killer! I've written applications like that several times, and I usually find myself giving up on all hopes of improving the code, and usually start over! It can turn into an absolute nightmare – bbosak Feb 25 '11 at 05:31
  • @moz - I think the take-home point is that it's the middle ground that is optimal: write good code *from now on*. Fix old code when there's time. Either extreme is counter-productive. – detly Feb 25 '11 at 06:26
  • 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
  • @Chris S - depends if you work in iterations! ;-) –  Feb 25 '11 at 11:12
  • 2
    +1. You can avoid these problems with some education. It may be helpful to explain it to management people in terms of [technical debt](http://en.wikipedia.org/wiki/Technical_debt). You can point to articles written by various gurus: [Martin Fowler](http://www.martinfowler.com/bliki/TechnicalDebt.html), [Steve McConnell](http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx)... – MarkJ Feb 25 '11 at 12:20
  • 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
  • 4
    @Zan There is a good and healthy balance between making a "perfect" product that never ships and making a garbage product that ships ultra-fast. Problem with making a garbage and fast shipped product first is that your next releases will suffer from it. As MarkJ linked to above here, it's called Technical Dept. – Svish Feb 26 '11 at 11:48
  • +1 It's good enough, we'll worry about it later. Package and ship out! – JustinC Mar 04 '11 at 20:20
  • Temporary is just a phase before permanent – Eric Mar 04 '11 at 21:11
  • In my environment, there are two major sites. Either one can originate a request for code, but the code will end up being deployed to both. They're different enough that you have to tune the code a bit for each...The practical result is that one site always gets beta code, and the other site always gets polished code, but then we never have time to migrate the polish back to the other site. I have had a number of people complain about our "uneven" code, or alternately, people at one site complaining about a program that people at the other site think is perfect. – Satanicpuppy Mar 18 '11 at 13:40
  • This pretty much sums up how security works on the internet. – aaaaaaaaaaaa Apr 19 '11 at 15:07
  • It's always too tricky to fix the things later. – faceclean Aug 12 '11 at 22:26
105

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?

user281377
  • 28,352
  • 5
  • 75
  • 130
103

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

davidhaskins
  • 2,158
  • 2
  • 18
  • 26
  • 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
  • @gaearon: everyone writes throw-away code - considering hello-world, did you put the constant string in resource file? did you try-catch? did you log... If not, it is a throw-away code. As long as we need to balance between making progress and perfection, we do throw-away coding from time to time. – Codism Feb 24 '11 at 17:07
  • 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
  • 1
    Every time this happens 'wow you did feature A fast, let's move onto feature B!' 'no, but I need to.... argh!' – sevenseacat Feb 25 '11 at 01:13
  • well some business still make a living out of RAD... The company I work for has 1.5M loc of just that... rapidly developed prototypes that, once presented to management were immediately sold to customers. Of course for every month of development comes inevitable 2 months of complete nightmare once it hits customers. We just came out of a 18 months development for the next features... sight – Newtopian Feb 25 '11 at 01:43
  • 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?" –  Feb 25 '11 at 11:43
  • @Ian it's also a different context, the small excel, vba thing you build are not to be used forever and by thousands of customers who pay for it. Or are they? – Stephane Feb 27 '11 at 08:57
74
  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.
John Topley
  • 103
  • 2
Amir Rezaei
  • 10,938
  • 6
  • 61
  • 86
  • 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 02: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 06: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 01: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 04:17
67

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.

k3b
  • 7,488
  • 1
  • 18
  • 31
John Bode
  • 10,826
  • 1
  • 31
  • 43
  • 6
    I hate it when architecture astronauts do that! – ozz Feb 24 '11 at 18:19
  • 13
    Oh, the joy of metafactoryfactories :( –  Feb 25 '11 at 08: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
  • I find this to be the biggest fault of programmers. We as a group tend to think that we need an abstract class and make things infinitely flexible in version 1. Save that for when you actually need it. If you have good testing (another topic) you should be able to refactor at will. – Bill Leeper Feb 26 '11 at 16:30
  • 1
    Have you heard about [YAGNI (You Ain't Gonna Need It)](http://en.wikipedia.org/wiki/You_ain't_gonna_need_it) Principle? – Oscar Mederos Feb 27 '11 at 10:47
  • I think I certainly fall into this category as I have recently discovered patterns. Pattern Fever, I think one of the books named it. I know it's bad writing needlessly complex code but the hard part is ignoring the fun of it. I guess what I really need to learn next is to assess *when* to generalize, or rather, force myself to calm down and think at the *current needs* and not run away and make every step extendable in every manner possible. :) – Statement Mar 12 '11 at 23:14
  • 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
55

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

Nathan Baulch
  • 101
  • 2
FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • 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 04: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
  • I've done this sort of thing, either because it was a personal project and it was cheaper to do my own, or to learn something, or because I was told to do so. (I've also been in situations where there were no satisfactory existing frameworks or libraries.) – David Thornley Mar 04 '11 at 14:58
  • @David Thornley: Doing it as a learning activity is fine. Doing it because it's cheaper does not *always* result in it being cheaper if it takes too much longer (at least in a corporate environment - for personal projects with no budget this is fine). – FrustratedWithFormsDesigner Mar 04 '11 at 15:01
  • and more often entire existing products... – jwenting Mar 17 '11 at 16:05
48

My recurrent demons: Premature optimization and overengineering.

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

Tomas Narros
  • 221
  • 2
  • 9
  • 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](http://programmers.stackexchange.com/questions/51437/harmful-temptations-in-programming/51523#51523) 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 01: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
46

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!

Community
  • 1
Nicole
  • 28,111
  • 12
  • 95
  • 143
  • 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 00: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 01:39
  • 2
    Alternatively, try the [SMBC approach](http://www.smbc-comics.com/index.php?db=comics&id=2133#comic). – detly Feb 25 '11 at 06: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 01:11
  • 2
    Evidence-based scheduling might help with this problem: http://www.joelonsoftware.com/items/2007/10/26.html – Rei Miyasaka Feb 26 '11 at 11:43
  • always double your gut feeling to get your estimate, then double it again before giving it to any manager or commercial guy (because they'll half it again before putting it in any of their documents). – jwenting Mar 17 '11 at 16:12
33

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.

biziclop
  • 3,351
  • 21
  • 22
  • 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
32

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

Richard Miskin
  • 205
  • 3
  • 9
31

The very worst temptation:

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

Guess what, it does hurt. :)

goto

Community
  • 1
Goran Jovic
  • 2,748
  • 23
  • 28
25

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

Dan
  • 2,902
  • 1
  • 25
  • 30
  • +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
23

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?

Satanicpuppy
  • 6,210
  • 24
  • 28
  • 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
20

  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

Kim Stacks
  • 279
  • 2
  • 8
  • +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. –  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 01: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 01: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 01:05
17

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

Adam Crossland
  • 9,688
  • 2
  • 35
  • 46
  • 11
    Wait...you mean it doesn't? (http://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
  • @Adam > http://xkcd.com/323/ – gingerbreadboy Feb 24 '11 at 18:44
  • @Adam Crossland, the problem is that you wrote *couple*. **A** beer can help you work better and longer, but it's a steep curve on the law of diminishing returns. – zzzzBov Feb 25 '11 at 01:38
  • 4
    @adam, it took you a year of drinking to become an engineer? –  Feb 25 '11 at 08: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 09:36
  • @Thorbjorn: I was deeply committed to becoming the best engineer that I possibly could, so I took the step of setting aside a whole year of my life for drinking to prepare myself. It also happened to be a convenient way to ride out a pretty bad job market. – Adam Crossland Feb 25 '11 at 15:07
  • @adam, I am glad to know that there are people on stackexchange who are willing to make large, personal sacrifices to become the very best :) –  Feb 25 '11 at 16:58
  • Also the "better and longer" does not tell that it is the one _after_ the other :-o –  Feb 25 '11 at 17:05
  • 1
    @Kitsched: Yep! Especially if you have someone else's pre-existing design to rip off. – Mason Wheeler Feb 25 '11 at 22:39
16

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

Hila
  • 1,332
  • 8
  • 15
  • 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
16

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

Wayne Conrad
  • 1,118
  • 10
  • 20
  • 2
    If a test is hard to write, you might not be programming it right :) – Merlyn Morgan-Graham Feb 25 '11 at 06: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 06 '11 at 18:39
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.

Nikita Barsukov
  • 1,265
  • 1
  • 9
  • 12
13

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

k3b
  • 7,488
  • 1
  • 18
  • 31
  • 2
    Yes, http://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
10

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

AlexC
  • 1,337
  • 1
  • 11
  • 18
10

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.

Community
  • 1
Nicole
  • 28,111
  • 12
  • 95
  • 143
  • 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 02: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 02: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 03: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 03:43
9

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.

dwidel
  • 101
  • 2
9

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

closely related to

The Plugin Fetish

Newtopian
  • 7,201
  • 3
  • 35
  • 52
  • 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 09:27
8

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

Naftuli Kay
  • 1,601
  • 2
  • 16
  • 23
7

Well, sometimes programming drives me to the bottle.

mipadi
  • 7,493
  • 36
  • 35
7

Rewriting instead of refactoring.

Dave O.
  • 320
  • 1
  • 9
  • 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 00: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 02:07
6

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.

JB King
  • 16,795
  • 1
  • 40
  • 76
5

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.

Dan
  • 2,902
  • 1
  • 25
  • 30
  • 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 00:52
4

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

Mahesh Velaga
  • 151
  • 4
3

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.

travis
  • 99
  • 4
3

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

Lee Kowalkowski
  • 262
  • 2
  • 6
  • Oh, if only I had seen that list before my last job. I've counted about 6 anti-patterns used so far – Earlz Feb 26 '11 at 06:26
3

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

Earlz
  • 22,658
  • 7
  • 46
  • 60
  • There is a guy from my team who loves to get his ego boost by re-ordering everyone's code to something like this. I hate him. – kizzx2 Feb 26 '11 at 04:31
  • `x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false); ` That's 3 question marks and only 2 colons. In C or C++, this would not compile, but maybe it's written in some other language? – Sjoerd Feb 26 '11 at 04:50
  • @Sjoe yea, I added a bit to the end to fix that. I'm almost positive this should be ambiguous though and requires parentheses around each conditional to compile. @kizz use reverse-merge his changes a few times. Maybe he'll get the hint – Earlz Feb 26 '11 at 06:06
3

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

emragins
  • 535
  • 2
  • 11
3

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.

Mag20
  • 3,281
  • 2
  • 23
  • 21
3

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

gladysbixly
  • 431
  • 4
  • 7
2

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.

PSU
  • 1,099
  • 8
  • 6
2

"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

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
  • 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
2

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

jwenting
  • 9,783
  • 3
  • 28
  • 45
2

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

dheerosaur
  • 181
  • 5
2

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

sunwukung
  • 2,275
  • 1
  • 17
  • 29
1

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.

Cheezmeister
  • 101
  • 1
1

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

Coyote21
  • 437
  • 2
  • 4
1

Very complete list: anti-patterns.

vartec
  • 20,760
  • 1
  • 52
  • 98
1

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.

MattLBeck
  • 101
  • 4
1

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

M. Utku ALTINKAYA
  • 121
  • 2
1

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

MPelletier
  • 2,038
  • 1
  • 18
  • 27
1

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

1

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

kiewic
  • 190
  • 7
1

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.

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

TODO: I need to document this properly.

Will _never_ happen

András Szepesházi
  • 581
  • 2
  • 7
  • 16
1

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.

Dima
  • 11,822
  • 3
  • 46
  • 49
1

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.

Scott McIntyre
  • 181
  • 3
0

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.

blunders
  • 4,550
  • 4
  • 31
  • 48