https://pinboard.in/u:jm/public/ recent bookmarks from jm 2024-09-12T15:05:44+00:00 https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt jm Q: “I’d like to make a better case for paying down tech debt on my team. What are some proven approaches for this?” The tension in finding the right balance between shipping features and paying down accumulated tech debt is as old as software engineering. There’s no one answer on how best to reduce tech debt, and opinion is divided about whether zero tech debt is even a good thing to aim for. But approaches for doing it exist which work well for most teams. To tackle this eternal topic, I turned to industry veteran Lou Franco, who’s been in the software business for over 30 years as an engineer, EM, and executive. He’s also worked at four startups and the companies that later acquired them; most recently Atlassian as a Principal Engineer on the Trello iOS app. Apparently Lou has a book on the topic imminent.]]> programming refactoring coding technical-debt tech-debt lou-franco software https://pinboard.in/ https://pinboard.in/u:jm/b:9cb66698c094/ 2021-01-18T10:24:54+00:00 https://codereview.stackexchange.com/ jm code-review algorithms coding review refactoring stack-exchange https://pinboard.in/ https://pinboard.in/u:jm/b:79b9cc8deda5/ 2014-09-09T13:19:56+00:00 http://blog.jetbrains.com/clion/2014/09/05/clion-brand-new-ide-for-c-and-c-developers/ jm c c++ refactoring ide intelli-j clion jetbrains editors coding https://pinboard.in/ https://pinboard.in/u:jm/b:41a0061b835d/ 2014-08-18T11:38:10+00:00 http://tech.blog.box.com/2014/08/a-tale-of-postmortems/ jmThe picture was getting clearer, and we decided to look into individual postmortems and action items and see what was missing. As it was, action items were wasting away with no owners. Digging deeper, we noticed that many action items entailed massive refactorings or vague requirements like “make system X better” (i.e. tasks that realistically were unlikely to be addressed). At a higher level, postmortem discussions often devolved into theoretical debates without a clear outcome. We needed a way to lower and focus the postmortem bar and a better way to categorize our action items and our technical debt. Out of this need, PIE (“Probability of recurrence * Impact of recurrence * Ease of addressing”) was born. By ranking each factor from 1 (“low”) to 5 (“high”), PIE provided us with two critical improvements: 1. A way to police our postmortems discussions. I.e. a low probability, low impact, hard to implement solution was unlikely to get prioritized and was better suited to a discussion outside the context of the postmortem. Using this ranking helped deflect almost all theoretical discussions. 2. A straightforward way to prioritize our action items. What’s better is that once we embraced PIE, we also applied it to existing tech debt work. This was critical because we could now prioritize postmortem action items alongside existing work. Postmortem action items became part of normal operations just like any other high-priority work. ]]> postmortems action-items outages ops devops pie metrics ranking refactoring prioritisation tech-debt https://pinboard.in/ https://pinboard.in/u:jm/b:849482d466c0/ 2011-11-15T13:22:06+00:00 http://eclim.org/ jm eclipse java programming software vim editors refactoring https://pinboard.in/ https://pinboard.in/u:jm/b:f8857bc0f67c/ 2010-09-02T14:29:54+00:00 http://akohli.wordpress.com/2010/08/31/if-slalom/ jm via:akohli code-smells refactoring if-slalom programming funny if-else indentation https://pinboard.in/u:jm/b:f819bb842477/