DEV Community: Cornelia

Why Focusing on the 'Why' Matters in Scrum

Cornelia — Fri, 29 Dec 2023 12:47:41 +0000

It's so easy to forget the why when the feature requests already tell you what you're supposed to do. But something's wrong. It feels like you're going back and forth and sideways, just like a wobbly wheel. It's hard to get a grasp on what you're actually working on and it slowly affects your work satisfaction and team morale.

As a developer and Product Owner, I've experienced what the lack of clearly communicated values can do to a Scrum team and its product. In this article, I explore the importance of transparent value in various elements of Scrum:

Product Vision,
Product Backlog Items,
Sprint Goal, and
Sprint Review

Product Vision

The Product Vision provides guidance. It describes what we want to achieve and why, and who we want to achieve it for.

I've worked on a couple of projects already where the developers didn't really know what the Product Vision was. There were two reasons for that. Either the Product Vision wasn't communicated clearly, but the Product Owner tried to keep things aligned with the vision. Developers also make decisions while they work on the product. Therefore it's crucial for them to also know what the long-term goal is.

In the other cases, there simply was no vision - or rather, the vision was like a leaf in the wind. In my experience, this has the most negative impact on team morale. A lack of vision often results in evaluating, planning, and developing features only to discover late in the process or afterwards that this feature isn't needed, or essential requirements and specifications were missing or wrong. Again, and again, and again. Besides the confusion, it also gives the feeling of investing a lot of effort to produce fancy waste. The constant change of direction can cause more impediments with external dependencies and in the stakeholder communication. All of this resulting in a team of developers that - in the best case - stop being interested in and caring for the product.

Product Backlog Items

The lack of a proper product vision often also causes the lack of communicated value on Product Backlog Items. It should always be clear which user need causes a Product Backlog Item. The solution to that need should be open for discussion and experimentation and is therefore optional! If the provided solution is already verified, the item should still state the value it's expected to achieve. This ensures that team members still think about it and challenge the suggested solution if they can think of potentially better ways to approach this need.

Providing the expected value also supports keeping the focus on what you want to achieve with this product. Items that provide value that doesn't contribute to the Product Vision can be easily identified.

Having the value on each Product Backlog Item nurtures team alignment and the team's engagement. As a consequence, the team is more likely interested and invested in the product, which has a positive impact on the team's mood.

Sprint Goal

Most Scrum teams I've worked with as a developer struggled with defining Sprint Goals. Sprint Goals state the main value the team wants to create in the Sprint. They, therefore, provide guidance, focus and a common ground to work with. In addition, without a proper Sprint Goal, it's far easier to fall into the trap of making the Daily Scrum a reporting meeting instead of a working and work coordination session.

When Product Backlog Items aren't prioritized (correctly), Sprint Planning is difficult and the team's planned work items are all over place, providing no clear value and thus no clear Sprint Goal. Usually, this is a consequence of the lack of a clear Product Vision and/or lack of value on the Backlog Items. Sometimes, there are other reasons, like availability of the Product Owner, or lack of ownership.

Sprint Review

It's important to communicate the Product Vision and the Sprint Goal in the Sprint Review. It provides context for what the team aimed to achieve and reminds the participants of what parameters to base their feedback on. I've attended reviews that lacked this clear communication and thus opened doors for feature requests that were irrelevant for the current product vision. It also opens doors for turning this working session into a reporting meeting.

Another effect this can have is that stakeholders stop attending the Sprint Reviews. Stakeholders are usually very busy, so it's crucial for them to understand why it's important that they attend and provide feedback. Providing context makes it easier for them to contribute and thus provide value for the product development.

Takeaway

Gaps in value communication cause confusion and wasted effort.
When we focus on the 'why' in what we build, we increase team and stakeholder engagement, product quality, and team satisfaction.
When you define the destination, the path becomes clear and is more enjoyable to follow.

Can you relate to any of those experiences? Where have you encountered gaps in value communication?

Thanks for reading and keep asking 'why'!

Debugging beyond console.log

Cornelia — Sun, 17 Jul 2022 23:36:30 +0000

In the past 10 years, I’ve worked with many other web developers and noticed something odd: many devs do not use the full arsenal for debugging in the browser - no matter what level they are at.

For this article I’ve set up a simple application on stackblitz you can use to follow along as we explore how to debug using breakpoints, watch, the Call Stack and various console methods for improved logging. Finally, we will also look into debugging with redirects.

Enjoy.

Demo application

The app is a modified version of W3School’s “How TO - Create a To Do List” app. It is a simple to-do app that lets you add texts via input field and button to a list of existing to-dos. You cannot add empty or duplicate values to the list. After adding an item, the input field is cleared. Clicking on a list item toggles its done-state. Each entry also has a button to delete it.

