Dealing with technical debt during the sprint – Matthias Noback

It’s quite ironic that my most “popular” tweet has been posted while Twitter itself is in such a chaotic phase. It’s also quite ironic that I try to provide helpful suggestions for doing a better job as a programmer, yet such a bitter tweet ends up to be so popular.

Twitter and Mastodon are micro-blogging platforms. The problem with micro-blogs, and with short interactions in general, is that everybody can proceed to project onto your words whatever they like. So at some point I often feel the need to explain myself with more words, in an “actual” blog like this one.

Waste in scrum processes

Hypothesis: the moment a team adds the requirement that each PR/commit should be related to a Jira issue, it will start accumulating even more tech debt than before.

We notice that one of the dependencies of our project has been marked as “abandoned” and we need to upgrade/switch to something else. When helping a new co-worker join the team, we find out that some crucial steps aren’t documented in the README. The test framework hasn’t been updated for some time, and upgrading means we have to rewrite some test setup code.

These are things that just happen to our projects from time to time. Many developers won’t go ahead and make the necessary changes. Being part of a “scrum process” they will:

  • Create an issue in the backlog
  • Bring the issue to the attention of the decision maker
  • Wait for the decision maker to assign it to a future sprint

Finally, once the issue has been assigned to a sprint, it needs to be refined. So a group of people that is often too large starts to talk about and describe what needs to be done. Why? Because scrum tradition prescribes that every person on the team should be able to pick up the issue. I don’t think that’s true at all; we’re just wasting time explaining everything to everyone, while often only 2 people are going to pick it up.

In the end we have to vote for the number of story points that we’re going to assign. This magic number has no specific meaning. If we try to describe what such a point represents, we get different answers, even within the same team:

  1. “It’s definitely not how much time we spend on it” (because we don’t want it to be an estimate)
  2. “It’s how complex we think this is” (unfortunately we all have different ideas about what “complexity 3” means)
  3. “We can do about 50 points of these in each sprint” (so it is an estimate after all; given we have two weeks, we can do 50 of them, so each point represents 2 weeks divided by 50 of our time)

Don’t get me wrong, it’s good to think about how much time something will likely take and use a rough estimate to decide if you want to start working on it. It’s just that we are guessing, and we can have huge surprises while we are actually doing the work. Or the opposite happens: we are over-complicating things in the refinement stage and it turns out the actual work was so easy, we get 5 points for the price of 1…

In both cases, a big part of the preparation phase is just a waste of time and energy. I’m certain that many scrum teams could do much, much more if they would let go of wasteful practices like those that “official scrum” or similar project management techniques prescribe.

How to deal with technical debt in a sprint

Back to the original point about technical debt. From time to time developers will notice something about the code base that really needs to be improved, something that is not part of any feature anybody is working on, just “general maintenance” or “developer experience”, and so on. Developers need to do this work because they have to battle the forces pulling the project downward. If they do not continuously do that, one day the project will be beyond repair. Yet, the scrum process prescribes that no work be done in the sprint that is not on the board. So an issue has to be created, and we jump back into the project management waterfall.

At this point a developer have several options, each of which appeared several times in the comments to my bitter tweet:

  • They can follow the process because they have to. There are strict requirements, maybe an ISO-standard, that have to be enforced. No way around it. So first they create an issue, and wait for it to be assigned to a sprint.
  • In some teams they wouldn’t have to wait, they can pick it up inside the sprint. But only if it’s small, “a 1” or “a 2”, because more would “endanger” the sprint.
  • They can play the process, and do general improvements as part of the current ticket they are working on (but these are now unrelated changes).
  • They can commit t

Truncated by Planet PHP, read more at the original (another 2664 bytes)

PHP 8.2.0 RC 6 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the release of PHP 8.2.0, RC 6. This is the sixth release candidate, continuing the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.2.0, RC 6 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the seventh release candidate (RC 7), planned for Nov 24th 2022. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.

Xdebug Update: August, September, and October 2022 – Derick Rethans

Xdebug Update: August, September, and October 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 45% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

I did not find the time to write this report in the last two months, sorry for that. So today I present you with a report for the last quarter.

In the last three months, I spend 63 hours on Xdebug, with 77 hours funded.

Xdebug Videos

I have published two new videos:

I have started writing scripts for videos about Xdebug 3.2’s features, and am also intending to make videos about “Running Xdebug in Production” and “Debugging Worker Tasks with xdebug_connect_to_client()”.

You can find all previous videos on my YouTube channel.

Neko – A brief history and porting to Javascript – Evert Pot

