A story about the risk of over-abstraction and false assumptions on technical debt.
I’m writing this blog post because I think that with the right argumentation people can get on-track, become more efficient for their bosses, but also in their personal lives.
The most important thing with retro’s is that you have them. But when you have them, there are a couple of things that you can do to optimize and get the most out of them.
It’s not an uncommon question. Should I outsource, should I create a distributed environment or should I keep everything (literally) in-house. There comes a time in nearly every company when these options will be (re) considered.
This blog post should shed some light at some possibilities and some of their pros and cons.
I’m starting an app. What technology to use?
It’s – as an entrepreneur – very hard to decide which technology to use. This blog post attempts to give you some insight in what options you have, and how they might affect you in the short and long run.
There is tight coupling involved between a database structure and an application. There’s no way around it. And that’s okay. But what I think is not okay, is setting rules about the relations more than once.
During development you will work with lots of individual files, comments, testers and such, to ensure that the project is structurally sound, but also understandable for humans. But as soon as we deploy for our client, there will only be machines interpreting your code, and we’d like to get rid of all that isn’t strictly necessary and really get the highest performance we can get. In this article, I give an example of a routine for doing exactly that (with TypeScript as foundation)