The button below the list redirects the user to another stackblitz app that redirects to google. It’s initially disabled but we will use it at the end of the tutorial to look into debugging despite page loads or redirects.

For the first sections, we only need the rendered app and the developer tools.

Open the demo app to follow along.
Can’t wait to see the code? Check out the app in edit mode.

Breakpoints

Do you ever wonder what happens to a value in a function that calls twenty other functions to modify it? Do you then find yourself logging it after each and every one of them? You can use breakpoints for these and other situations. A breakpoint will halt the execution of a script allowing you to check exactly what is going on, which value variables have and what is available in that scope. You can then follow the script step by step to the end of execution.

Standard breakpoints

To do so, open your developer tools and navigate to “Sources”. Locate the JavaScript file that includes the line of code you want to stop at. In this case, you are looking for top/js-cl89rs.stackblitz.io/~/index.js. Alternatively, you can click on index.js:69 in the console next to the “Let’s debug!” output for quicker access.

To add a breakpoint simply click on the line number. It will be highlighted in blue and the line of code will show up in the breakpoints section on the right. There you can also deactivate it. Remove breakpoints either by clicking their highlighted line number or via the context menu in the breakpoints section to the right.

Now add a breakpoint on line 53, the first check within the validateNewTodo function. If you now add a new to-do, the execution will stop when it reaches the breakpoint. You can then hover over the variable, use the console and access everything available within the scope you’re currently at. You can also see available functions and variables in the “Scope” section on the righthand side.

To simply continue execution use the button “Resume script execution” (resume) on the right or on top of the rendered app.
If you want to follow the execution step by step, use “Step over next function call” (step over). Stepping over will not follow the execution into functions but will let you check a value before and after it’s executed.
If you want to follow it into function calls, use “Step into next function call” (step into) instead. If you step into the filter function on line 56, you will see each value being checked. Now, if you don’t want to keep following the execution for each to-do, you can use “Step out of current function” (step out) to skip the rest of the execution of the filter method and continue to the next line.

Conditional breakpoints

Breakpoints are great, but what happens if we want to check only a specific type of item, one of - let’s say - one thousand? You’re probably thinking, “Well, I just add an if with a console.log”. That’s one way to do it, but you could also use Conditional Breakpoints. These breakpoints will only stop the execution of the script if a logical check resolves to true.

Right-click your breakpoint on line 53 and select “Edit breakpoint…”. If you already removed the breakpoint, right-click on the line number and select “Add conditional breakpoint…”. Fill in your condition, for example, val == 'stop'.Now the script will only halt if the value you want to add is “stop”.

Logpoints

If you only need a simple log, you can also add a logpoint instead of modifying the code of the application. Edit your breakpoint again and choose “Logpoint” from the dropdown and add what you want to log to the input.

Watch

If you want to keep track of a specific variable, especially when it is in global scope, it might be hard to keep track of it within the Scope section; maybe a property of window. In this case, you can use the “Watch” section.

The app keeps track of how many to-dos you have in your list and stores it in window.todoCount. To keep an eye on what happens to the list, hit the plus in the header of the “Watch”-section and enter “window.todoCount”. You now see the current amount of to-dos in your list.

Remove or disable all your breakpoints. Now add or remove one or more to-dos. The watched variable will not update automatically, but you can reload it with the “refresh” icon next to the plus. If you re-enable or add a breakpoint at line 60 and then step over the addTodo function call, you can see that the watch now updates automatically.

Call Stack

Many functions are called by a lot of different other functions. Sometimes it’s tricky to figure out where a specific call came from. To check that we can look at the Call Stack.

The renderTodos method is called from four different places within the app. Let’s find out which ones by using the Call Stack.

Add a breakpoint at the top of the renderTodos function in line 14 and then reload the page. On the right in the “Call Stack” section you can see that you currently are at renderTodos in index.js:14, indicated by the arrow to the left of the line. If you now click on the line below you jump to the anonymous function that called it. If you go further down the Call Stack you can look at the inner workings of stackblitz. Resume the script.

One down, only three to go. Now add a new to-do to your list. Notice, this time the Call Stack is a lot smaller. We can see that the function was called by addTodo which was called by validateNewTodo. Look at the Call Stack when deleting an entry and when toggling the done status.

Console methods

Besides log, there are many other useful methods that you can use to output information. Feel free to fork the app and add the different outputs as we work through the methods.

Fork the demo app on stackblitz. Since stackblitz doesn’t forward the output of all methods to the integrated console, open the app in a separate tab (“Open in New Window - live” button at the top right).

.info vs .log

As an alternative to log, there is the info method. Some browsers, like Chrome, treat both the exact same way. They consider them at the same level and render them in the same style. Other browsers, like Firefox, differentiate between the two. In Firefox, you can toggle their visibility separately and info output comes with a little information icon.

