Engineering Team Lessons from Cycling
Cycling provides interesting examples for software development. It’s possible to race individually or in teams. A group that’s an effective team will outperform the same group acting as individuals every time. Teams compete towards a goal, and also against the environment, and many other teams, all with their own tactics, all at the same time.
Ensemble working provides an Advantage
Cycling teams working together in a paceline can travel significantly faster—via the aerodynamic advantage of drafting the slipstream of the rotating leading rider.

Software teams can build more stuff if each person works independently, than when working together. However, they’ll reach a team goal the fastest through working together, on the same stuff, at the same time, via pair or ensemble programming.
Having all the perspectives, experience, and expertise available at the point of meeting resistance from unknown challenges, results in a sort of aerodynamic advantage. We get stuck for less long, and overcome obstacles more easily.
A pair may not be twice as fast at shipping stuff as two people, but shipping stuff is not important. Working together they’ll achieve a goal a bit faster. Our goals have a cost of delay. The ability to ship a capability with associated revenue significantly faster, more than makes collaborative working worthwhile.
Individual working provides an Advantage
Cycling teams are comprised of multiple people, they can send riders back for hydration & energy food. They can send riders ahead to mark breakaways and mitigate the risk of the breakaway succeeding at remaining ahead until the end of the race.

Software teams that are paying attention, will see side opportunities & risks that are tangential to the main focus but too big to ignore. Often it helps for one or two people to go after them. Builds getting slow; someone peels off from the group to go fix that. Competitor launched a new product; someone peels off to explore how it works and whether should this change our plans.
Competitive Market
Unlike many pitch team sports where teams compete head to head, cycling teams compete against several other teams, at the same time. Each competitive team will employ their own tactics. Some teams may be more interested in overall win, or other incentives available such as intermediate sprints. Tactics have to take into account all the competition, not just a single opposing team. There are also environmental factors on the day such as wind and rain conditions, and the terrain.
Organisations building software are competing against many other organisations with directly or indirectly competing interests.
Sometimes it is advantageous to collaborate with the competition to conserve resources by working together. Cycling teams can work together to increase the chance of leading the race through a breakaway. Software builders partnering with competitors can build an ecosystem to grow the opportunity available to all parties.
Other times there’s an opportunity to get ahead of the competition by creating a break that your team is uniquely positioned to take advantage of.
Adapt to the riding conditions. Lightweight for climbing or Aero for flat. Wet or Dry. Similarly, as the economic climate changes, so do the tactics that are most successful for building software.
Dynamic Reteaming to Breakaway
Working together, a breakaway made up of individuals from multiple teams can stay ahead of the race. They must take their own share of the hard work in the wind, and communicate effectively. If they refuse to help each other, the breakaway will fail, and will be absorbed. Breakaways often fail when competing incentives and ineffective communication reduce their advantage over the main peloton.

There’s often a need and benefit to pulling together or self organising temporary short lived software teams. They can effectively chase an immediate goal that doesn’t neatly map to the existing team structure.
Dynamic reteaming can be far more effective than dependencies between teams, and like a breakaway it can rapidly get ahead of what an unchanged organisation structure could achieve.
Temporary teams also often struggle to communicate as effectively as a well established team; lacking the trust that comes from experience working with each other.
Marginal Gains Add Up
A clean well-lubricated chain could save you 5 watts, adding up to several seconds advantage over a race. Small tweaks to fitness training habits every day can add up to an advantage over a season.

Software teams often underestimate how quickly small investments in their own effectiveness cumulatively create an advantage. Time spent making your deploy pipeline a couple of minutes faster, or time automating manual onboarding steps. The wins from these add up over time to help you outpace the rest.
Specialists
You need specialists: climbers & sprinters. The rest of the team help get them in position at the right time for the challenges that they can best help with. Get your sprinters to the front of the race with a leadout in time for the sprints. Do the hard work to protect your race-winner’s ability to take advantage of a tactical opportunity when it comes. However, everyone needs to finish the race. Sprinters must be able to get over the mountains within the time limit.
Effective software teams have a mix of generalising specialists. They can all muck-in with whatever needs to be done towards the team goal. There’s also huge value to having the person with expertise in building UIs, the person with Data Science expertise, or the person who’s scaled databases. The right specialists enable help the team to overcome challenges.
Support Staff
Teams need support staff. If riders had to stop and repair their own mechanical issues, or carry their own food they’d be far slower.
Engineering teams benefit from internal platforms, and developer experience tooling support functions. Invest a portion of your budget in these.
Beware Incentives
Unglamourous work is essential to team success. Teams are ruined if everyone tries to go for the win.
Cycling teams need domestiques who will protect the leaders and fetch food. Software teams need people who’ll do glue work. People who help the whole team communicate. People who remove the friction slowing the team down.
Organisational incentives often risk this essential work and destroy the potential of teams.
Incentivise each of your riders to go for the win and the team will fail.
Incentivise each of your developers to chase promotions and compensation increases, on the basis of their individual impact, and your team will be ineffective.
Incentivise each of your developers to chase promotions and compensation increases, on the basis of their individual impact, and your team will be ineffective.
Work Sustainably
Pace yourselves. Only go all out when there’s a need for it, or you’ll not have the energy when it is needed. There’s a sprint at the end of the race. There’s another stage tomorrow. Don’t drop out.
If you are successful, there will be production incidents and customer crises to handle. These will take your energy reserves.
If you run at 100% every day you’ll have nothing left to give when there’s a real need.
The post Engineering Team Lessons from Cycling appeared first on Benji's Blog.
One does not simply deliver software
I was startled from my reverie by a shout, as this gentleman attempted to clear dawdling tourists such as myself out of his way.
I watched with bemusement but resisted the urge to offer to help—knowing the eye-watering value of Murano glass therein.

