agile-otter.bsky.social
Software, guitars, books and articles,
Industrial Logic's own Agile Otter
292 posts
2,442 followers
9 following
Regular Contributor
Active Commenter
comment in response to
post
Yes.
When I do it on my own, it is free fun.
If I rely on a vibebot, I have to feed it money.
That isn't to say that there is no place for such things.
I'm surprised at what you can get when "the first taste is free."
comment in response to
post
Was it card stock? I bet that is the secret!
comment in response to
post
Change the validation to allow only 1-100 instead of 0-100: it rewrites the UI and adds 50 lines of code.
comment in response to
post
All tests support refactoring, and approvals and E2E are great scaffold tests at the least, and often useful guard tests to boot!
comment in response to
post
I thought "legacy code is any code without tests" was a radical statement at the time. I realized that, tactically speaking, any code without tests is still "code without tests" whether written 10 years or 10 seconds ago.
Michael was right to begin with.
comment in response to
post
This is one area where approval tests are excellent, and you might even use AI to generate some tests.
comment in response to
post
No, you keep it.
It is time for someone else to benefit and it was probably part of my purge before moving to Scotland. I don’t carry physical books around much any more.
comment in response to
post
Yes, that's my old copy. i miss it.
I hope you get as much joy from it as I did.
comment in response to
post
THAT's what happened to it!!!
comment in response to
post
A daily status meeting is probably a "tell" for a non-agile team. It's not so much that the meeting is bad, it's that it's showing other problems.
A bit more here;
www.industriallogic.com/blog/the-dai...
comment in response to
post
Well, XP and scrum include it, so I guess not frowned upon.
It's really only an antipattern when some other element of agility is left out, like in solo ticket processing (unteaming) - where what person A is doing is none of person B's business, and so through the "team."
comment in response to
post
No.
It does require that business and development work together every day, though.
agilemanifesto.org/principles.h...
comment in response to
post
Or at least you're ready for the StopIteration and AttributeError. ;-)
comment in response to
post
[email protected] <-- note the lack of a trailing R. :-)
comment in response to
post
I've eventually got to trim that bio down, and maybe remove the articles in magazines nonsense.
But it looks good to me and is on my calendar.
comment in response to
post
Splitting is really important.
It's not important to slice up-front into assignments to do that.
I find that people doing teaming are more likely to drop needless work in the moment.
comment in response to
post
"Clean start, easy recovery"
Why your desk disciplines matter, and how a measured approach leads to continuous development.
Come explore how a safe and sane approach to software development can result in big organizational improvements.
(Not by Wednesday)
comment in response to
post
a) YES.
B) Umm... "First-Time Through and the CD Pipeline" or maybe "Clean Start, Safe Retreat, Fast Feedback"
comment in response to
post
Excellent!
comment in response to
post
Are you making it go away today?
comment in response to
post
How so?
comment in response to
post
Thank you! Fixed now, will be live shortly.
comment in response to
post
I agree. I like the presence of safeties.
What bothers me is that so many people work from self-confidence alone, never checking their code and even ignoring or disabling checks, and then are angry when they get rejections from the pipeline.
comment in response to
post
People with difficult gates and a lack of understanding tend to "try to sneak a dirty joke past the censors" rather than clean up their act. I've seen code written to get past a strict linter in the worst possible way, mostly from ignorance. It passed the automated checks, but OMG.
comment in response to
post
The trick, of course, is to write the code that will pass through the pipeline on the first try.
Not to lower standards, certainly.
So, how could we bolster the editing session to enable a high First Time Through ratio?
comment in response to
post
Writing tests for existing code that uses Calendar.
¯\_(ツ)_/¯
comment in response to
post
But also, had I NOT used Calendar.getInstance() to give me a current time/date, but had specified a day with a time ending in all zeros (00:00:00, or 12:00:00) it would have been obvious, AND free of DST flakiness.
It is the noobiest of sins. Please grant me absolution.
comment in response to
post
... then was surprised when "both" dates had the same value.
Sigh. In python, adding a time to a date returns a new date.
In Java, it's a void-returning mutator.
TAKE A CLUE, TIM!!!!!
comment in response to
post
Humans have an innate difficulty in processing guilt, embarassment, and/or shame that they associate with failure.
It's maybe one of the most human things of all, coming in just after curiosity or awe?
comment in response to
post
(sadly, some people have told them that solo-ticket-processing is "agile" or "scrum" and therefore is not to be questioned. More the pity.)
comment in response to
post
Yes, this is true, and typically more than offsets the elimination of backflow within a week or two (sometimes the first day!) but these are definitely real things. Some people and some teams may take a bit longer to settle in, and especially managers raised in utilization-greediness.