Why bother? Most devs will configure their linter to not accept console.log, if you want to log (relevant) information you can still use the info method. This way, you will always know log-outputs are dev only, info-output can stay.

.warn & .error

As indicated by their names, these are to output warnings and errors. They each have a separate logging level that you can show or hide in the console.

Let’s include them in our application. Let’s output a warning before a to-do is deleted by adding console.warn(‘Deleting todo’, todos[i].text); at line 32. Within the validateNewTodo function let’s output errors in both cases the validation fails.

.table

When logging arrays of objects, it can be daunting to check a specific property on multiple entries. To easily compare these, you can use the table method. Try it out for yourself by adding console.table(todos); to the addTodo function.

.assert

We’ve learned about conditional breakpoints, but how about conditional logs without an if? You can use the assert method and pass a condition as the first and the message to log as a second argument. The assert will output an error when the condition renders false.

.time & .timeEnd

Another useful thing you can do directly with console methods is checking how long the execution of functions takes. To do that, add console.time(‘new-todo’); at the beginning of the validateNewTodo function. The string we pass is the label of the timer. Now add console.timeEnd(‘new-todo’); before both returns and at the end of the function to ensure the timer is stopped even if the validation fails.

.count & .countReset

You can use the count method to track how often the script runs a certain part of the logic. In the demo application, the function renderTodos is called multiple times. Add console.count(‘render-todos’); at the top of the function. The string we pass acts as the label of the counter. If you now reload the app and add, toggle and remove to-dos, you’ll see an output with the label and the number of times the line has been run. You can reset the counter by calling console.countReset(‘render-todos’);.

.trace

You can also easily output the Call Stack to the console by calling the trace function.

.group & .groupEnd

By this point, the console gets full quickly. To keep a better overview, you can group the output. To do that, simply add console.group(‘add-todo’); at the beginning and console.groupEnd(‘add-todo’); at the end of the addTodo function. The string is the label of the group that will be shown at the top, where you can toggle it open or closed.

Add another group to the renderTodos function. Since the addTodo function calls renderTodos, the groups are nested.

You can check out even more methods in the mdn web docs.

Debugging with redirects

Debugging an application that redirects can be tricky, but there are a couple of things that can help us.

First remove the disabled attribute on the button in the index.html file. If you now click the button below the to-do list, it will redirect you to another stackblitz project that logs something and redirects to google. However, feel free to redirect to another page directly.

If you know where the redirection happens, you can add a breakpoint at the trigger. Now you can use the Call Stack to check what happens up to this point within the application. However, if you try to step into or over the replace call, you’ll notice that the script will not pause on the new page. If this page also redirects, it can be especially hard to check what exactly happens. In this case, watching the window.location can be useful, but it will also update once the script resumes.

You can preserve the console output and the network. The log will at least list all URLs you’ve been redirected to and the network tab will show you which resources have been loaded, including scripts that caused further navigation.

Conclusion

What you should take away:

Next time you need to debug something and find yourself constantly going back to log various variables, think of this article. Likely, one or more of the things you’ve learned working your way through it will speed up the process. Good luck and happy debugging!

Thanks for reading.

Cache-Control header & Cache-Busting

Cornelia — Sun, 10 Jul 2022 02:06:09 +0000

A while ago, I found a bug in one of my company’s earliest PWAs; some users’ devices did not fully receive the latest update. Investigating this issue led me down the rabbit hole of cache-busting and caching strategies.
This article focuses on the Cache-Control Header and possible cache-busting strategies. I might publish a second part, that will focus on caching with service workers.

Cache-Control Header

The Cache-Control header provides the ability to manage the cache per asset. It can have one or multiple directives.

public

This directive allows any cache to store the resource (incl. browser caches and CDNs). Resources that do not include user-specific data could be cached using this directive.
If a resource specifies other directives, but neither public nor private, public is set implicitly.

Cache-Control: public

private

This directive indicates that only a browser can cache the resource. private is useful for responses that are unique to each user.

Cache-Control: private

no-store

If this directive is set, no cache will store the resource. Use this directive for resources that include sensitive or time-critical information.

Cache-Control: no-store

no-cache

Caches will always re-validate resources that have this directive.
The cache will ask the server for a newer version. If it has one, it replies with a 200 and the new file to download and use. If the cached version is the latest one, it responds with 304. The cache then serves the asset it already has.
Since no-cache will always trigger a re-validation, it cannot be combined with the max-age directive.

Cache-Control: no-cache

max-age

This directive sets a time (in seconds) within the asset is safe to use. After that time has passed, the file will be considered stale. Stale files will be re-validated the next time the client requests the file and restarts the max-age. Note that caches might eject stale files. In that case the client will need to download the resource again.
If the user explicitly refreshes the page, the browser will re-validate the resource even though the max-age hasn’t passed yet.

