As Pale As A Sheet

»As pale as a sheet, « I thought while watching my customers, the CEO and the project leader, who shifted nervously on their chairs. They were sitting to my left and right. Opposite me sat the leading developer of their only product. Totally unexpected, he had suddenly found the love of his life and decided to quit the company and relocate to a faraway place.

I was invited to interview the developer to determine what information was still missing during the handover to new employees who had recently joined the company and were not very pleased about facing an intensive phase of drinking from the firehose.

The meeting was scheduled for about an hour. It was clear that this was an emergency, so I decided to play it nice, not ask about software development processes, and did not put a CMMI questionnaire on the table, but instead asked simple questions like, e.g.

• Where do you store passwords? (“Nowhere, they are all in my head.”)
• How do you shut down and restart the production system (“That’s a 30-minute procedure where you manually generate and upload new container images to Azure, but we also run some VMs and some of them on a different hoster, for some, I am not sure whether we really need them.”)
• Is there an architecture diagram? (“No”)
• Is there a comprehensive list of all software components that are active in production and their corresponding repositories? (“No”)
• For the REST APIs in use, is there an OpenAPI specification? (“We deactivated autogeneration based on OpenApi files and did it manually.”)
• Is there any documentation about the REST APIs in use? (“There used to be a Word document, but it’s outdated. Read the code. It’s all there.”)    

This went on for about three hours. »As pale as a sheet, « I thought while watching my customers, and rightly so. Luckily, I had taken notes on my laptop, approximately 15 pages of issues to be clarified.

It was apparent we had a huge bus problem. The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase “in case they get hit by a bus”.

Guessing from the color of my customers’ faces, I derived that I did not have to share the story of a good friend who was hit by a stroke that led to a total aphasia. He eventually recovered and regained his speech, reaching a level where his struggle to find the words was only noticed by people who knew him before. The only data that never came back were all his passwords. My customer no longer needed to hear this story.      

On that day, the only thing I asked for was for the developer to make me an additional administrator of all systems (of all systems). Everyone was deeply exhausted, but I felt energetic to an extent that seemed inappropriate. So I kept that inside.

A Deep Crisis Ahead

Having access to all repositories, my software archaeology project started on the same evening.

To add to the problem we were already facing, the code quality reflected the absence of any kind of product strategy, development processes, or application of best practices, let alone common sense.

The client informed me they were facing significant operational challenges. Over the years, their software stack had grown through an unstructured, ad-hoc approach, which was further exacerbated by high staff turnover. The result was a system plagued by errors and instability, leading to massive customer dissatisfaction and developer frustration.

From looking at the code, I could confirm they were in big trouble.

Nothing to Lose

Having nothing more to lose gives you some freedom to take unorthodox measures. You can only win, because if you fail, no one can blame you, given the starting point where you joined.

I had been there before (create a working software solution in ten weeks for a piece of software that a team of five had failed to deliver within 3 years), but this time I perceived the task to be different. This was not a pure rescue action; it was more. I had the responsibility to create a genuinely sustainable solution, and for that, I had to develop a vision for how to enable the team. It turned out that the person who left was challenging to communicate with (surprise, surprise). Some team members had lost all hope, but to me, they appeared to be “good citizens” who only needed someone to give them a little direction and hope.    

Since other developers had very recently joined, we had a considerable opportunity to form a new organization and set some things straight from the beginning.      

The next morning, I called the CEO and asked whether the current system was not in too much danger of failing immediately. He confirmed that the house of cards the company was built on showed some singularity in time and space and could run if (and only if) someone was restarting the whole system from time to time - as we had already learned, a tedious and manual process.

That was the point in our discussion where I requested a complete halt to all development activities. I needed the whole team to pursue my idea. The plan that I was going to propose was as follows:

1. Collect all accounts and passwords and put them into a password database.
2. Document how the productive system could be shut down and restarted. The definition of done was something along the lines that a completion was reached when a person who had never heard about software development and had zero technical background could perform the task simply by reading the manual. We already had such a person on board: the CEO.    
3. Completely document the source code repository structure, i.e., add a README to every repository that explains what the code was meant for, its maturity level, and whether it was actually part of the production system.
4. Completely document the current system and all software components.
5. Completely document the REST APIs in a machine-readable format, preferably using OpenApi v3 documents under version control.
6. Create some kind of architectural documents
7. Perform a deep source code analysis and make an improvement plan.    

Luckily, I got a green light on the very same day.

Wiki Forever

To enable the team, I provided clear direction on how to work collaboratively on the documentation.

After more than three decades in software development, I have reached the conclusion that the tools a company adopts not only reflect its culture but also actively shape it over time. I considered the choice of tools to be critical and was eager to find tooling that did not require a significant amount of education and was easy to use.

The first deed was to create a new git repository dedicated to holding all our documentation. I believed the accessibility and ease-of-use of the chosen documentation was crucial for our success, so I decided to go with a GitHub Wiki inside a GitHub repository.

The plan was to put all files, such as API definition files, under version control and subject them to a review process via pull requests, and to utilize wiki pages for all regular documentation. The intuitive graphical user interface of the GitHub Wiki and the minimal set of markdown features available for generating documentation helped to have everyone clearly instructed within a couple of hours.     

Because wikis are Git repositories, every change you make is a commit that you can (re-)view. Ultimately, the GitHub wiki is essentially a Git repository containing Markdown files. So, late at night, when no one was editing, I was able to pull the whole system onto my disk and perform some editorial work, like, e.g., cleanup, fix formatting errors, create consistency, reorganize documents, and push all changes back, so that everyone would find a clean environment the next morning.

Markdown has the advantage that it is easy to learn, allowing people to focus on content instead of wasting time on formatting issues. Based on the immediate feedback the team received from each other and from me, best practices for editing emerged within days.

Success is a Team Effort

Over the following two weeks, we scheduled video conferences where the “bus problem” developer presented the entire system landscape and performed a live session for the shutdown and restart of the production system. The team then took the video recording, worked through it, and then tried hard while he was watching until they were able to do the same things. Then they put that information into the wiki.  

