What programming shortcuts do you end up regretting or backing out? [closed]

Question

I saw this question and it reminded me of AutoGenerateColumns in the old DataGrid. The few times I've used them, I ended up backing it out because I needed data formatting past the standard "spit out the Data Source columns." Likewise, with toggle, it sounds like it would save time, but then you end up needing to keep track of state or something else, and you rewrite the code accordingly.

Are there things that you end up using thinking it will save you time, but end up backing out because it doesn't do what you need?

Answer 1

Make a little improvement in an existing working system and not cover it with tests.

For many times it ended up with debugging hell. Worst of all that the hell went to my colleagues, not me.

Answer 2

I think the obvious answer for the most regrettable programming "shortcut" would be gotos.

But regarding frameworks, I think all frameworks can be a trap sometimes. They're not bad to use but I don't think you'll find a framework that doesn't force you to purchase reduced development time with reduced maintainability. I work mostly with Drupal, and every time a new version comes out I have to rewrite at least some of my custom code... but that's the price I pay for being able to add new features quickly with community modules, and for me, it's worth it. For a different set of purposes or applications, it certainly wouldn't be worth it.

Answer 3

Every large web project that starts with a huge amount of modularity usually goes too far for the scope of the application that will eventually be built.

So, the web layer calls a delegate interface calls delegate implementation calls service interface calls service implementation calls dao interface calls dao implementation and so on.

And eventually, since you didn't do distribution at this level, you notice that all of your delegate implementations are one line of code, and you pull them out for clarity, after losing some efficiency by writing a hundred delegate classes in the first place.

---

Or: most projects at one point or another massively overestimate how large the application's userbase will be, and unfortunately, code for that instead of coding more efficiently. A cookbook application with 200 users is a lot more common to write than an industry-defining application with a hundred thousand users every morning, but developers tend to code part - but not all of - their app for the improbable case.

If you're writing hello world, just write the code, and bulk it up later as needed.

Answer 4

Letting Visual Studio do the Data Binding. It works most of the time, but sometimes it introduces subtle bugs that take far more time to find and solve than it would doing the data binding manually.

Answer 5

Copy/pasting a few lines of code that are similar to, but not exactly the same as the code you need right now, will almost always result in a bug in that code.

It's almost always better to just type it character by character, forcing yourself to consider everyone of them. But I keep doing it, thinking: "what could possibly go wrong", and regretting the decision later.

Answer 6

Using the latest and greatest feature from <insert framework here> only to have it fail and take longer.

I am all for new features but to use them too soon can be problematic.

Answer 7

The over usage of C/C++ macros. I think it's a trap big projects fall into more than small projects though.

Answer 8

Not exactly a shortcut, but: Writing a C++ String class without even considering the possibility that someone else has had the same idea. However, it was a good exercise, as I learned that:

• Writing a library doesn't make all of programming downhill from there. It can be easier to have a library on hand, but if it's harder to understand the semantics of the library than to implement the functionality by hand, the library can turn out to be pretty useless.
• C++ has a lot of really neat features.
• C++ is always missing that one feature I really need.