Cache-Control: max-age=60

s-maxage

This directive overwrites the max-age directive for shared caches (like proxy servers or CDNs).

Cache-Control: max-age=86400, s-maxage=3600

must-revalidate

Use this directive in combination with max-age.
must-revalidate prevents caches from ejecting the resource.
Again, refreshing the page will cause re-validation even if the specified time hasn’t passed yet.

Cache-Control: must-revalidate, max-age=600

proxy-revalidate

This directive overwrites the must-revalidate directive for public caches.

stale-while-revalidate

This directive allows caches to serve the stale file while re-validating the resource for a specified amount of time (in seconds).

Cache-Control: max-age=31536000, stale-while-revalidate=86400

stale-if-error

If this directive is set, the cache will serve the stale resource for the specified amount of seconds if the server responds with a 5xx error upon re-validation.

Cache-Control: max-age=2419200, stale-if-error=86400

no-transform

This directive prevents intermediaries from modifying responses. For example, a telco provider might optimise images by default. You most likely want to prevent that because it would likely cause a loss in quality.
Since intermediaries are not allowed to modify responses on HTTPS connections, this directive will only affect HTTP connections.

Cache-Control: no-transform

immutable

This directive specifies the amount of time within the resource will not change. During that time, caches will not re-validate it, not even on manual page refreshes, nor download newer versions. So, ensure a good cache-busting (see below) strategy before using the immutable directive!

Cache-Control: max-age=31536000, immutable

Cache-busting

Cache-busting strategies define how cached resources can be updated or replaced. These are some strategies that you can use:

Fingerprinting filenames

A random hash is added to directories, per example: images-rzt87032ztr. This is usually easier to set up but could cause a lot of unnecessary traffic. Caches will need to download all resources within the folder, even though only a couple might have changed.

Query String

A specific version is requested via parameter, per example: style.css?v=1.0.0. This provides cache-busting per individual file but might still be an insufficient solution since many proxy servers and CDNs omit query strings while serving from the cache. Therefore these caches cannot be busted using this strategy.

Conclusion

What you should take away:
Work out a cache-busting strategy first, then define a caching strategy.

Thanks for reading.

Calculations with booleans

Cornelia — Wed, 18 Aug 2021 21:00:15 +0000

Sometimes I like to take a look at the quirkiness of the language I code in and compare it to other languages. This time, I thought I'd share my findings with you, in case you also find them entertaining and interesting. On this occasion I looked at a quirk featured in WTFJS, namely doing Math with booleans. Let's dive in.

true + true = ?

In Javascript, we use the + operator to concatenate strings as well as to add up numbers, but what happens when we through some booleans into the mix? Let's try!

'Hi' + true;    // output: "Hitrue"
true + 'Hi';    // output: "trueHi"

Okay, so far, so good, Javascript notices that we use a string with a + operator and treats the boolean like a String and concatenates the two. Now, let's take a look at the numbers.

5 + true;    // output: 6
true + 5;    // output: 6

Wait, what? Let's take a closer look at what's happening here.

the Number-function

The boolean value is passed to the Number-function, which converts it to a Number; true is converted to 1 and false to 0.

Note

The Javascript Number type has limits to what it can store and also limits on how high the numbers stored in can be. All Numbers are stored as floating-point values.

If it fails to convert the value into a number, it will return NaN. It can convert true, false, null, as well as a decimal and hexadecimal number (in strings).

Number(true);        // output: 1
Number(false);       // output: 0
Number(null);        // output: 0
Number(undefined);   // output: NaN
Number(0x7E5);       // output: 2021
Number('0x7E5');     // output: 2021
Number('12.5');      // output: 12.5

calculation with booleans only

When we only add boolean operands, Javascript will still try and convert them into Numbers, rather than interpreting both as being strings.

true + true;     // output: 2
true + false;    // output: 1
false + false;   // output: 0

Beyond the addition

The same effect, of course, happens with subtractions, multiplications and divisions, as well as when using unary operators (positive and negative - although NaN will not be signed).

+true       // output: 1
+false      // output: 0
+null       // output: 0
+undefined  // output: NaN
+0x75E      // output: 2021
+'0x75E'    // output: 2021
+'12.5'     // output: 12.5

Is it just JS

You might know all of this already, so let's compare it to a few other languages.

PHP and Python will also allow calculations with booleans. They both also convert true to 1 and false to 0.

Java and Rust on the other hand, will both refuse calculations with boolean values and throw an error during compilation.

error: bad operand types for binary operator '+'
Java

error [E0277]: cannot add bool to {integer}
Rust

I hope you had fun reading about calculations with booleans. Thanks for reading!