He eased the precious cargo over one step at a time. The cart—heavily laden with boxes of fragile glass secured with a flimsy strap—wobbled precariously over every step.
The sun baked the scene in an intense 40 degree furnace, like the one whence the glass came. Bump. Wobble. Heavy breathing. Bump, wobble.
Deliveries here are hard and risky work. Irreplaceable unique craft pieces, one mistake and they’re lost forever.
Too many teams suffer through building software like this: crafting a big batch of artisanal changes. Loading up a big batch to deliver to customers.
many teams suffer through building software like this.
We suffer through risky deployments, fearful that any mis-step may lead to disaster.
We optimise our delivery, each engineer efficiently delivering as much as possible; piling our carts high.
We plan our routes using detailed road maps and follow them religiously, fearful of the consequences of deviating from the route we filed.
Sadly, delivery is an accurate metaphor for many teams’ approach to building software. Software development doesn’t have to be like this. Delivery is a poor metaphor for effective software engineering.
Software is not delivered like packages of pre-made goods. Software is crafted, nurtured, and discovered. Software is grown like a garden. Software is supplied like water or energy. Software is improved through experimentation like knowledge.

Delivery logistics can be optimised for efficiency & throughput. Software needs learning and discovery. Efficient delivery prevents outsized outcomes—efforts to eliminate wasteful deviations from plans limit teams. At very best they’ll achieve only the outcomes they were able to foresee in advance.
Efficient delivery prevents outsized outcomes.
At very best they’ll achieve only the outcomes they were able to foresee in advance.
Deliveries can follow planned routes along road maps. Software development is more like exploring an area with a sat-nav. You have a destination in mind but can adapt your route given unforeseen traffic conditions. You can choose to explore things that pique your interest along the way without losing sight of the goal.
Delivery is risky; if you destroy or lose a package it’s gone forever, you can never get it back. Software change can be made low risk and boring if we’re willing to invest in the technical practices, architecture, and tooling to make it so.