In the meantime, I had my own interview sessions with the individual and provided him with a list of information I would like to obtain. So he dug out some office documents from somewhere on his laptop (no backup) and shared them on a Google Drive. I collected the data and converted everything to new wiki pages using the Swiss Army Knife of document format conversions, pandoc.    

Initially, some team members were hesitant to use a wiki instead of a traditional text processor, but as the documentation evolved and they discovered how easy it was to correct errors, refine the text, and link to other sections, they became more comfortable with it.

Initially, it was I who, during meetings where people verbally shared new findings about the system, asked, “Have you put that piece of information in the wiki?” and persuaded them to share all their knowledge there, regardless of its importance. A couple of weeks later, the project manager called me and told me that I was no longer required to attend all knowledge exchange meetings: “You know what?” he said, “They start to ask each other exactly your question and they really mean it and they are really motivated and behind it all day long.”

I watched the wiki grow in size and quality during the following weeks.

After several internal tests with the project manager, they finally held a session where the CEO shared his screen, going through the Wiki document that explained how to shut down and restart the production system. It was a great success.  

My contribution to all this was a set of 70 action items for the next two years to further clean up the codebase and introduce proper Testing, Continuous Integration, and Continuous Deployment, as well as complete automation and code generation from interface specifications.

Together with a vast number of documentation tasks, we created tickets for each of them and assigned them to the appropriate team members. All was clearly visible in the cross-repository Project view, featuring a Kanban board which could be filtered for certain aspects and per assignee.

That was helpful for our daily standup. Yes, it came naturally to introduce agile best practices. I did not tell them it was Agile, though. Leave out the buzzwords, find out what works.

The next day, I got a call from my customer. They said

We always had a bad feeling about the whole system, but we couldn’t clearly identify what it was. We were also quite unhappy with the way our work was organized, as no one had an overview of what was happening within the team.

You opened our eyes and gave us a clear vision of how to go on. And this lean project management tool is quite cool.

Reflection

The person who left the company was actually quite intelligent. Yet, the work products he left behind were a real mess. I have questions about the overall system’s architecture. The code quality was not at the level it could have been.

So, what had happened here? What led to the mess? Why was there no structure? Why did they fail to organize themselves? And, since I am as German as German can be, the most important question is: Who is to blame for this? 😉    

Neil Kandalgaonkar once put it this way¹:

Some people blame incompetent developers for cursed code. But the most cursed code is caused by highly competent developers. You just have to give them a task in a team that has the right kind of organizational dysfunctions - poor communication, power imbalances, diva designers or managers, unclear decisions. Where the incompetent developer would just fail, the highly competent developer will deliver an eldritch monstrosity - that works. Just don’t ask how it works.

This statement is quite on the spot. In the case discussed here, I think that several factors contributed to the situation:

1. A lack of true leadership:

   After all, it is always about the management. Management is to blame for everything. Really, I mean it. If managers fail to communicate purpose, prioritize, provide direction, and have an overview of what is happening within their own company, then they are doomed. Highly skilled developers can only partly compensate for a lack of true leadership.

   It is worth noting that the CEO was a person who was very reluctant to make decisions while everyone was still waiting for his advice and input.

2. A lack of experience:    

   If you do not know how to set up a development process, if you have never learned about best practices for project management or for how to keep track of all tasks, then how are you going to survive facing a constant stream of requirements changes, incidents in the field, and trouble in the production system?

   It also becomes problematic when people who have never developed software and never engineered a system are the ones who decide how the work is organized. I disagree with those who think that good managers are not required to know the problem domain the engineering team is addressing.    

   For software, many good ideas on how to set up a development process emerged over the past decades. Except Scrum. Simply do not use Scrum. Using it only reveals your lack of experience². This is not the future you are looking for³.  

3. A lack of appropriate tooling:

   As outlined in another post, tools that generate more work by requiring significant administrative effort than they help reduce through their feature set can ruin your day.     It is incredible to watch people come to the aha effect while using reductionist tools like the GitHub ticket system and its lean project views instead of a full-blown JIRA/Confluence instance or office suite.     It always makes my day when people who used to drown in a never-ending stream of e-mail threads and a mass of documents on a shared drive finally learn that information can be shared in small text snippets under version control. I celebrate when they finally grasp it and fully understand the benefits of centralized knowledge management.      

This is Not Real

• Are you sure?
• Do you make backups?
• Can you recover data from the backup you made two months ago?
• When was the last time you did this test?
• What happens if the data center gets flooded?
• Do you host a centralized password database with dedicated user access control and clear instructions about every password being stored exactly there?
• Do you have a backup of your centralized password database?
• What happens if the data center gets flooded? Do you still have a backup of your centralized password database?
• Did you make sure the password database backup is encrypted? Who holds the key to decrypting it? What happens when she gets hit by a bus?  
• How many different documentation systems do you run in parallel?
• Is your wiki up-to-date?
• Is every artifact the team has ever created documented?
• Do you have a centralized overview of who is working on what in your company and why?
• How large is the portion of maintenance effort that goes into the tools you use?  
• Do you have a development process?
• Do you think your development process is efficient?

Meta Questions

• Do you put individuals and interactions over processes and tools?
• Do you put working software over comprehensive documentation

Final Question

Would you like me to come to your company and ask some more questions about how you organize your work until you are as pale as a sheet?  

I am going to put music in your pocket […] somewhere between 500 and 1000 songs right in your pocket cuz I can’t stand looking at that inexplicable Walkman anymore. You’re carrying around a brick playing cassette tape. We’re not savages!

You’ve got to start with the customer experience

Steve Jobs once said the following wise words about product design:

You’ve got to start with the customer experience and work backwards to the technology.

