Sunday, September 20, 2015

How architecture and the constraints that apply to it cannot be seen as separate things

In a previous project, I observed a typical communication mismatch. One team was demonstrating the technical details of architecture that, on first glance, was supposed to be a replacement for an existing architecture. The team demonstrated all kinds of technical solutions and showed us how much better they were than the solutions in the prior architecture. At some point the team compared a very nice and elegant implementation detail with the worst the existing architecture had to offer. On itself, the new architecture contained some brilliant ideas that the old team wished they had thought of themselves. The point however, is that the team forgot to mention how different the constraints were under which both architectures evolved. By doing so, a lot of people in the room interpreted this as bashing the old stuff. And that's a shame, because the old team could learn a lot from the fresh ideas the new team showed them.
The original architecture started almost five years prior to this meeting with best intentions. However, over those years the architecture accumulated technical debt, even though the old team keep tight control on it. Commercial pressure is a reality and forces you to take shortcuts and usually doesn't give you enough room to pay pack on that technical debt. As I've said it before; working on a system with 4-5 great developers is a completely different game then when you have 40 developers working on the same monolithic code base. And when that project started, they didn't have great technologies and tools like Git, Github, MyGet and OWIN, offering the old team less options for pro-actively breaking down complex systems in small maintainable chucks. Sustaining architecture over a long period is just a very very difficult thing to.
Anyway, I'm not trying to defend the old team in this discussion. I'm pretty sure that they've made some bad decisions over those years. But something that I'm guilty of myself is to criticize a team's accomplishments purely by comparing the status quo with your own ideas and opinions and neglecting their history. Most bad design decisions are not made intentionally, but result from political, organizational and functional constraints that may not be even be relevant anymore today. Without those constraints you'll probably come up with a completely different (and probably better) architecture. But please don't ignore that history and judge them from the looks of it. And beware of focusing too much on the technology rather than on the problems your are solving and the constraints that apply. The architecture of your solution is there to support the requirements of the problem domain and is never a goal on itself.
So what do you think? Do you agree that architecture cannot be discussed without discussing the constraints that apply to it? Let me know by participating in the Disqussions below. Oh and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.

Saturday, September 12, 2015

What it takes to turn a group of people into great colleagues

At Aviva Solutions, we have a unique tradition to celebrate our annual anniversary in some foreign city or at a warm beach in the south of Europe. During such a weekend, you're free to enjoy the local culture, go shopping in the local area or just relax at a terrace or the beach. Next to being a great company to work for, that on itself is a privilege that I'm looking forward to every year. Some people may think that we're being spoiled or that we're a bunch of expensive overpaid consultants for which our clients pay the price. But when they say or think something like that, I'm pretty sure they miss the point.


Sure, it is a privilege working for this company and everybody loves those annual trips. However, the most important reason why my employer is doing this is because it helps building a company were people really learn to know each other. We're with 50 people from all over the country (we have offices in Eindhoven and near Leiden) and about half works in the office or from home, whereas the other half is usually working full-time at a client's office. So, other than a couple of knowledge sharing evening and our bi-yearly formal meet-ups, they don't see each other that often. Being able to enjoy a long informal weekend to learn each other's skills, interests and personality is a very efficient way of building bridges within your company. That's why such weekends have a couple of mandatory parts such as dinner or an occasional organized activity or boat trip. In my opinion, such a weekend binds the people together. It makes them want to work together.

As an example how well this worked before, I can remember how we went through the first two years with 10-15 senior developers. Within the same building, there was another small company with young, relatively inexperienced .NET developers. At some point, Aviva Solutions decided to take over that company and merge those developers into our group. Since I did a couple of tech sessions for that group before, I knew most of the boys and girls. But since Aviva Solutions started off with the idea of only hiring very experienced people, you could see how these groups were miles apart on all levels…until we travelled to Mallorca… People discovered that they had common interests and hobbies, lived in the same area, or had the same acquaintances. I don’t have to explain that after that weekend we were one big group of happy developers.


I also remember working for a prior employer in the Eindhoven region who equally valued their people. Since that company helped me boost my career as a software developer I have a lot to be grateful for. And I sure have some precious memories from that time. I still keep in touch with a quite a few of those colleagues. However, during most of the four years, I was subcontracted at Philips Medical Systems in a department with about 150 .NET and C++ developers. Even though that employer was very dear to me, when I left to move to The Hague area, my departure party at Philips involved 100+ people, a speech by the department manager, and many gifts from my Philips colleagues. After saying goodbye with a tear, I dropped my laptop, phone and entry card at my own employer, shook some hands, and left without a blink…

My point? Well, I don't have to repeat how great of a company Aviva Solutions is (and that we're still looking for passionate young people). But I hope you see the power of such a weekend away and how it can turn a group of employees into a band of brothers (and sisters)…

So what do you think? Do you agree that such an initiative is a good idea for a company to do? Do you know of any other or better ideas? Do you want to share what your company is doing to make it unique? Let me know by commenting below. Oh and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.