Delivery is done when the package reaches its destination. A software change reaching customers is only the beginning of the learning loop. What was the effect of the change? Did it do what we expected? Is there anything that surprises us in the impact on the rest of our production systems? Is it being used in the way we expected? What have we learned about the needs of our users to inform what we do next? Is it valuable or should we undo the change? What was hard about the change and how do we make it easier to do the next?
Beware the influence of the metaphors we use upon the ways we think and work. The language we use affects how we act. We can do better than delivery.
The post One does not simply deliver software appeared first on Benji's Blog.
Electron Apps Blank on openSUSE Tumbleweed
openSUSE Tumbleweed – Review of the week 2023/41
Dear Tumbleweed users and hackers,
This week, we have published four snapshots; number 5 is in the process of syncing to the download infrastructure, but it seems to be taking slightly longer than it would.
The four snapshots (1006, 1008, 1010, and 1011) brought you those changes:
- NetworkManager 1.44.2
- Shadow 4.14.1
- Linux kernel 6.5.6
- Qt 5.15.11
- LibreOffice 7.6.2.1
- LLVM 17.0.2
- Node.JS 20.8.0
- gpg 2.4.3
- libcue 2.3.0 (CVE-2023-43641)
Snapshot 1012 is currently syncing out and will contain cURL 8.4.0, which is fixing CVE-2023-3854
Other than that, you can expect these changes in the next few snapshots (depending on QA results of course):
- KDE Gear 23.08.2
- zypper 1.14.66
- Freetype 2.13.2
- binutils 2.41: all flavors of rust fail to build
- moving to dbus-broker
Leap 15.5 issue with Radeon RX 7000 series and amdgpu driver
Upcoming Quarterly Update 1 for SLES 15 SP5 contains Bug 1215802.
This update will make its way also to Leap 15.5 users, since SLES and Leap starting by 15 SP3/15.3 share the same kernel.
Bug 1215802 says openSUSE Leap 15.5 systems with AMDGPU driver and Radeon RX 7000 series could experience a boot freeze with kernel-default 5.14.21-150500.55.28.1. Based on the discussion it seems like issue does not happen if the latest avaiable kernel-firmware-amdgpu is installed. Comment says as long as user applies all updates, this problem should not happen.
In case you’ve already installed update and your system fails to boot, you can boot your system by a passing nomodeset option to the kernel in grub and ensure you have latest kernel-firmware-amdgpu. Alternatively, you might want to consider using snapper to rollback the update.
We highly recommend Leap 15.5 users to postpone further kernel update until the situation in Bug 1215802 is further clarified and potential fix (if needed) is released. The best case scenario is that no action is needed, and everything works as long as the user installs all available updates.
GPG, RubyGems, Kernel update in Tumbleweed
Snapshots of openSUSE Tumbleweed this week had a variety of package updates.
Both Mesa and ImageMagick, were among the packages updated both this week and last week in the rolling release.
The latest snapshot, 20231011, made some significant changes with the gpg2 2.4.3 update. The package installs internal executables in the /usr/libexec directory instead of /usr/lib64. The internal executables include daemon keyboxd, scdaemon, user authenticator gpg-auth, ` gpg-pair-tool` and more. The updated GPG also provides systemd-user files, which were removed upstream since version 2.4.1. The video acceleration package libva 2.20.0 enhances AV1 encoding, refines Direct Rendering Manager array handling to prevent out-of-range issues, and adds support for crop and partial decode JPEG. GNOME’s screen reader Orca, which provides accessibility for graphical applications through speech or Braille, updates to version 45.1. The package corrects a regression in bookmark support and fixes a bug that caused Orca to present custom widgets as images when it shouldn’t. German, Brazilian Portuguese, Indonesian and Catalan languages were updated in a yast2-trans update. Several other packages were also updated in the snapshot.
Snapshot 20231010 updates NetworkManager-applet to version 1.34.0, which include fixes for a crash when importing WireGuard connections and the package streamlines dependencies and translations. A large update for rubygem-rubocop 1.56.3 addresses issues such as false positives and negatives for various cop rules, enhances the accuracy and reliability of rubocop in code analysis. The package also optimizes the performance and functionality of the Ruby code style checker. An update of clipboard manager for the Xfce panel, xfce4-clipman-plugin, updates to version 1.6.5 in the snapshot. The package has changes like hiding certain settings for Wayland, adds D-Bus call support with the set-text action, makes the clipboard manager an interface with both Wayland and X11 implementations and fixes a memory leak. The Hewlett-Packard image and printing package hplip 3.23.8 update includes support for a wide range of new printers that include models like the HP Color LaserJet Pro MFP 4301 series, 4302 series, 4303 series, and various other HP DeskJet printers. A few other RubyGems packages were updated in the snapshot.
The Linux Kernel was updated in snapshot 20231008. The 6.5.6 kernel-source version has fixes related to Network File System error handling, O_DIRECT flag scheduling and locking issues. The Linux Kernel also addresses issues in media drivers, netfs, ext4, netfilter, Advanced Linux Sound Architecture for Embedded Systems and more. An update of NetworkManager 1.44.2 in the snapshot improves IPv4 Address Conflict Detection (ACD) logging. The package addresses issues related to generating connections with the IPv6 method disabled, enhances documentation and now uses explicit release tags. An update llvm17 17.0.2 has changes to maintain Application Programming Interfaces and Application Binary Interface compatibility with with LLVM version 17. The update of nodejs20 20.8.0 improves stream performance and does a rework of memory management in the Virtual Machine APIs as it relates to the importModuleDynamically feature. The package also includes updates to the test_runner, which now accepts testOnly in the run command, The update of LibreOffice 7.6.2.1 addresses document layout issues, image rendering, compatibility, and more. Several other packages were updated in the snapshot including gnome-control-center 45.0+34, which addresses issues such as editing connections without a device and resolves a crash in the firmware security page.
A Common Vulnerability and Exposure was addressed by ImageMagick in snapshot 20231006. The 7.1.1.19 version of the image editor doesn’t provide a description for CVE-2023-5341 other than saying it has moderate severity. The package also eliminates some warnings and compiler issues and addresses issues related to BMP file size checking and XMP profile validation. An update of GNOME Character Map gucharmap 15.1.1 changes to update Unicode version 15.1.0 and adds launchable information to metainfo. The project also removed a defunct mailing list. The essential utilities package shadow updates to version 4.14.1 in the snapshot. This update primarily addresses build system issues to resolve linker problems, particularly noted in Gentoo. Additionally, Alejandro Colomar has been added as a new stable branch maintainer to shadow.keyring. A few Python Package Index updates were made as well as updates to libXrandr and sg3_utils.
The snapshot toward the end of last week that came out just after the blog post update was 20231005. This snapshot brought Mesa 23.2.1, which implements the OpenGL 4.6 and Vulkan 1.3 APIs and brings some new extension features. An update of terminal emulator xterm 385 updates tables based on Unicode 15.1.0 and enhances the configure script. The 3.4.3 icewm version adds a preference for showing window titles in icon-only task buttons, adds support for tabs to switch between open windows and introduces a -f, --fork option for icewmbg to detach it from the terminal. Other software packages were updated in the snapshot including a few Xfce packages and an update libvirt 9.8.0, which enhances its support for network disks by using nbdkit as a backend for network Input/Output.
The syslog-ng Insider 2023-10: contribute; parallelize; compatibility;
The October syslog-ng newsletter is now on-line:
- Why contribute to syslog-ng upstream?
- Accelerating single TCP connections in syslog-ng: parallelize()
- Backward compatibility in syslog-ng by using the version number in syslog-ng.conf
It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2023-10-contribute-parallelize-compatibility

