It Is OK to Require Your Team-mates to Have Particular Domain/Technical Knowledge

Should we write stupid code that is easy to understand for newcomers? It seems as a good thing to do. But it is the wrong thing to optimise for because it is a rare case. Most of the time you will be working with people experienced in the code base. And if there is aContinue reading “It Is OK to Require Your Team-mates to Have Particular Domain/Technical Knowledge”

Don’t add unnecessary checks to your code, pretty please!

Defensive programming suggests that we should add various checks to our code to ensure the presence and proper shape and type of data. But there is one important rule – only add a check if you know that thing can really happen. Don’t add random checks just to be sure – because you are misleadingContinue reading “Don’t add unnecessary checks to your code, pretty please!”

A Costly Failure to Design for Performance and Robustness

I have learned that it is costly to not prioritise expressing one’s design concerns and ideas early. As a result, we have a shopping cart that is noticeably slow, goes down whenever the backend experiences problems, and is a potential performance bottleneck. Let’s have a look at the problem, the actual and my ideal designs,Continue reading “A Costly Failure to Design for Performance and Robustness”

Why we practice fronted-first design (instead of API-first)

Cross-posted from the TeliaSonera tech blog Alex has introduced us to the idea of front-end first design: You start by creating the front-end (browser) code. As you discover data or API calls that you need, you mock them. When the UI stabilizes, you use the mocked APIs and data to create the backend with exactlyContinue reading “Why we practice fronted-first design (instead of API-first)”

Moving Too Fast For UX? Genuine Needs, Wrong Solutions

Cross-posted from the TeliaSonera tech blog Our UX designer and interaction specialist – a wonderful guy – has shocked us today by telling us that we (the developers) are moving too fast. He needs more time to do proper user experience and interface design – talk to real users, collect feedback, design based on data,Continue reading “Moving Too Fast For UX? Genuine Needs, Wrong Solutions”

Upgrade or not to upgrade dependencies? The eternal dilemma

Cross-posted from TeliaSonera Tech blog. Handling dependencies is one of important challenges in any software project – and especially in the fast-moving JavaScript world. Our Nettbutikk team just had a heated discussion about handling upgrades of our dependencies that continuous our learning journey lined with failures (or rather “experiments that generated new knowledge” :-)). FailedContinue reading “Upgrade or not to upgrade dependencies? The eternal dilemma”

Shipping a Refactoring & Feature One Tiny Slice at a Time, to Reduce Risk

You don’t need to finish a feature and your users don’t need to see it to be able to release and start battle-testing it. Slice it as much as possible and release the chunks ASAP to shorten the feedback loop and decrease risk. My colleagues have been working on a crucial change in our webshopContinue reading “Shipping a Refactoring & Feature One Tiny Slice at a Time, to Reduce Risk”

There will be failures – On systems that live through difficulties instead of turning them into a catastrophy

Our systems always depend on other systems and services and thus may and will be subject to failures – network glitches, dropped connections, load spikes, deadlocks, slow or crashed subsystems. We will explore how to create robust systems that can sustain blows from its users, interconnecting networks, and supposedly allied systems yet carry on asContinue reading “There will be failures – On systems that live through difficulties instead of turning them into a catastrophy”

The Are No Silver Bullets: Which Error Handling Style to Pick For a Given Configuration of Constraints?

Kent Beck in his Patterns Enhance Craft Step 3: A Few Good Solutions highlights an important fact about software development: We encounter repeating configurations of forces/constraints that have only a handful of “solution families” and the optimal solution(s) depend on the relative weights of these constraints. For example when deciding what error handling style weContinue reading “The Are No Silver Bullets: Which Error Handling Style to Pick For a Given Configuration of Constraints?”

Focus & Do the Simplest Thing Possible

Are you tired of days spent in front of the screen, with no results to show? Have you once again engaged in yak shaving? Today, after having failed previously, I have finally managed to solve a problem while avoiding this trap by following rigorously two guidelines preached by grandmaster programmers. Be warned: Following this approach, you will get a working solution – but you won’t like it. It will be ugly, stained by compromises, far from the elegant solution you wish for. But if your resources are limited and you want to avoid death by too many yaks, this is your only option. But first, what are these guidelines?

One: Maintain a laser-sharp focus. A great programmer is constantly aware of what she is trying to achieve and never strays far from it. If the path leads away, she backs up. If something else pops up, she writes it down for later and gets back to the job. This is essentially about deciding what not to do. (Many thanks to Kent Beck for sharing his focus secret!)