@jhumelsine.bsky.social
Oops, should be: ... cells -> organelles -> bio-molecules ...
November 15, 2025 at 2:53 PM
Oops, should be: ... cells -> organelles -> bio-molecules ...
Consider biology, which is its own biotech stack.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
November 15, 2025 at 2:51 PM
Consider biology, which is its own biotech stack.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
Organisms -> systems -> organs -> cells -> bio-molecules -> ...
While scientists can understand concepts at each level, understanding each supporting level helps us understand the levels above it.
However, when you find code that doesn't look correct, still document it with a test, but add SHOULD_IT to the end of the test name.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
November 13, 2025 at 11:11 PM
However, when you find code that doesn't look correct, still document it with a test, but add SHOULD_IT to the end of the test name.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
Then create a ticket highlighting the test for someone with more domain knowledge to evaluate.
AI would basically be automated characterization tests, which don't address correctness or not.
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
November 13, 2025 at 11:11 PM
AI would basically be automated characterization tests, which don't address correctness or not.
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
I wrote about this to some degree in this section of my legacy code blog: jhumelsine.github.io/2025/03/24/l...
TL;DR - We can usually assume that legacy code is correct, since users confirm it.
...
I can see one possible application: Use AI tests to add coverage to legacy code that does not have tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
November 13, 2025 at 1:34 PM
I can see one possible application: Use AI tests to add coverage to legacy code that does not have tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
AI tests would provide temporary coverage to refactor and reveal behavior and intent. Then replace AI tests with behavior inspired human written tests.
I've got three reasons:
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
October 28, 2025 at 8:58 PM
I've got three reasons:
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
1. Software practices are not presented by academia.
2. Prisoners Dilemma from Game Theory. Individuals are rewarded for closing tickets quickly rather than taking the time to invest in the codebase for the team.
3. It's too hard to break old habits.
I still like to rearrange the list so that they spell CLAMS or CALMS.
October 21, 2025 at 12:03 PM
I still like to rearrange the list so that they spell CLAMS or CALMS.
Here's the section of my Legacy Code blog entry that summarizes Characterization Testing and introduces the concept of AI Generation.
jhumelsine.github.io/2025/03/24/l...
jhumelsine.github.io/2025/03/24/l...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
October 20, 2025 at 2:37 PM
Here's the section of my Legacy Code blog entry that summarizes Characterization Testing and introduces the concept of AI Generation.
jhumelsine.github.io/2025/03/24/l...
jhumelsine.github.io/2025/03/24/l...
However, Characterization Tests aren't the most fun to right, and they tend to be nasty, since the Legacy Code is probably nasty too.
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
October 20, 2025 at 2:37 PM
However, Characterization Tests aren't the most fun to right, and they tend to be nasty, since the Legacy Code is probably nasty too.
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
If we trust that the legacy code is correct via user confirmation, then I think we can use AI to generate temporary Characterization Tests.
...
Characterization Tests provide safety scaffolding but tend to be implementation specific and brittle. CTs provide temporary safety to refactor legacy code hoping intent will emerge. Then replace CTs with behavior based tests from revealed intent.
...
jhumelsine.github.io/2025/03/24/l...
...
jhumelsine.github.io/2025/03/24/l...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
October 20, 2025 at 2:36 PM
Characterization Tests provide safety scaffolding but tend to be implementation specific and brittle. CTs provide temporary safety to refactor legacy code hoping intent will emerge. Then replace CTs with behavior based tests from revealed intent.
...
jhumelsine.github.io/2025/03/24/l...
...
jhumelsine.github.io/2025/03/24/l...
I agree that I don't think that in general we should use AI to generate test cases. However, I see one possible exception with working legacy code, which is tested indirectly via our users.
This means that most legacy code "tends" to work even if we don't understand it.
...
This means that most legacy code "tends" to work even if we don't understand it.
...
October 20, 2025 at 2:36 PM
I agree that I don't think that in general we should use AI to generate test cases. However, I see one possible exception with working legacy code, which is tested indirectly via our users.
This means that most legacy code "tends" to work even if we don't understand it.
...
This means that most legacy code "tends" to work even if we don't understand it.
...
I agree. Tech Debt's original meaning has been usurped possibly forever. That's probably because there's so much Cruft when compared to the amount of OG Tech Debt.
October 13, 2025 at 8:01 PM
I agree. Tech Debt's original meaning has been usurped possibly forever. That's probably because there's so much Cruft when compared to the amount of OG Tech Debt.
I also feel that cruft is the unintended consequences of a lot of incentives. Not enough room for details here, but it's similar to the Tragedy of the Commons and the Prisoners Dilemma.
October 13, 2025 at 7:39 PM
I also feel that cruft is the unintended consequences of a lot of incentives. Not enough room for details here, but it's similar to the Tragedy of the Commons and the Prisoners Dilemma.
I now try to use "Technical Debt" in Ward Cunningham's original intent and "Cruft" for the short cuts that accumulate and eventually gum up the works in the implementation.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
October 13, 2025 at 7:35 PM
I now try to use "Technical Debt" in Ward Cunningham's original intent and "Cruft" for the short cuts that accumulate and eventually gum up the works in the implementation.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
Tech Debt makes more sense as a term when consider with Cunningham's original intent too.
Thanks for sharing. I've added it to the list of references in jhumelsine.github.io/2025/03/24/l...
Working Effectively with Legacy Code
… with all due respect to Michael Feathers in stealing his book title and a lot of his ideas for this blog
jhumelsine.github.io
October 7, 2025 at 4:51 PM
Thanks for sharing. I've added it to the list of references in jhumelsine.github.io/2025/03/24/l...
I reference the song "Que Sera, Sera" when it comes to YAGNI. "Whatever will be, will be. The future's not ours to see."
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
October 7, 2025 at 1:25 PM
I reference the song "Que Sera, Sera" when it comes to YAGNI. "Whatever will be, will be. The future's not ours to see."
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
While we can't predict the future, it is coming.
Therefore, we should design so that we're flexible enough to accommodate whatever will be coming.
"now" or "not". Unfortunately, both sort of work these days.
September 24, 2025 at 8:44 PM
"now" or "not". Unfortunately, both sort of work these days.
Thanks for the conversation with Dan and your BDD reference. I've added them both of them to the references section of my BDD blog entry.
jhumelsine.github.io/2024/08/08/b...
jhumelsine.github.io/2024/08/08/b...
Be On Your Best Behavior
Test-Driven Development - How to create tests; Behavior-Driven Development - What tests to create
jhumelsine.github.io
September 23, 2025 at 1:30 PM
Thanks for the conversation with Dan and your BDD reference. I've added them both of them to the references section of my BDD blog entry.
jhumelsine.github.io/2024/08/08/b...
jhumelsine.github.io/2024/08/08/b...
Aren't many original COBOL programmers retired or dead?
September 17, 2025 at 1:21 PM
Aren't many original COBOL programmers retired or dead?
Developers should be responsible for the code the produce.
However, responsibility is more than just the developers. It also applies to PMs, domain experts, managers, executives, etc.
If you produce a substandard artifact, you should feel the pain.
However, responsibility is more than just the developers. It also applies to PMs, domain experts, managers, executives, etc.
If you produce a substandard artifact, you should feel the pain.
September 17, 2025 at 1:20 PM
Developers should be responsible for the code the produce.
However, responsibility is more than just the developers. It also applies to PMs, domain experts, managers, executives, etc.
If you produce a substandard artifact, you should feel the pain.
However, responsibility is more than just the developers. It also applies to PMs, domain experts, managers, executives, etc.
If you produce a substandard artifact, you should feel the pain.
BDD tests specify behavior for the Software Under Test (SUT), whose implementation is challenged and confirmed each time the tests are executed.
jhumelsine.github.io/2024/08/08/b...
jhumelsine.github.io/2024/08/08/b...
Be On Your Best Behavior
Test-Driven Development - How to create tests; Behavior-Driven Development - What tests to create
jhumelsine.github.io
September 14, 2025 at 6:49 PM
BDD tests specify behavior for the Software Under Test (SUT), whose implementation is challenged and confirmed each time the tests are executed.
jhumelsine.github.io/2024/08/08/b...
jhumelsine.github.io/2024/08/08/b...
When they said that AI would create new jobs, this isn't exactly what I thought they had in mind.
September 14, 2025 at 12:42 PM
When they said that AI would create new jobs, this isn't exactly what I thought they had in mind.