syslog-ng logo
Leap Micro 5.5 availability and Leap Micro 5.3 EOL
A new version of the modern lightweight host operating system Leap Micro 5.5 is now available. All documents including Release notes from SLE Micro 5.5 documentation space are also applicable for Leap Micro, as Leap Micro is essentially a rebranded SLE Micro.
It’s important to mention that this also means that Leap Micro 5.3 is now End of Life (EOL). Users of Leap Micro 5.3 are strongly advised to consider upgrading to either the Leap Micro 5.4 or 5.5 release. This ensures access to the latest features, security enhancements, and ongoing support.
One of the standout features of Leap Micro 5.5 is its SELinux enhancements. Security-Enhanced Linux (SELinux) has received a significant boost. It brings podman-docker and hyper-v support for AArch64 for a more robust and secure computing experience for users.
Leap Micro 5.5 has podman 4.4 which introduces podman quadlets. If you haven’t tried quadlets yet, please make sure to check our Nextcloud deployment using quadlets. We also ship podman-docker, which is a podman wrapper that can be used together with docker-compose, or at least once the fix for Bug #1215926 is released for SLE and Leap Micro.
Cockpit 298 container management interface noticeably matured, as I’m finally able to use Cockpit to manage all of my home workloads.

Users new to ImmutableOS space (systems with read-only /root) are advised to read transactional update guide. Users can also use Toolbox to install additional software without a need to reboot into a new snapshot, this comes especially handy for debugging where the reboot is not an option.
We’ve made a short YouTube playlist with a few tutorials on how to put Leap Micro to practical use at home.
Wayland Display Server on openSUSE Tumbleweed in 2023
Innovation Marathon Hack Week Set for November
Hack Week 23 is set to blaze a trail of innovation this November.
This annual tradition started in 2007, this annual tradition, which somehow made up the difference for the number of the event to now, mirrors the year; it brings together SUSE employees, openSUSE contributors and open-source developers and enthusiasts from around the globe together for a week of uninterrupted experimentation and boundary-pushing.
This year’s Hack Week is scheduled from Nov. 6 to 10 and participants are gearing up to harness their collective creativity to innovate, contribute and expand the open-source landscape.
SUSE employees step out of their regular roles to embark on a week-long journey of collaboration, innovation and socialization. This year’s Hack Week promises to be a dynamic convergence of talent, expertise, and passion, as hackers collaborate across teams and continents to push boundaries of technology.
Hack Week is more than just a coding marathon; it’s a testament to SUSE’s commitment to nurturing open-source collaboration across the globe. Participants bring a diverse set of skills, knowledge, passion and perspectives to build and develop something new; this fosters an environment where creative ideas flourish and solutions take shape.
Past Hack Weeks having produced groundbreaking advancements and disruptive innovations. A few to mention are openQA, Aeon (formally known as MicroOS’ GNOME Desktop) and Weblate, which is used by openSUSE for translations.
While the global open-source community eagerly anticipates the commencement of Hack Week 23, individuals are already gearing up by compiling lists of projects they intend to undertake or contribute to.
Stay tuned to SUSE’s official communications channels and social media platforms for updates, announcements, and a front-row seat to the action as Hack Week 23 takes center stage this November.
