Are there specific "technical debts" that are not worth incurring? [closed]

Question

There are (at least) two ways that technical debts make their way into projects. The first is by conscious decision. Some problems just are not worth tackling up front, so they are consciously allowed to accumulate as technical debt. The second is by ignorance. The people working on the project don't know or don't realize that they are incurring a technical debt. This question deals with the second. Are there technical debts that you let into your project that would have been trivial to keep out ("If I had only known...") but once they were embedded in the project, they became dramatically more costly?

Overstay

Wow--think you could ask any broader question? Downvoted. – Bloomsbury

The question is intentionally broad, because I hope the answers will include things that I am ignorant of... and therefore would not be capable of asking a specific question about. – Overstay

read the faq: you are asked to pose specific questions. asking for specific answers doesn't make a broad question specific – Assamese

oh c'mon -- this is better than any of this month's hottest questions: The Coolest Server Names, Programmer Jokes — what’s your best one?, What tricks do you use to get yourself “in the zone”?, Dealbreakers for new programming , Jon Skeet Facts – Domineer

@Jimmy, true that.. not much happening on the hot page lately. – Liebman

Perhaps this question belongs on programmers.stackexchange.com, which was not available at the time it was asked. – Overstay

Answer 1

Ignoring security problems entirely.

Cross-site scripting is one such example. It's considered harmless until you get alert('hello there!') popping up in the admin interface (if you're lucky - script may as well silently copy all data admins have access to, or serve malware to your customers).

And then you need 500 templates fixed yesterday. Hasty fixing will cause data to be double-escaped, and won't plug all vulnerabilities.

Alimony

speaking from experience? ;-) – Conform

+1 on the security - I knew I was forgetting a big one! – Tetherball

Answer 2

Storing dates in a database in local timezone. At some point, your application will be migrated to another timezone and you'll be in trouble. If you ever end up with mixed dates, you'll never be able to untangle them. Just store them in UTC.

Overstay

Answer 3

One example of this is running a database in a mode that does not support Unicode. It works right up until the time that you are forced to support Unicode strings in your database. The migration path is non-trivial, depending on your database.

For example, SQL Server has a fixed maximum row length in bytes, so when you convert your columns to Unicode strings (NCHAR, NVARCHAR, etc.) there may not be enough room in the table to hold the data that you already have. Now, your migration code must make a decision about truncation or you must change your table layout entirely. Either way, it's much more work than just starting with all Unicode strings.

Overstay

+1 for advocating an easy step away from obsolete code pages! – Sedulity

last couple versions of sql server support varchar(max), char(max), nvarchar(max), and nchar(max) which can each store 2^31-1 bytes. Long values are stored off the physical row, but it works seamlessly as if it were in the actual row. msdn.microsoft.com/en-us/library/ms143432.aspx – Fashionable

Answer 4

Unit Testing -- I think that failing to write tests as you go incurs a HUGE debt that is hard to make up. Although I am a fan of TDD, I don't really care if you write your tests before or after you implement the code... just as long as you keep your tests synced with your code.

Lolalolande

Exactly. And if a team is interested in starting to write unit tests, they should start doing so. Don't wait for the perfect understanding or high code coverage. I firmly believe that not doing any unit testing is a higher liability than not doing them perfectly. – Dioptrics

Answer 5

Not starting a web project off using a javascript framework and hand implementing stuff that was already available. Maintaining the hand written javascript became enough of a pain that I ended up ripping it all out and redoing it with with the framework.

Roister

of course, the converse is often true too... using a full library for trivial javascript tasks that are inherently cross-browser-portable is often overkill. – Domineer

Answer 6

I really struggle with this one, trying to balance YAGNI versus "I've been burned on this once too often"

My list of things I review on every application:

1. Localization:
   2. Is Time Zone ever going to be important? If yes, persist date/times in UTC.
   3. Are messages/text going to be localized? If yes, externalize messages.
2. Platform Independence? Pick an easily ported implementation.

Other areas where technical debt can be incurred include:

• Black-Hole Data collection: Everything goes in, nothing ever goes out. (No long-term plan for archiving/deleting old data)
• Failure to keep MVC or tiers cleanly separated over the application lifetime - for example, allowing too much logic to creep into the View, making adding an interface for mobile devices or web services much more costly.

I'm sure there will be others...

Tetherball

Answer 7

Scalability - in particular data-driven business applications. I've seen more than once where all seems to run fine, but when the UAT environment finally gets stood up with database table sizes that approach productions, then things start falling down right and left. It's easy for an online screen or batch program to run when the db is basically holding all rows in memory.

Aphrodisia

Answer 8

At a previous company they used and forced COM for stuff it wasn't needed for.

Another company with a C++ codebase didn't allow STL. (WTF?!)

Another project I was on made use of MFC just for the collections - No UI was involved. That was bad.

The ramifications of course for those decisions were not great. In two cases we had dependencies on pitiful MS technologies for no reason and the other forced people to use worse implementations of generics and collections.

I classify these as "debt" since we had to make decisions and trade-offs later on in the projects due to the idiotic decisions up front. Most of the time we had to work around the shortcomings.

Admetus

This is just stupidity. But is it technical debt ? – Kami

Yes, the results were that we had library conflicts and threading (apartment model crap and other issues) - we also had bad results with other collection classes - like ATL replacement of MFC> The result of that is real programmers had to learn atl collections rather than the stl stuff – Admetus

Answer 9

While not everyone may agree, I think that the largest contributor to technical debt is starting from the interface of any type of application and working down in the stack. I have come to learn that there is less chance of deviation from project goals by implementing a combination of TDD and DDD, because you can still develop and test core functionality with the interface becoming the icing.

Granted, it isn't a technical debt in itself, but I have found that top-down development is more of an open doorway that is inviting to decisions that are not well thought out - all for the sake of doing something the "looks cool". Also, I understand that not everyone will agree or feel the same way about it, so your mileage might vary on this one. Team dynamics and skills are a part of this equation, as well.

Dioptrics

Answer 10

The cliche is that premature optimization is the root of all evil, and this certainly is true for micro-optimization. However, completely ignoring performance at a design level in an area where it clearly will matter can be a bad idea.

Caparison

Answer 11

Not having a cohesive design up front tends to lead to it. You can overcome it to a degree if you take the time to refactor frequently, but most people keep bashing away at an overall design that does not match their changing requirements. This may be a more general answer that what your looking for, but does tend to be one of the more popular causes of technical debt.

Sacchariferous