tag:blogger.com,1999:blog-36118108.post4315843750725962700..comments2023-12-06T00:17:28.519-08:00Comments on Creative Chaos: Technical Debt - IIMatthewhttp://www.blogger.com/profile/05956714498778698672noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-36118108.post-51522408825897805662007-10-24T22:46:00.000-07:002007-10-24T22:46:00.000-07:00I disagree with James Bach that technical debt get...I disagree with James Bach that technical debt gets forgiven on a regular basis. What happens is that the new manager and/or programmers look at debt-ridden code and say, "This steaming pile of crap needs to be rewritten." The old code-base is largely tossed away and a whole new set of bugs are brought into existence. <BR/><BR/>This isn't technical debt forgiveness. It is declaring bankruptcy.Steve Polinghttps://www.blogger.com/profile/06095291939072131815noreply@blogger.comtag:blogger.com,1999:blog-36118108.post-4082213657222170982007-10-12T06:09:00.000-07:002007-10-12T06:09:00.000-07:00FYI:I'm currently working in an operational enviro...FYI:<BR/><BR/>I'm currently working in an operational environment that suffers from a large technical debt. <BR/><BR/>Technical debt got introduced by several reasons. It is indeed as you say a fact of working within the constraints. <BR/><BR/>The operational part is more duct tape then anything else. And now it works like a snowball effect: incidents take up more time, less time is left to project work. The operational people only finish the solutions half way. As the project is long gone, they are the only ones left.<BR/><BR/>It can at the moment not be solved anymore at the technical level. I'm trying to create this awareness to have a separate team for 'operational' projects aside from the operational team who handles the incidents. Projects should take this kind of maintenance team into account when they are calculating the cost of the project maintenance.<BR/><BR/>It is normal that project tend to focus on the fuctional aspect. But one of the actors they most often forget in their use cases are operations.Patrick Deboishttps://www.blogger.com/profile/08503871075811189483noreply@blogger.comtag:blogger.com,1999:blog-36118108.post-48519716900010618522007-10-05T06:54:00.000-07:002007-10-05T06:54:00.000-07:00Hi,This article is good and informative.Software D...Hi,<BR/><BR/>This article is good and informative.<BR/><BR/><A HREF="http://www.frontlinesoft.com/company.html" REL="nofollow">Software Development Company</A><BR/><BR/><A HREF="http://www.processfront.com" REL="nofollow">Free Directory</A><BR/><BR/><A HREF="http://www.careersfront.com" REL="nofollow">Software Jobs India</A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-36118108.post-28724706117926480362007-10-04T20:30:00.000-07:002007-10-04T20:30:00.000-07:00Software Entropy - what a nice term... I think it ...Software Entropy - what a nice term... I think it deserves a separate post. Great to see your post on technical debt linking Entropy is simply great.<BR/><BR/>Your veiew of role of "software Entropy" in complexity (growing) of an existing software, new code vs maintenance costs, business pressures (and probably social science issues of people interactions) - is inspiring. Expect more on these lines ...<BR/><BR/>Interestingly found an article on IBM site - where the author claims to fight Software Entropy with ClearCase - IBM's config mgmt tool.<BR/>The paper also touches upon another natural phenamenon - Gravity.<BR/><BR/>http://www.ibm.com/developerworks/rational/library/3871.html<BR/><BR/>Time to include Entropy in "Creative Chaos" (title) ?<BR/><BR/>>>What you can do to reduce technical debt?<BR/><BR/>Understand "entropical forces" in software and just do not rush to make everything great and perfect (do it right first time) etc.<BR/><BR/>Understand that there are natural forces that are at play to "mess" up every thing that we attempt to do to bring order in Chaos (in Creative Chaos?)<BR/><BR/>Shrini<BR/><BR/><BR/>ShriniShrini Kulkarnihttps://www.blogger.com/profile/10782753752478547381noreply@blogger.comtag:blogger.com,1999:blog-36118108.post-56007567365740828642007-10-04T03:42:00.000-07:002007-10-04T03:42:00.000-07:00I happen to see an article from Jonathan Kohl (he ...I happen to see an article from Jonathan Kohl (he calls it as "Testing Debt ..(a 2005 blog post)<BR/><BR/>http://www.kohl.ca/blog/archives/000148.html<BR/><BR/>This post also refers another work by Johanna Rothman in this area<BR/><BR/>Can you see the similarities and differences?<BR/><BR/>ShriniShrini Kulkarnihttps://www.blogger.com/profile/10782753752478547381noreply@blogger.comtag:blogger.com,1999:blog-36118108.post-38753852533815023882007-10-02T19:14:00.000-07:002007-10-02T19:14:00.000-07:00The debt metaphor is interesting, but it doesn't q...The debt metaphor is interesting, but it doesn't quite fit. Unlike real debt, technical "debt" gets forgiven on a regular basis. If your product becomes obsolete, the "debt" just goes away.<BR/><BR/>It's only if you maintain a code-base for the long term that this debt issue becomes critical and chronic.James Marcus Bachhttps://www.blogger.com/profile/09985950531079499844noreply@blogger.com