In the early 90’s, being a frisian kid obsessed with computers there weren’t a
ton of ways to get access to new software or learn more about computers.

The two main ways were exchanging 3.5” diskettes with friends, or go to the
library. One book I remember more than others was “Windows for Kinderen”
(“Windows for Kids”) by Addo Stuur.

I must have been around 10 years old and was obsessed by this book. It covered
Windows 3.0, and when you got the book from the library, it came with a diskette
filled to the brim with shareware. Mostly games and
useless toys, but it still baffles me thinking they were able to cram it all on
a 1.44 megabyte disk. Using floppys from the libraries was even back then a
risky business given that they’re writable! Luckily this mostly went ok.

One that I remembered particularly well was ‘Neko’, an application that
renders a cat in a window that follows your mouse. This must have been a
popular thing to make at the time, because the diskette somehow had space
for 3(!) different ports of this same application.

I don’t know what reminded me of Neko last week, but I started doing some
more research, and found out that the first version was written all the
way back in the 1980’s by Naoshi Watanabe for the NEC PC 9801.

Neko for the NEC PC 9801
Neko for the NEC PC 9801 (1980’s)

After that, it was ported to the Macintosh in 1989 by Kenji Gotoh, and this
art style seems to be the basis of almost every future port:

Neko on Macintosh
Neko on Macintosh (1989)

In 1991, IBM included it in OS/2! Apparently they paid 300,000 YEN, which
is about $3000 CAD in todays money. At this point it also became public
domain.

Neko on OS/2
Neko on OS/2 (1991)

Since then there’s been countless ports for every platform. If you’re running
linux you might be able to install one by just running:

apt install oneko

I also decided to make a version. Neko is now close to 40, so my Neko is
no longer interested in following the mouse, and prefers to just sleep all day
unless you wake it.

Taking a look at Mastodon – Evert Pot

I’ve been a Twitter user and fan since 2007. With Twitter’s future
looking a bit grim, I started looking around if there’s another place to go.

Twitter can’t really be replaced with anything else, because everyone’s
Twitter experience is unique to them and their community. For me, it’s
the main way I stay in touch with my Open Source / HTTP / API / Hypermedia
bubble and some friends. Losing that would suck! Unfortunately, there’s no way
that group would all flock to another platform.

But for the ones that do try something else, the talk of the town seems
to be Mastodon.

Mastodon is interesting. On the surface it might just seem like a
Twitter clone, but it’s based on a federated protocol called ‘ActivityPub’.
What this means in practice is that there’s no central server. There’s
many instances. Each of these instances
is managed by different people, and many of them focus on specific interests.

With email, it doesn’t matter which provider you go with Thanks to universal
SMTP standards that every server uses, you can exchange messages with everyone
else. This is the same with Mastodon. You’re not siloed into a single instance,
and you can follow people from any other instance. Unlike email, it appears
that with Mastodon you can actually migrate to different instances if you don’t
like your current one.

This has some interesting side effects too. I joined the
IndieWeb instance, which is a community I already
loved. And even though I’m not siloed in, I get access to a local feed of
like-minded people from that community. Everything feels new and more
intimate.

Also, instead of one central authority that you have to trust to make the right
moderation decisions, you can join one of many that aligns with your values,
and you can block entire instances that don’t.

So should you join? If you use Twitter to stay on top of news and follow high
profile people then probably not. If you’re like me, you might be able to
find a community that fits your interest.

Will I stick to this? Who knows… but Twitter, like everything before,
will fall out of favor one day and I’m enjoying Mastodon’s ad-free, open source,
developer-friendly experience. Reminds me of early Twitter or mid-2000’s
blogging culture.

Lastly, one of the interesting results of Mastodon building on open protocols,
is that it allows alternative implementations.

The Microblog.pub project lets you self-host a
single-user instance. Instead of joining some large instance, you deploy
an instance on your own domain that’s just for you. Can’t get more control
than that, and this might be something I’ll consider in the future.

I don’t see why this blog couldn’t one day also be a ‘microblog’ and part of the
fediverse.

PHP 8.2.0 RC5 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the fifth release candidate of PHP 8.2.0, RC 5. This continues the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki.For source downloads of PHP 8.2.0 RC5 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version.For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.The next release will be the sixth release candidate (RC 6), planned for Nov 10th 2022.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

PHP 8.2.0 RC 4 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the release of PHP 8.2.0, RC 4. This is the fourth release candidate, continuing the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.2.0, RC 4 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the fifth release candidate (RC 5), planned for 27 October 2022. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.