Monthly Archives: February 2013


If you postponing the payment of your technical debt, you are definitely doing something wrong and it will cost you more later. Business owners cannot see the value of this (as it doesn’t translate to a tangible feature in the application). It is the responsibility of the technology owner to make this as part of the overall plan (cost and time)


I am assuming that, you already know what technical debt means.

We are building a EDI processing platform. This means we have to understand the EDI specifications of many HIPAA transactions. While you are at it, make sure that don’t keep any technical debt pending. Pay it off IMMEDIATELY (I know I am giving a concrete example of my scenario, I guarantee, this applies to many software projects). Here is why:

While things are fresh in mind, you can do lot of important things which will be very useful though out the life cycle of your product. Write ALL the required unit tests (you cannot give any excuses for not doing this). EDI documents comes in so many verities, each with its own quirkiness. Take some of these exceptional documents cover all the test cases. Make sure that, every time you change your core code, these tests pass. These unit tests (if written/used properly) will have save your ass (many time over). If your software is written such a way that, creating unit tests is difficult, then you have far bigger problem than paying off technical debt.

In addition, capture the overall design in a Visio (or any graphical fashion of your choice) diagram and store is close to its corresponding source code.

One more thing I do is, keep track of counts: Since we have to process large number of files (each with several EDI records), every time we make changes to core of the software, we run the process and compare these counts with the previous version.

If you are just one developer in your project, do whatever you want. Otherwise, there must be a clear definition of what DONE means. Do not check in code that ‘sort of works’ or ‘sort of complete’. This will affect the overall flow of the ‘value’ and creates unnecessary friction and stops you from delivering potentially shippable product.


Imagine a scenario where you have to perform some sort of processing then persist information to RDBMS. Without the support of sequence numbers in the underlying RDBMS, support, you have to perform these tasks in a serial fashion.


As you can see from the following diagram, it is very easy to make your overall process to run in parallel



I have not used this in any real project yet. When get a chance to do it, I will update this blog further.