Some software development teams are so perfectly balanced that more work comes out than the sum of the work of the individual members. It’s a team of skilled experts, that get the most out of themselves and bring out the best in others. If you are invited to join such a team, expect to feel pain. The pain of trying to keep up with the pace of the team. The pain of others trying to push you to heights you did not reach before. The pain of raising the bar for yourselves.
If you manage to hang in there though, the pain becomes gain. You learn, you get better at everything and the team becomes even better, just because of you.
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 →
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.
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 →
Although we usually like to enforce strict rules on our data, sometimes we just like to loosen it up a little. Don’t get me wrong, namespaces definitely have a place and we use them to enforce contracts on our data. But sometimes, we don’t need (and thus, want) that layer of complexity.
At Avisi we maintain an application platform where the platform (VM’s, databases, LDAP, etc.) is maintained by a third party. Modernizing our deployment processes, we obtained ownership of the platform’s configuration. This brought up a practical issue: we don’t know the passwords used by the applications to connect to the services provided by the platform (database, LDAP). In fact, we aren’t allowed to know these passwords since that would break the SLA with the platform provider.