Click here to Skip to main content
15,868,016 members

itsdkg - Professional Profile



Summary

    Blog RSS
9,342
Author
146
Authority
30
Debator
33
Editor
19
Organiser
305
Participant
0
Enquirer
A programmer by heart since 1998. Written code in C++, Java, JavaScript, Python & Ruby, Worked on Stack Development to Web Development. Data Specialist with SQL and NoSQL DBs

Reputation

Weekly Data. Recent events may not appear immediately. For information on Reputation please see the FAQ.

Privileges

Members need to achieve at least one of the given member levels in the given reputation categories in order to perform a given action. For example, to store personal files in your account area you will need to achieve Platinum level in either the Author or Authority category. The "If Owner" column means that owners of an item automatically have the privilege. The member types column lists member types who gain the privilege regardless of their reputation level.

ActionAuthorAuthorityDebatorEditorEnquirerOrganiserParticipantIf OwnerMember Types
Have no restrictions on voting frequencysilversilversilversilver
Bypass spam checks when posting contentsilversilversilversilversilversilvergoldSubEditor, Mentor, Protector, Editor
Store personal files in your account areaplatinumplatinumSubEditor, Editor
Have live hyperlinks in your profilebronzebronzebronzebronzebronzebronzesilverSubEditor, Protector, Editor
Have the ability to include a biography in your profilebronzebronzebronzebronzebronzebronzesilverSubEditor, Protector, Editor
Edit a Question in Q&AsilversilversilversilverYesSubEditor, Protector, Editor
Edit an Answer in Q&AsilversilversilversilverYesSubEditor, Protector, Editor
Delete a Question in Q&AYesSubEditor, Protector, Editor
Delete an Answer in Q&AYesSubEditor, Protector, Editor
Report an ArticlesilversilversilversilverSubEditor, Mentor, Protector, Editor
Approve/Disapprove a pending ArticlegoldgoldgoldgoldSubEditor, Mentor, Protector, Editor
Edit other members' articlesSubEditor, Protector, Editor
Create an article without requiring moderationplatinumSubEditor, Mentor, Protector, Editor
Approve/Disapprove a pending QuestionProtector
Approve/Disapprove a pending AnswerProtector
Report a forum messagesilversilverbronzeProtector, Editor
Approve/Disapprove a pending Forum MessageProtector
Have the ability to send direct emails to members in the forumsProtector
Create a new tagsilversilversilversilver
Modify a tagsilversilversilversilver

Actions with a green tick can be performed by this member.


 
GeneralNot every code or design shortcut is "Technical Debt" Pin
itsdkg22-Feb-16 19:30
itsdkg22-Feb-16 19:30 
The word “Technical Debt” has come a long way since it was first introduced by Ward Cunningham in early 1990s.

The word “Technical Debt” makes sense as most of us are aware about the meaning of “Financial Debt”, which means paying interests all the time unless you repay your principle amount.

Similarly Technical Debt means that we need to pay interests (in terms of our design or code capability) all the time unless we re-factor our earlier design or code (the principle).

However, somewhere during the rush hour to find technical debt we've start characterizing every coding / designing shortcut as technical debts. We should just be very clear that there is a fundamental difference between a Technical Debt and a Financial Debt.

In a Financial Debt, you always know the amount of interest that one needs to pay all the time and what’s your principle outstanding. However, in a Technical Debt you neither know the amount of interest you will pay nor the cost to pay your principle (i.e. Effort to re-factor the design or code).

For design / code, it’s unlikely that we can quantify the interest cost unless the shortcuts are causing very trivial side effects like increase memory / flash footprint, cache misses etc.

In reality, people are trying to analyze the design and code from the perspective of whether the code can be extended to support additional feature or it’s looking ugly and difficult to understand so it needs to be re-factored and so on.

I’d like to advice against considering these designs and codes as Technical Debt.

An ugly looking code which is working fine and may not be required to change in near future is not a technical debt.

A design or code which shows little sign of being extendable is not a technical debt unless there is an immediate need to extend it.

It’s wise to remember the financial cost of being future proof which nobody really knows about. The cost of redoing things a new way in future may be much smaller than to keep on refactoring in assumption of future needs, which nobody can predict and control.

To summaries, if you’re given a chance to identify and fix technical debt, use that opportunity wisely.

Just a thought

Dkg

(Disclaimer : The opinion is purely mine and it doesn't reflect the views of the organization I'm employed with)

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.