Software development is a craft and we can follow many routes to achieving a specific goal. Having this freedom allows us to create simple solutions for very complex problems. That same freedom has a flip side, where very complex solutions can be applied to very simple problems!

To be clear: I don't think anybody purposefully sets out to create complex solutions to simple problems (unless part of an artistic discovery). I think it is a sign of lack of understanding of a certain domain or technology. I also think there are several strategies you can apply to reduce complexity!

I saw this post, by Erik Flowers while scrolling the LinkedIn feed which resonated with some thoughts that have been floating in my mind without anything to latch on to. But now those thought found something to root.

I am currently working as a "software engineer" (commonly also referred to as "frontend developer") and although I like to label myself more as an "interaction developer" my main domain consists of designing software architectures and writing code. My background has always involved some level of getting involved with the user experience (UX) aspect. And while that may seem something that sticks out, I feel it is both to build good software and unfortunately also something that is not commonplace.

When you're part of a "modern" software building team, changes are, it is being referred to as "multi disciplinary" or "cross functional". This is to indicate that the team is made up of backend developers, frontend developers, some design role(s) and maybe somebody in charge of metrics and KPIs or some additional, specialised roles.

The thought process here is that if you do that, the team can be completely in control of their responsibility (maybe add some DevOps terminology in there then, as well). Which makes for agile teams.

Why do you test? Is is because you want to prevent errors on a deployment affecting the visitor? Is it because you simply want to know that the software does what it needs to do? Or maybe you want to get to know the software a bit better?

Hopefully, in this day and age, your main software tests are automated. Running before a commit, running in the deployment pipeline and running on a testing environment. Repetitive jobs need automation and testing fits that mantra very well. This article is relevant for automated testing, although for certain topics you could use a manual testing perspective as well. If you like.

So. You’re a small, medium sized or even large scale company. IT is an integral part of your business, whether it is a small scale application or an enterprise grade platform. Let me repeat that for you: IT is an integral part of business. You know this, because you’ve been doing IT for a long time, right? But. Are you doing it right?

Yes, you tick the SEO boxes and yes, off course you’re in the cloud (whatever the heck that is). You have backups 🤞. Nice! You even have a couple of scrum teams working together on your product. Extra nice!

I am working for Jumbo Supermarkten, which is a large grocery chain in the Netherlands. This family owned business started to venture into e-commerce at about 10 years ago with a very small team of developers. Currently, we've grown into an IT department that consists of over 450 developers working on all digital solutions. We've made some changes over time on how we manage our software. I gave a talk together with my colleague on this topic, so let's share the write up here.

So, if we rewind the clock the the founding of the Jumbo Tech Campus (JTC), where in the beginning the main purpose was to get started with e-commerce. What happened was that the team at the time did the thing that is most obvious with limited resources and a generic goal: they grabbed an off the shelf solution and started to implement it. This meant connecting to the existing brick and mortar stores, the delivery and storage APIs and whatnot.

In software engineering, we can apply a lot of the psychology findings to their digital counter part. If we consider the broken window theory, it doesn't apply to the operating system, but to the state of code.

Let's go back to the source. From an article originating from 1982 ("Broken Windows") in The Atlantic by James Wilson and George Kelling.