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
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!
Team member: “We cannot proceed with the project before we have a scrum master”. Other team members nod… project stalls. Actual conversation, overheard 2 times on 2 different projects in the last 2 weeks. Continue reading
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.
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
A lot of people know sh#$t about software licenses. That includes me. One option is then to fear licenses and be afraid of them. This behavior is driven mostly by persistent myths. Continue reading
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. Continue reading
Often a lot of effort is put into the possibility of rolling back changes to a production system. The amount of time and money wasted on rollback scenario’s is enormous. I realize not everybody agrees with calling this ‘waste’, but I still feel there is a better way. Continue reading
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
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