About Gert-Jan van de Streek

Owner and Engineer at Avisi, Arnhem, The Netherlands

System intolerance

In the systems integration field we often encounter systems that more or less frustrate the integration process. An example is a system that sends confusing messages or messages that clearly violate interface definitions. Requests to the owner of that system to fix those messages might result in improvements that work out better for everyone, but are often ignored and you will just have to deal with it. What are the options? Continue reading

Praise is an issue type

Issue trackers most often contain issue types, like ‘Bug’ or ‘Feature Request’. These are about stuff that is wrong, or stuff that is missing. I would like to introduce an issue type called ‘Praise’. Use it when you feel a developer has gone the extra mile to solve a problem, or to compliment on a new feature that shines!

Bugs with a soul

I love bugs with a soul. Bugs that are not straightforward. Bugs that keep you awake at night. A bug that fights back. Bugs that manifest only in very specific situations with very specific data and for very specific users. A bug that stays under the radar, that is undetectable with all the bug preventing tooling you have in place. Bugs that are uncoverable by unit tests and pass your test phase with ease.

Bug with a capital B.

All software is embedded

Embedded software is mostly referred to as software that runs on devices that don’t look like computers. The software is very tightly integrated with the device and it’s features. It runs most efficiently and interacts in the best possible way with the capabilities offered by the device.

I’m thinking all software should be embedded, including business software… Continue reading

Reward for reducing technical debt

I refuse to understand the discussion about ‘point junkies’. In short: software development teams seem to exist that are so focussed on earning story points that supplementary requirements are completely ignored. Performance, code quality, stability, etc are important factors for engineers and if you find yourself or your team in such a situation I think you have an HR problem instead.

Teams need to be rewarded for reducing technical debt, in fact, most teams reward themselves. ‘You build it, you run it’ teams know that reduced technical debt, means more BeerOps[1]. Continue reading

You build it, you run it

This is a quote on a blog from 2006 from Werner Vogels (CTO Amazon):

The best way to completely automate operations is to have to developers be responsible for running the software they develop. It is painful at times, but also means considerable creativity gets applied to a very important aspect of the software stack. It also brings developers into direct contact with customers and a very effective feedback loop starts. There is no separate operations department at Amazon: you build it; you run it. Continue reading

Requirements you don’t want

If you are building software, you need requirements. They are input for implementation and test and they can serve as means of acceptation. Requirements can be as explicit, implicit, formal or informal as long as it works in your particular situation.

That said, if you have requirements, they must make sense. I often see the ‘too many requirements syndrome’ in projects. Most often caused by someone that obviously had too much time on her hands. Continue reading