views:

383

answers:

11

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?

+4  A: 

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.

tvanfosson
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.
Jimmy
+5  A: 

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.

Brandon DuRette
+1 for advocating an easy step away from obsolete code pages!
Jeffrey L Whitledge
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.http://msdn.microsoft.com/en-us/library/ms143432.aspx
KM
A: 

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.

Nerdfest
+1  A: 

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.

Tim
This is just stupidity. But is it technical debt ?
krosenvold
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
Tim
+1  A: 

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.

joseph.ferris
+8  A: 

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.

porneL
speaking from experience? ;-)
Nathan Koop
+1 on the security - I knew I was forgetting a big one!
Ken Gentle
+2  A: 

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:
    1. Is Time Zone ever going to be important? If yes, persist date/times in UTC.
    2. 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...

Ken Gentle
+7  A: 

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.

Brandon DuRette
+2  A: 

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.

Ken H
+4  A: 

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.

Brian Genisio
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.
joseph.ferris
+1  A: 

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.

dsimcha