You can’t start with the technology and try to figure out where you’re going to try to sell it and I’ve made this mistake probably more than anybody else in this room and I’ve got the scar tissue to prove it and I know that it’s the case and as we have tried to come up with a strategy and a vision for apple it started with “What incredible benefits can we give to the customer? Where can we take the customer?” not starting with “Let’s sit down with the engineers and figure out what awesome technology we have and then how we’re going to market that!” and I think that’s the right path to take.

Through painful errors for which I had to pay high prices, I found out that this is easier said than done. You are always wiser after giving an idea a try¹.

I am going to put music in your pocket

Despite the specific dialogue being fictionalized for dramatic effect, and while this film scene in this exact form never actually happened, this movie scene from the movie “Steve Jobs” captures the emotional tension and key facts of Jobs’ relationship with his daughter Lisa:

At a critical point in the conversation, Steve Jobs finds no other way to express his love but by making a promise about key features of a product that had not even been worked on yet².

Your design reflects your personality

What strikes me about Steve Jobs is his profound impact on Apple’s products, even years after his death and more than ten additional generations of the iPhone. On the positive side, there is an astonishing number of key features of that product that confirm the customer experience drove the product design³. In stark contrast to this, one can also observe that the much darker parts of Steve’s spirit are very much alive in those tiny boxes (and their larger tablet counterparts).

And those are all about sharing.  

To say it nicely: Sharing was not Steve’s primary concern. Taking advantage of the help provided by others was⁴.  This reflects in many facets of Apple’s products and ecosystem.  

Steve Jobs initially denied paternity for his daughter Lisa after her birth in 1978, even publicly rejecting that Lisa was his daughter and disputing the DNA test results. He even refused to provide financial support for Lisa and her mother, Chrisann Brennan. And he went beyond that. At one point, when Chrisann asked Jobs to buy a house for herself and their daughter, he toured the property she had in mind; however, he ultimately purchased the home for himself and his new wife, Laurene Powell Jobs⁵.

Now, let’s examine Apple’s product landscape.

• You have that glossy iPhone or iPad at home? Well, iOS does not support multiple user profiles, making family sharing impossible for individuals who value privacy or data protection. Notice that the product design forces you to share all your data if you want to share your device. But why?

  Not exposing all your data to others, even within your own family, is a matter of responsibility. Your kids should not have insight into all of your communication, especially when a close friend sends a note about severe medical conditions (been there, seen that).  

• Ever tried to share that photo you made with your friend immediately? What if she does not possess an iPhone because she is a true professional and prefers the User Experience and configurability of an Android system? Hmm. The AirDrop protocol is proprietary. Even when reverse-engineered, it is not officially supported on Android devices, and Apple retains the power to restrict or modify these protocols at will, creating future barriers for interoperability.

  

  Cannot share your memories? (generated with Perplexity)
• Observe how Apple⁶ fights back on any regulatory attempt to enforce interoperability among devices. We are lucky enough that they could not prevent the EU common charger rules.
• Despite the widespread use of open-source components in the underlying operating systems—such as the Mach kernel in iOS and macOS—Apple has an ambivalent attitude towards the Open Source idea. Andrew Hyatt⁷ put it this way:  

  Apple Open Source is truly a strange beast. In many ways, it portrays Apple as a company that values open source and wants to give back to the community. But in many ways, it falls short of this and represents an effort to look like they care about Free & Open Source Software.  

Corporate personalities and their strategic choices can profoundly influence the characteristics of the products they create—shaping the user experience far beyond mere hardware and software design.

Let us acknowledge Steve Jobs’ remarkable achievements, while also not forgetting the challenges this world faces due to his shortcomings.

It’s all about me

And this is all about me. The most challenging question I have to ask myself is, to what extent my history, my brightness, and my darkness continue to influence the way I write software, the architecture I propose, how I shape products, how my way of thinking is reflected in the user interface and the user experience of all that I design.  

To give you one example: For what reason is the Ducktrain vehicle body made out of canted and riveted metal sheets? Was ist a good decision? At the time I made the decision, it appeared so. Of course, it had nothing to do with my fascination with airfoils since I was ten and having studied Aeronautics. 😉      

Foto by JWM Media

Modern web development demands optimized images that load quickly while maintaining visual quality. The WebP format, developed by Google, offers superior compression compared to traditional JPEG and PNG formats, typically reducing file sizes by 25-35% without noticeable quality loss. This guide walks through converting images to WebP format and embedding copyright metadata using command-line tools on Ubuntu Linux.

Prerequisites

This tutorial assumes you’re running Ubuntu 22.04 LTS or newer with the following tools installed:

• ImageMagick 6.9.11 or higher for image conversion
• ExifTool 13.38 or higher for metadata management

Step 1: Converting Images to WebP Format

The first step is converting your existing JPEG images to the WebP format using ImageMagick’s convert or mogrify commands.

Why WebP?

WebP provides several advantages over traditional image formats:

• Superior compression: Reduces file sizes by 25-35% compared to JPEG at equivalent quality
• Transparency support: Like PNG, but with better compression
• Animation support: Can replace animated GIFs with better compression
• Broad browser support: Supported by all modern browsers since 2020

Basic Conversion Command

For converting a single file:

1
convert input.jpeg -quality 80 output.webp

The -quality parameter accepts values from 0-100, where higher values preserve more detail but result in larger files. A value of 80 provides an excellent balance between quality and file size.

Batch Conversion

To convert all JPEG files in a directory, use the mogrify command:

1
cd raw && mogrify -format webp -quality 80 -path ../new *.JPEG

This command:

• Creates the output directory if it doesn’t exist
• Changes to the source directory
• Converts all .JPEG files to WebP format
• Stores the output in the ../new directory
• Preserves original filenames with the new .webp extension

For handling both uppercase and lowercase extensions:

1
cd raw && mogrify -format webp -quality 80 -path ../new *.{JPEG,jpeg}

Step 2: Adding Copyright Metadata

After converting images to WebP, the next step is embedding copyright information into the file metadata. This protects your intellectual property and provides attribution information.

Installing the Latest ExifTool

