Skip to main content

Posts

Showing posts with the label Technical Debt

When do we begin Colonoscopy on Code?

At what age should we be inspecting all this code full of colons?  Sometime in 1970's the software world had a lot of colons evolving - 1973 for the popular C Language and its family... That tells us that in 2023 at age 50 the C Language should begin Colonoscopy procedures, yearly.  It's not a pleasant thought but it is the recommendation. Now some of the more modern (non-legacy) code may not need this extreme level of screening... but how would one know - unless one probes around in all those semicolons. Now, many Proctologist have worked to make this procedure less stressful, what have we done in the software community to improve patient outcomes, and satisfaction with our inspection and visualizations? Jokes from the Hole (A Proctologist's Perspective) Shall we work on that?

It's not Technical Debt - it's Unclean Code

I hear lots of colleagues using the term 'technical debt' and the scenario that plays in my brain's cineplex is from The Princess Bride when Inigo Montoya remarks to Vizzini; "You keep using that word.  I don't think it means what you think it means." Inconceivable! So what does "Technical Debt" mean?  And what do my colleague's typically mean if it is not truly technical debt. The first is easy; the definition of Technical Debt: He who coins the term gets to define the term ( that's Ward Cunningham ). Ward Cunningham on Technical Debt Metaphor  OK, so to be truly technical debt one must negotiate the debt with the business.  The business should achieve some objective sooner and incur an obligation to repay the technical team the time and effort required to put the system back into a proper state of clean well factored code. But, wait... what could my colleagues mean when they misuse the term technical debt?  I think the...

No test - inconceivable. Not Technical Debt.

Technical Debt The software term "technical debt" is getting a lot of play on the air waves.  But I do not think we are using it the way Ward was when he invented the term (a metaphor) to explain to his buisiness team why creating software fast to get feedback was a good thing.  But that they had to be willing and able to sustain a pace of repayment on the debt of doing just good enough design to get product feedback.  Their form of repayment was constant refactoring.  Always keeping the software model moving toward the best possible business model, which modeled the real world.  Using many XP practices to enable the repayment plan of the debt they were consciously assuming. In this vain, technical debt does not cover the process of writing bad code, of poor design, of skipping steps (such as testing).  Those behaviors would be considered to be incompetent design and implementation.  That behavior results not in debt at all but a breach of the in...

A Technical Debit - Collateralized Debt Obligation you should not invest in

I just watch Ward Cunningham explain the XP Technical Debit metaphor that he coined.  It enlightened my understanding of how the term was applied in the early days (when he used it), and how we have mutated the metaphor to cover areas he never intended. Ward Cunningham's Debt Metaphor Isn't a Metaphor (18 March 2009) In summary Ward was suggesting that it was valuable long term thinking for a company to take on debt (technical debt) in order to ship a product early and get market feedback. Feedback that would get factored into the next iteration (release) of that same product. You see building software by Ward's XP model is not like building a house or a sky-scraper, it's like growing a garden of asparagus . Asparagus is a flowering perennial which requires several seasons of cultivation before it is ready to ship to market.  My father grew asparagus in our garden, when I was a kid, I didn't like it much then, but love it now. Using debt to achieve some...