Ubuntu 22.04’s default ExifTool version doesn’t support writing to WebP files. WebP write support was added in ExifTool version 12.46 (October 2022). To install the latest version from source, download Image-ExifTool-13.38.tar.gz or a newer version from https://exiftool.org/ and copy it to /tmp. Then issue the following commands.

1
2
3
4
5
cd /tmp
tar -xzf Image-ExifTool-12.96.tar.gz
cd Image-ExifTool-12.96
perl Makefile.PL
sudo make install

Verify the installation:

1
exiftool -ver

Adding Copyright Information

To add copyright metadata to your WebP files:

1
2
3
4
5
exiftool -overwrite_original \
  -Copyright="Copyright © 2025 Markus Werle" \
  -Artist="Markus Werle" \
  -CopyrightNotice="Copyright © 2025 Markus Werle" \
  assets/images/new/*.webp

This command sets three metadata fields:

• Copyright: The copyright statement with the proper © symbol (U+00A9)
• Artist: The creator’s name
• CopyrightNotice: An additional copyright field for broader compatibility

The -overwrite_original flag prevents ExifTool from creating backup files (.webp_original).

Handling Minor Warnings

You may encounter warnings like "[minor] Incorrect XMP tag ID" for some images. These warnings indicate improperly formatted XMP metadata in the original files and don’t prevent the copyright information from being written successfully. To suppress these warnings, add the -m flag:

1
2
3
4
5
exiftool -m -overwrite_original \
  -Copyright="Copyright © 2025 Markus Werle" \
  -Artist="Markus Werle" \
  -CopyrightNotice="Copyright © 2025 Markus Werle" \
  assets/images/new/*.webp

The warning doesn’t affect the functionality of your images or prevent metadata from being written. If you still feel inclined to fixthe XMP Metadata, you can rewrite their XMP tags to correct the formatting:

1
exiftool -xmp:all= -tagsfromfile @ -xmp:all problematic_file.webp

This command removes all XMP tags and rewrites them cleanly, which resolves the “Incorrect XMP tag ID” warning.

Step 3: Automated Script

For repeated use, the following bash script automates the entire conversion and copyright embedding process.

The Complete Script: to_webp_with_copyright.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
#!/bin/bash

# Script: to_webp_with_copyright.sh
# Description: Convert any image file to WebP format and add copyright metadata
# Author: Markus Werle
# Date: 2025-10-02

set -euo pipefail

# Constants
readonly SCRIPT_NAME="$(basename "$0")"
readonly REQUIRED_EXIFTOOL_VERSION="13.38"
readonly COPYRIGHT_TEXT="Copyright © 2025 Markus Werle"
readonly ARTIST="Markus Werle"

# Variables
INPUT_FILE=""
OUTPUT_FILE=""

# Function: Print usage information
usage() {
    cat << EOF
Usage: $SCRIPT_NAME -i|--input <input-file> -o|--output-file <output-file>

Convert any image file to WebP format and add copyright metadata.

Required arguments:
  -i, --input <file>        Input image file (any format supported by ImageMagick)
  -o, --output-file <file>  Output WebP file (will auto-append .webp if missing)

Optional arguments:
  -h, --help               Display this help message and exit

Examples:
  $SCRIPT_NAME -i photo.jpg -o photo.webp
  $SCRIPT_NAME --input image.png --output-file converted

Requirements:
  - ImageMagick (convert command)
  - exiftool version >= $REQUIRED_EXIFTOOL_VERSION

EOF
    exit 0
}

# Function: Print error message and exit
error_exit() {
    echo "Error: $1" >&2
    exit 1
}

# Function: Compare version numbers (semver compatible)
version_ge() {
    # Returns 0 (true) if $1 >= $2
    local ver1="$1"
    local ver2="$2"
    
    # Use sort -V to compare versions
    if [[ "$ver1" == "$ver2" ]]; then
        return 0
    fi
    
    local highest
    highest=$(echo -e "$ver1\n$ver2" | sort -V | tail -n 1)
    
    [[ "$ver1" == "$highest" ]]
}

# Function: Check if required commands exist
check_dependencies() {
    # Check for ImageMagick convert
    if ! command -v convert &> /dev/null; then
        error_exit "ImageMagick 'convert' command not found. Please install ImageMagick."
    fi
    
    # Check for exiftool
    if ! command -v exiftool &> /dev/null; then
        error_exit "exiftool not found. Please install exiftool version $REQUIRED_EXIFTOOL_VERSION or higher."
    fi
    
    # Check exiftool version
    local exiftool_version
    exiftool_version=$(exiftool -ver 2>/dev/null) || error_exit "Failed to determine exiftool version."
    
    if ! version_ge "$exiftool_version" "$REQUIRED_EXIFTOOL_VERSION"; then
        error_exit "exiftool version $exiftool_version is too old. Required: >= $REQUIRED_EXIFTOOL_VERSION"
    fi
    
    echo "Dependencies check passed: exiftool v$exiftool_version" >&2
}

# Function: Validate input file
validate_input() {
    local file="$1"
    
    if [[ -z "$file" ]]; then
        error_exit "Input file not specified. Use -i or --input option."
    fi
    
    if [[ ! -f "$file" ]]; then
        error_exit "Input file does not exist: $file"
    fi
    
    if [[ ! -r "$file" ]]; then
        error_exit "Input file is not readable: $file"
    fi
    
    # Check if ImageMagick can identify the file
    if ! identify "$file" &> /dev/null; then
        error_exit "Input file is not a valid image format: $file"
    fi
}

# Function: Prepare output filename
prepare_output_filename() {
    local output="$1"
    
    if [[ -z "$output" ]]; then
        error_exit "Output file not specified. Use -o or --output-file option."
    fi
    
    # Add .webp extension if not present
    if [[ "$output" != *.webp ]]; then
        output="${output}.webp"
        echo "Auto-appending .webp extension: $output" >&2
    fi
    
    # Check if output directory exists
    local output_dir
    output_dir=$(dirname "$output")
    
    if [[ ! -d "$output_dir" ]]; then
        error_exit "Output directory does not exist: $output_dir"
    fi
    
    if [[ ! -w "$output_dir" ]]; then
        error_exit "Output directory is not writable: $output_dir"
    fi
    
    echo "$output"
}

# Function: Convert image to WebP
convert_to_webp() {
    local input="$1"
    local output="$2"
    
    echo "Converting $input to WebP format..." >&2
    
    if ! convert "$input" -quality 90 "$output" 2>/dev/null; then
        error_exit "Failed to convert image to WebP format."
    fi
    
    if [[ ! -f "$output" ]]; then
        error_exit "Conversion completed but output file not found: $output"
    fi
    
    echo "Conversion successful: $output" >&2
}

# Function: Add copyright metadata
add_copyright_metadata() {
    local file="$1"
    
    echo "Adding copyright metadata..." >&2
    
    if ! exiftool -m -overwrite_original \
        -Copyright="$COPYRIGHT_TEXT" \
        -Artist="$ARTIST" \
        -CopyrightNotice="$COPYRIGHT_TEXT" \
        "$file" > /dev/null 2>&1; then
        error_exit "Failed to add copyright metadata to: $file"
    fi
    
    echo "Copyright metadata added successfully." >&2
}

# Function: Parse command line arguments
parse_arguments() {
    if [[ $# -eq 0 ]]; then
        usage
    fi
    
    while [[ $# -gt 0 ]]; do
        case "$1" in
            -h|--help)
                usage
                ;;
            -i|--input)
                if [[ -n "${2:-}" ]] && [[ "${2:0:1}" != "-" ]]; then
                    INPUT_FILE="$2"
                    shift 2
                else
                    error_exit "Option $1 requires an argument."
                fi
                ;;
            -o|--output-file)
                if [[ -n "${2:-}" ]] && [[ "${2:0:1}" != "-" ]]; then
                    OUTPUT_FILE="$2"
                    shift 2
                else
                    error_exit "Option $1 requires an argument."
                fi
                ;;
            *)
                error_exit "Unknown option: $1. Use -h or --help for usage information."
                ;;
        esac
    done
    
    # Validate that required arguments are provided
    if [[ -z "$INPUT_FILE" ]]; then
        error_exit "Missing required option: -i|--input. Use -h for help."
    fi
    
    if [[ -z "$OUTPUT_FILE" ]]; then
        error_exit "Missing required option: -o|--output-file. Use -h for help."
    fi
}

# Main execution
main() {
    # Parse command line arguments
    parse_arguments "$@"
    
    # Check dependencies
    check_dependencies
    
    # Validate input file
    validate_input "$INPUT_FILE"
    
    # Prepare output filename
    OUTPUT_FILE=$(prepare_output_filename "$OUTPUT_FILE")
    
    # Convert to WebP
    convert_to_webp "$INPUT_FILE" "$OUTPUT_FILE"
    
    # Add copyright metadata
    add_copyright_metadata "$OUTPUT_FILE"
    
    echo "✓ Successfully created: $OUTPUT_FILE" >&2
    exit 0
}

# Run main function with all arguments
main "$@"

Script Features

The script performs several tasks:

Argument Parsing: Supports both short (-i, -o, -h) and long options (--input, --output-file, --help) with comprehensive validation.

Version Checking: Automatically verifies that ExifTool version 13.38 or higher is installed using semantic version comparison with the sort -V method.

Comprehensive Error Handling: Validates all potential failure points including:

• Missing or incorrect command-line arguments
• Non-existent or unreadable input files
• Invalid image formats
• Missing or unwritable output directories
• Conversion failures
• Metadata writing failures

Automatic File Extension: If the output filename doesn’t end with .webp, the script automatically appends the extension.

Usage Examples

Make the script executable:

1
chmod +x to_webp_with_copyright.sh

Convert a single image:

1
./to_webp_with_copyright.sh -i photo.JPEG -o photo.webp

The script automatically appends .webp if omitted:

1
2
./to_webp_with_copyright.sh --input image.png --output-file converted
# Creates: converted.webp

Display help information:

1
./to_webp_with_copyright.sh --help

Verification

To verify that the copyright metadata was successfully embedded, use ExifTool to inspect the output file:

1
exiftool -Copyright -Artist -CopyrightNotice photo.webp

This displays the three copyright-related metadata fields you added.

TL;DR

In the second part of this article series, I will compare JIRA to one of its competitors, GitHub. The differences in architecture, data model, and UI design are striking. They reveal something very fundamental about software design and about company culture.

Disclaimers

• I am still waiting to get paid for praising some parts of GitHub. 😇
• I am disappointed with how GitHub continues to evolve after Microsoft acquired GitHub.
• This article is highly opinionated. Please let me know if you disagree on LinkedIn.

The Power of Minimalism

New Kid On The Block

A couple of years after starting my struggle with JIRA, I learned about another platform solution that had gained quite some attraction: GitHub. Getting to know GitHub in its early years, I realized something significant.

When it comes to software tools, simplicity often reigns supreme. GitHub, the popular version control and collaboration platform, exemplified this principle.

GitHub - A Multiverse of Good Design Decisions

While GitHub representatives probably never explicitly mentioned the KISS (Keep It Simple, Stupid) principle, the original GitHub design demonstrates a pragmatic approach that values simplicity without compromising functionality. I believe this to be a key factor in GitHub’s meteoric rise and in its becoming the number one place to go for Source Code Management.

GitHub’s success can be attributed to two critical effects of its minimalistic approach:

1. Ease of Learning: GitHub’s user-friendly interface made it accessible to experts and novices.
2. Reduced Complexity: GitHub minimized complexity by offering users a streamlined set of options. This simplicity allowed the platform to reach stability and maturity swiftly. Users could focus on their work without being bogged down by unnecessary features.

Ease of Learning

I had the chance to see how vital ease of learning can be on several occasions when I introduced GitHub to technical and non-technical staff simultaneously. As with a chemical reaction, it is crucial to collect sufficient activation energy to get things going.

Interesting enough, using GitHub’s web GUI to create content only requires a fairly low amount of activation energy. People who had never used a markup language to generate formatted text before needed less than an hour to understand how to write issues, READMEs, or Wiki articles.

For LaTeX text processing fans like myself, the number of features offered by GitHub Flavored Markdown (GFM) are way too limited. But this lightweight markup language can be learned fast by anyone who can read. Its simplicity encourages collaboration and documentation without the need for extensive training.

The positive effect is that non-technical and technical staff can share information via a common collaboration platform.

Reduced Complexity

GitHub’s interface doesn’t overwhelm users with unnecessary bells and whistles. It sticks to the essentials. This intentional minimalism prevents over-engineering and keeps the focus on what truly matters.

Note that GitHub is a tool built on top of one of the world’s most complex and powerful tools, namely Git. Git is like the Wenger Giant Swiss Army knife, but all you need is a blade, the nail file, the saw, and the scissors (git clone, git add, git commit, git push).

Source: Wikipedia

The GitHub GUI reduces the view of this powerful tool to the absolute necessary.

Issue States

Now, how many states can an issue have? Remember JIRA? Please count all possible “statuses” their documentation lists. I failed to enumerate them all in part 1 of this article series. In contrast, the number of possible states of a GitHub issue is at the theoretical minimum. It can exist in only two primary states: “open” and “closed”.

Of course, this is only half of the truth. As with JIRA tickets, GitHub tickets can have an arbitrary number of labels; from a formal point of view, these are sub-states. Or - to be even more precise - every GitHub issue has one additional substate: a set of labels that can be empty.

Can you spot the difference? The JIRA designers try to catch every possible view you can have on an item in one attribute - a common error in Object Oriented Programming. Finding the right location for the information to be stored has a significant impact on the scalability of the system itself. JIRA architects failed this task. You have to get structural containment right. The initial error led to further complexity: JIRA does not only have a rather large set of “Issue statuses,” but due to later extension of the system, it also provides additional sets of states: “Jira Software statuses” and “Jira Service Management statuses.”

Is that a complete set of possibilities now? While I was CTO of Ducktrain, we successfully used GitHub Issues for everything, even for the procurement process! How would we handle that in JIRA? Will JIRA extend the set of possible sets of possible “statuses”? Will we have “Jira Procurement Statuses”? Can you see the unnecessary complexity introduced in the system? Can you see Pandora’s box wide open? Is there a better way to map business processes to a ticket system?

Distinguish Data and Views

If you want a certain view of your data, create it! But as a system designer, never try to anticipate and map all possible future usage scenarios of your product into a finite set of states stored within the data items.

Let’s have a look at GitHub Projects. After a considerable launch failure due to a missing m-to-n relation in project views to repositories (which is fixed by now), we have a system that allows a specific set of views (called layouts), such as list views, Kanban boards, and roadmap views.

Interestingly enough, you can add metadata to an issue like dates or number fields. But this data belongs to the project and is not stored as an issue state in the issue itself.

The column in a Kanban board a ticket is assigned to is also some kind of metadata (an additional state the ticket is in, but not stored as a state within the ticket). Unsurprisingly, a ticket (aka issue) can be in different columns in Kanban views of several projects.

It appears that GitHub’s data model yields a more flexible product and is more robust against changes in the user story.

What was it made for?

The huge success of the Agile Movement may stem from its human-centric approach. If you are old enough, you might remember the wishful thinking of “Individuals and interactions over processes and tools” that never came true.

GitHub’s huge success may stem from its developer-centric approach or, more precisely, from its focus on the people who actually do the work, not the ones who supervise others.

There is tension between developers’ and managers’ needs. You can guess which party has predominance from the tools an organization uses. For example, extracting metrics and KPIs¹ is not something a developer needs. It’s what managers need to fake objectivity for their decision-making ² or to feel less insecure.

Don’t get me wrong. The tension between developers’ and managers’ needs does not mean managers’ needs have no right to be fulfilled. Having a clear picture of what is going on in your organization and knowing whether there is enough money to pay the next salary round is essential. Coordination between different entities in your organization might serve productivity and unveil potential for improvement.

You should be honest with and aware of the reason for a particular tool choice or tool configuration. Life is hard when a tool does not fit the task, but life is even more challenging if a tool is not used for its intended task but is abused by some people in your organization for supervision or command and control.

So here’s the question: What was GitHub made for? It was made for collaboration. It was made for coordination. It was made for documentation. It was made for traceability. It was made for source code management.

It was not made for command and control. It was not made for supervising. It was not made for performance tracking³. It was not made for people management.

As a manager, I love unified approaches. I love simplified structure and information that fits on a PowerPoint slide because that is what managers do. Three bullet points on a slide to ease tough decisions. Thinking linear, not thinking complex. It helps when I have 200 decisions to make every day.

Is that what ticket systems were made for? What was JIRA made for? Do you understand how its feature set reflects a particular management style and perspective on a company? At one of my customers, the quality team forced completely independent software development teams to align on their JIRA configuration, renaming states (!) to ease the acquisition of KPI data. This kind of behavior is the complete inversion of “Individuals and interactions over processes and tools”.

If you look at GitHub projects with a more critical eye, you can spot the small steps toward features that meet the needs of managers, especially in large organizations. For example, the original GitHub authors turned deaf on any request to add effort estimates to tickets. Now, they are available via the project views. This could be collateral damage of the ongoing #NoEstimates battle, best illustrated by my most beloved “enemy” Peter Kretzmann, who gives his website the title “CTO/CIO Perspectives” (I could not have invented this one), fighting bites and nails in an uphill battle against something that worked for GitHub to deliver one of the most valuable software products of the planet.

As with JIRA, the tides have turned for GitHub. The managers are taking over, especially those who think that “if you can’t measure it, you can’t improve it.” Hence, GitHub now provides supervision labeled with the euphemism “data-driven insights” as if that data really shows you the root cause of your organization’s problems.

Some Advice

If you want to be successful in Software Development (or, more generally speaking, engineering), choose your tools and their configuration so that neither the tools nor the processes designed around them stand in the way of the developers. Drop alleged objectivity through KPIs and other measurements favoring a more human-centric approach.

Yes, try it!

A Real-Life Struggle

My first contact with JIRA was while working on a project at a customer’s site. A large automotive company based in southern Germany pushed hard to get a vital project straight. To ease our collaboration, we were granted access to their JIRA instance - or at least parts thereof. Here’s what I witnessed:

• Dedicated Maintenance Team: The company needed a dedicated team solely responsible for maintaining the JIRA instance. Customizations, plugins, and integrations demanded constant attention.
• Training Hurdles: Bringing everyone on the same page required extensive training sessions. Employees had to navigate intricate workflows, custom fields, and permissions. The learning curve was steep and hindered productivity. Nothing worked out of the box. Since no one had the time to explain the company-specific rules (and no one knew them), the whole project team was lost in an overarching manifold of possibilities.

I was concerned. None of the ticket systems I had used so far had been so hard to use compared to JIRA. I had a bad feeling about it, but I could not explain why. I thought that maybe they got the setup and configuration wrong. Today, I think Atlassian’s product management is to be held accountable for this mess.

The decision for a specific tool is crucial for your company’s success. You might guess by the title of this article series and my wording so far that I consider using JIRA for tracking issues extremely harmful. Here is why:

JIRA - A Multiverse of Complexities

Let’s venture into the labyrinth of JIRA, the powerful but intricate project management tool. Brace yourself for its complexities:

Editor UI

JIRA’s editing experience leaves much to be desired. Creating and updating issues can feel cumbersome. The unintuitive behavior of its rich text editor and pseudo-markdown editor may frustrate even seasoned users.

If you have JIRA installed, then check your instance. Do people create easy-to-read descriptions? Do weblinks always work? Is code put in a code block? Can you enumerate all possibilities to configure your text editor ({code} macro, Wiki Style Renderer)? Are you sure the text editor configuration is consistent across the complete organization? How many hours did your company spend on agreeing on a text editor configuration?

Issue Types And The Layered Thinking They Yield

Issues or Tickets? Beware! JIRA doesn’t settle for a single issue type. We are pros, right? Instead, it offers a smorgasbord: Initiatives, Epics, Stories, Tasks, and Sub-tasks. Each type represents a layer of granularity, forcing users to map their complex reality into this predefined hierarchy.

There’s a saying, “To understand recursion, you must first understand recursion.” Obviously, neither Atlassian’s product managers nor 90% of the so-called Agile Coaches have the slightest clue about recursive structures.

They do not see how, from one issue or ticket, a complete tree structure of child issues could be derived and that the depth of this tree structure is arbitrary due to the nature of the problems or the tasks they describe - and due to the setup of the organization working on it. However, the designers of Atlassian deliberately decided that each problem on this planet could be mapped into a finite set of categories. It’s a severe crime, IMHO.

Check for the symptoms: If you use JIRA in your daily business, does your thought process become a game of JIRA Jenga? Do discussions devolve into fruitless debates about categorization rather than solving actual problems? Is it a value in itself to have meetings and lengthy discussions to clarify the arbitrary rules for mapping reality into five categories?

I observed another problem: A specific type of person in your organization (mainly managers, especially those who do not have a master’s in computer science or never wrote more than 100 lines of code) will love this system because it comes with a plethora of arbitrary, hard-to-remember, user-definable rules that can be written to a Confluence page where no one will read them. But anytime someone breaks the rules, these people can re-post the link to that Wiki page and feel superior for at least knowing something.

At least knowing something is very important when you have no clue about tree structures, category theory, or the software architecture and programming skills your team needs to craft the product for which the deadline is already overdue.

Consistency Nightmare via State Overload

In their viciousness, the DFH (designers from hell) at Atlassian found another dimension where they could add an even higher level of unnecessary complexity. Buckle up for the state options! A JIRA ticket can have more states than a chameleon has colors. “To Do,” “In Progress,” “Blocked,” “Review,” “Done,” “Awaiting Approval,” and the list goes on. But wait, there’s more! The maintainer of a JIRA instance can define additional states and transitions per project and per issue type.

The problematic part here is that a non-programmer can modify the state machine. Chaos ensues, and ad hoc state machines sprout like weeds. The Dunning–Kruger effect leads people to think they can easily design a state machine with more than two states and more than two state transitions.

Getting these state transitions consistent across projects and issue types becomes a Herculean task. Wait three weeks, find some deviation again, create company rules (do not forget to put them on a Confluence page!), and observe them being broken regularly.

When you try to move tickets across projects, you discover that this fails, or you lose information during the transition. In the best case, you catch the admin of your instance and whisper something nice in their ears so they fix it for you. If not, you have no option but to close the original ticket containing the beginning of the discussion and create a new one within your JIRA section. Problem solved.

Don’t worry, they say. People have absolutely no problem gathering information out of 32 different JIRA tickets, and it never happened that someone fixed an issue incorrectly due to missing an essential, well-hidden detail in one of those Initiatives, Epics, Stories, Tasks, or whatsoever. Unless they do, and the customer with the $10M budget chooses to look elsewhere for people who know their mass from a black hole.

If only those who created the mess suffered the most due to their recklessness. One might get rich by suing Atlassian for all the lifetime lost on this feature.

[TODO: Generate and add a “Lord of the Rings” meme stating, “One does not simply build a state machine.”]

Not Everything Was Bad in the 90s

I am not kidding. Some things and concepts developed in the 90s were quite good. Like e.g. “The Game” or the Matrix film.

Unfortunately, it also brought us State Machines, which were quite popular in the last millennium. This happened because they fit well with object-oriented programming thinking, which was popular, too. JIRA’s initial release was in 2002. Some people probably learned about these topics at university, became managers at Atlassian, and then thought that they knew a thing or two. And now we pay for their decisions daily.

Make a test: People who think that object-oriented programming is modern also tend to believe that state machines are excellent. Avoid these people. Get out of their way and find someone to learn from.

A Light at the End of the Tunnel

Interestingly, no one except managers was using the Atlassian toolchain at one of my customers. Do you see the pattern here? I managed to get Atlassian tools banned within a couple of weeks.

We transitioned to another, much simpler system, and within three months, all tools and development activities were documented and planned without much hassle within the new tool. We also extended the number of users to non-technical staff.

All you need are tools that do not stand in your way but rather boost your productivity. Read more about that success story in one of my following articles.

Takeaway

In the grand theater of software tools, feature bloat often masquerades as progress. But beware, every unnecessary knob, button, and dropdown exacts a toll. Your customer’s productivity wanes, buried under layers of complexity. So, dear product managers, remember that sometimes less truly is more.

Continue with part 2 of this series.

A Direct Message at Night

It’s Saturday night 3:00 am. I am awake at my desk digging through stuff from my ever growing TODO list and trying not to panic. I am good at that. I mean: not to panic. It’s the only thing you can do as CTO of a startup. The Signal Messenger notifies me about a new message received. It’s from one of my employees, let’s call him Gregor, as a cross reference to the dragons in the title.

Gregor proudly informs me about a programming task he finished and the problems he solved.

It was quite tricky. That week we had a vivid discussion about the appropriate design, data ownership, delegation and code organization criteria for reusable components, scalability and ease of use. You probably know this kind of discussions. A philosophical contest is nothing compared to that.

I immediately check the pull request and take a glance at the result of this night shift and I feel an urge to immediately give some positive feedback. The problem is not only solved, but all my hard requirements, my extra wishes (I always have those) and my criticism of the former design was taken into account. 100% solved. Extraordinary solution, elegant by design, easy to grok on the library user’s side, catching usage errors at compile time.

This guy is amazing. Outstanding code quality. A solution right on the spot. Not the overcandid and overengineered stuff that sometimes stems from long discussions.

Early in the Morning

You want to know who Gregor is? Gregor is the employee who overslept two meetings the very same week, one at 10:00 am, the other at 11:00 am. Gregor also is the one who forgot we had high visit during the week and appeared in a track suit.

Can’t be so hard, Gregor? Look, we really need some communication in this interdisciplinary team and E/E was in need of clarification. It’s not helpful you don’t care! It’s not helpful you shrug your shoulders and mumble around in rudeness and disrepect for your team mates - and your boss.

Sleeping it Over

I made a decision. I did not put my energy into changing other people. I changed myself: All meetings which Gregor had to attend, especially the recurring ones, I moved into the early afternoon¹.

If we had to schedule before noon due to lack of alternatives, I provided Gregor with a verbal warning notice the day before.

Conflict settled.

Dissecting a Message

If I understand correctly, the sentence

The early bird catches the worm.

is the postulate that if you start working early in the morning, then your productivity will rise and the quality of your work outcome will be leveraged. It is stated in such a form that it sounds like a general truth or a law of nature.

The problem with statements like these is that they get traded by managers around the world without thinking it over. Nobody takes the time to question the amount of truth in this. Nobody cares if this is backed by science². Some people even believe that Daylight Saving Time is a thing³.

In my opinion a non-violent communication is inappropriate here. Let’s talk plain: This idea is total and utter bullshit.

Neither reliability, maintainability, testability, portability, nor reusability of the code depend on the day of time it is created.

If you really want to know what contributes to code quality, probably ask Joel Spolsky⁴. If you want to make a statement about the correlation between sleeping times and quality of work outcome, probably consider Albert Einstein⁵.

Nothing Else Matters

I also would like to share my own personal view, totally not backed by science, totally anecdotal, after more than 25 years of software engineering:

The quality of work outcome depends on two things⁶:

1. education
2. the intrinsic motivation of your developers

Homework

• Is the working environment you are creating inclusive?
• Does your way to organize work reflect the fact that people are different? Does it take into account that some people would like to start very early in the morning while others start to be productive at 8:00 pm?
• Does your company provide an environment where asynchronuous communication is possible?
• Do you embrace and use KPIs? If yes:
  • How do you measure work quality?
  • How do you measure code quality?
  • And how do you measure intrinsic motivation?

Abstract: C++ lambdas are cool, but generic lambdas give you superpower.

Modern C++ has brought us lambdas and constexpr if. This is good news for compile-time evaluation nerds like me. Now it is possible to seamlessly store key-value pairs within the closures of a lambda:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#include <type_traits>
#include <iostream>

consteval auto addItem(auto origin, auto key, auto value) 
    requires (std::is_same_v<void, decltype(origin(key))>) {
    
    auto result = [=](auto arg) constexpr
    {
        if constexpr(std::is_same_v<decltype(arg), decltype(key)>) {
            return value;
        } 
        else if constexpr(!std::is_same_v<void, decltype(origin(arg))>)
        {
            return origin(arg);    
        }
    };

    return result;
}

template<int I> struct index {};

int main()
{
    constexpr auto c = [](auto) {};
    constexpr auto c_ = addItem(c, index<1>{}, "Hello");
    constexpr auto c__ = addItem(c_, index<2>{}, 42);  
    
    // Will fail to compile as expected, since requires clause above kicks in
    // constexpr auto c___ = addItem(c__, index<2>{}, "WAT");  

    std::cout << c__(index<1>{}) << " ";
    std::cout << c__(index<2>{}) << "\n";   
    
    // Will fail to compile as expected, since return type is void 
    // std::cout << c__(index<3>{}) << "\n";   
}

Abstract: Aiming at reusability and maintainability in large scale projects automatically leads to the desire to split the code base into a large number of small modules. This puts more burden on configuration management. The version control system Git allows to address this task via plugins or the built-in submodule management, but these solutions come with some drawbacks regarding performance and usability which leads to acceptance issues and might generate friction in the highly sensible field of collaboration. Fortunately, Modern CMake has some useful features that help to overcome these issues and can make configuration management seamless for both, developers and integrators.