Jimmy Nilsson's blog

Totally unexpected and extremely nice

2026-04-09T00:00:00Z

The other day I was watching this very good video where The Pragmatic Engineer interviews Martin Fowler here.

Approximately one hour and 31 minutes in, Martin says that he enjoys discussing with people who are expressing different perspectives and uncertainty rather than telling just ‘how it is’ with full confidence. Then he takes me as the positive example.

This was extremely nice to hear since Martin has been my leading source of inspiration since around 2000. For example he made me decide to write a second book when he referred to my first in his seminal book Patterns of Enterprise Applications Architecture (PoEAA) 2003.

A fun anecdote related to what Martin said about me was that I spoke at a conference in USA a few years earlier. The organiser provided me clear feedback that I had to stop saying “maybe” on stage and provide different suggestions as solutions to the same problem. “Just tell them how it is!” they told me.

They did invite me back several times so I guess it wasn’t too bad, but still fun how different people think about the same thing. Your weaknesses are your strengths and vice versa, it just depends on the context?

Dear Martin, thank you!

This text has also been published on LinkedIn. Join the discussion here.

What is flow for you?

2026-03-25T00:00:00Z

Earlier in my career, I’d automatically have said something like: being in a weightless state, without time and space, completely zoned in on what I’m doing. Someone even compared flow to the state of deep meditation or when a religious person prays.

And this is for sure a lovely state to be in. But it’s pretty much a local optimum.

As I gathered more experience, I found myself more drawn to flow at the organisational level: value that is created and moves from start to finish. Starting from the customer’s perspective, having no or few hand overs, doing the work to the very end so that it creates impact.

To me, that’s a far more interesting form of flow. Even lovelier and more important since it’s done though collaboration. Much more of a global optimum.

Tell me, what’s your version of flow?

This article has also been published on LinkedIn. Join the discussion here.

Decision speed 2

2026-03-04T00:00:00Z

As I mentioned in the previous post about “decision speed”, I’m a bit obsessed with bottlenecks. Sometimes the bottleneck is learning enough to make a good decision. Here are a few more links on that subject which I find very inspiring. Two new and one old.

Learning from users faster

Jan Bosch says that a common bottleneck in software delivery is that gathering user feedback is very slow. That feedback loop needs to be closed: User feedback as code: virtual users in AI-driven value loops

Programming to understand

To faster understand something in depth, Kristen Nygaard said: “To program is to understand”. Here’s some information about Kristen: Kristen Nygaard It’s hard to grasp that a couple of decades ago, involving users in software development initiatives was very political!

Programming to understand faster

In the same spirit, Simon Wardley explains how to learn something in depth more quickly by programming it: Post on LinkedIn

Any tips to share on how to speed up decisions that are otherwise killing your flow?

This article has also been published on LinkedIn. Join the discussion here.

“Is our organisation ready for AI?”

2026-02-27T00:00:00Z

There are quite a lot of comments flowing around right now that GenAI is an accelerator. Good news if you are in a good situation, since the good will be increased. Bad news if your situation is the opposite. Here are two interesting indications:

1.

In his recent white paper “AI-Ready Code: How Code Health Determines AI Performance”, Adam Tornhill comes to the conclusion that GenAI is even more inclined to create errors due to bad code than human developers.

You can read the full paper here.

2.

In her article “Building Foundations for Continuous (AI-accelerated) Change”, Susanne Kaiser points out that team topology and architecture are crucial if you want to benefit from the faster pace of AI-generated code.

You can read the full article here.

I find this is especially interesting in the light of this quote from the book “Accelerate”, by Kim, Humble and Forsgren, about what kind of architecture you need to enable high software delivery performance:

“We set out to discover the impact of architectural decisions and constraints on delivery performance, and what makes an effective architecture. We found that high performance is possible with all kinds of systems, provided that systems – and the teams that build and maintain them – are loosely coupled.”

I would like to add 'high cohesion' (from a business perspective) to 'loosely coupled' as another important pairing principle. :)

This text has also been published on LinkedIn. Join the discussion here.

What will tomorrow look like?

2026-02-20T00:00:00Z

How do you organise for tomorrow when nobody knows what tomorrow looks like?

A friend mentioned yesterday that many software organisations are stuck in a vacuum right now. GenAI is clearly affecting them, but they don’t know how, and even less what to do about it.

At first, this surprised me. I definitely see how GenAI is affecting things daily, but mostly it’s accelerating trends that were already in motion. Sure, it’s a jump, a big one. But the direction isn’t entirely new.

That said, I understand that it’s complex to decide what to do. The information overload isn’t helping, is it? And it also doesn’t help to acknowledge that nobody actually knows what’s coming (even though plenty of people sound like they do). In some places there's a pre-hysteria vibe...

But here’s what scares me more than the uncertainty: doing nothing. That’s probably the worst decision right now. In my opinion the best approach is the same as always: make the best decision you can with what you know today, execute and adapt!

To help you do that, here are three things that are still important and true:

1

Context is king. What you should do depends entirely on your situation, not what worked for someone else or what the hype cycle says.

2

Aim for global optima. Maybe coding speed was your bottleneck before (though I suspect not for most). Where will the bottleneck appear now? What unlocks the most value across your entire business?

3

Software architecture still matters, a lot. If your architecture tricks people into creating errors, it will trick GenAI. If it drains your teams’ energy with unnecessary complexity, same goes for GenAI. If it blocks people, it will block AI agents too.

By the way, nobody ever knows what tomorrow looks like. Therefore, embracing change is always a good strategy.

This article has also been published on LinkedIn. Join the discussion here.

Decision speed

2026-02-19T00:00:00Z

I confess, I’m a bit obsessed with bottlenecks. Lately, I’ve been thinking a lot about the kind that slow down your flow of change. I’ve gathered a few links below to solutions for common ones. The theme today is decisions. Maybe one of them will help with whatever bottleneck you’re facing right now?

Decision speed

Suzi Edwards-Alexander pointed me to this interesting article by Dave Girouard: “Speed as a Habit”. It focuses on speed for decisions, which is often what slows everything down. He also addresses the common belief that speed is the enemy of quality. I know you can have both. In fact, high quality can help speed, a lot!

Decentralising decisions

Andrew Harmel Law provides an appealing solution for speeding up architecture decisions whilst keeping them sound: decentralise them “correctly”. (Read it here.) We’ve used architecture decision records for a long time, but this approach makes them even more powerful.

Answering certain hard questions quickly and well

Simon Wardley and Tudor Girba are working on a book called Moldable Development. I’ve only read the first four chapters, but they’re very inspiring. A theme is that by creating tiny, context-aware tools for answering questions about a system, speed and quality of decisions might increase dramatically. Again, they can go hand in hand...

From decision to action

An old favourite book of mine, “The Art of Action” by Stephen Bungay, always feels important here. Maybe the overall decision about direction was taken quickly, but how and when is it translated into action? And what action? Taking the decision is often the easy part. “Yes, there’s a strategy, but I just don’t know what I’m supposed to do” might sound awkwardly familiar. It’s about how to correctly decentralise decisions – and action – to where the information is.

Which are your best suggestions?

This article has also been published on LinkedIn. Join the discussion here.

Feeling trapped in a US cloud? — How to stay flexible?

2026-02-12T00:00:00Z

This text continues my attempt to speak directly to system owners, rather than to my usual community of software developers. Earlier texts in this series (“Feeling trapped in a US cloud?”) can be found here:

Today I will try to answer a question from a friend. They said:

“I get that it’s good to stay flexible and not lock yourself in for life with a certain provider. But how do you actually do that?”

In this text, I’ll focus on how to handle dependencies, especially external dependencies – meaning something you’re dependent on that another team or organisation is responsible for. Typical examples include databases, frameworks, code libraries, APIs, applications, and runtime environments.

Below are three practical tips you can bring into discussions with your developers on how to avoid ending up in a blind alley when it comes to dependencies. Make sure they don’t dismiss questions as “stupid” or “impossible”, but help you evaluate both past and future decisions more consciously.

Tip 1 – Avoid obvious lock-ins

Even though tips 2 and 3 are about handling tricky dependencies, the first tip of them all is to avoid obviously tricky dependencies altogether.

The obvious candidates are things that are unique to a specific product or vendor, for example:

A stored-procedure language tied to a single database vendor.
An uber-quick way of doing something thanks to a cloud tool unique to a single vendor.

At first, these choices might look like a good trade-off between a certain quick result now vs a possible cost later. After all, certain is better than possible, and now is more important than later, right? And sometimes that trade-off makes sense. But sometimes it’s just wrong.

When is it wrong, then? Business priorities and ethics will help judge that. From a development perspective, I also look out for two technical warning signs:

Will this choice affect testability negatively?
Will this choice prevent local development without a network connection?

If the answer is yes, you should reconsider.

Here’s a common objection: “Swapping database products, that never happens!” Well, I disagree. I’ve experienced it several times in recent years. In one case, for a very small solution, cost was the driver. Interestingly, the discussion about whether to swap took longer than the actual work, because the system had implicitly been prepared for it by following tips 2 and 3.

Another common situation worth considering is when there is only one vendor to choose from and you’re not allowed to read the code. In those cases, if not before, looking for an open-source alternative to evaluate is typically a good idea.

That said, open source is not automatically safe forever. Projects can change direction, open source can become closed source, or licenses can become problematic in later versions. So, even with non-lock-in open-source dependencies, follow tips 2 and 3.

Tip 2 – Keep your dependencies under control

Even if you avoid the worst lock-ins, you can’t avoid dependencies altogether – and you shouldn’t. Dependencies often create value. The key is to deal with them wisely and responsibly.

If a dependency is used in many places, aim to centralise its use by calling a single place rather than spreading it out in the code. That way, if you need to swap it, there’s at least only one place you need to change. (Some dependencies – such as to your cloud provider – might be harder to centralise. We’ll get back to that.)

Test automation is definitely your best friend when it comes to keeping your dependencies in control and staying flexible. You need automated tests that are testing real dependencies to check their behaviour, not just mocks. This allows you to try an alternative implementation and validate it using the same test suite. If the tests are green, you’re ready for more full-scale testing.

Your build pipeline should help you stay in control. Beyond running tests, it should also analyse your external dependencies to reduce the risk of security issues. Common practices include:

Generating an SBOM
Scanning for vulnerabilities
Verifying package integrity
Enforcing strict dependency-management policies, such as blocking deployments with critical security issues or license violations.

Your external dependencies are a key attack vector – treat them accordingly.

A short reflection: I was once asked to help a customer choose a product of a certain type. I told them they could pick whichever option they preferred from a short list. They found that unhelpful, they wanted me to tell them which one. When I said it didn’t matter, they thought I was being sloppy.

In hindsight, I should have explained myself better. What I meant was that the choice could easily be swapped later if needed. And the only way to learn whether the first choice was wrong was to live with it for a while.

Keeping dependencies under control doesn’t stop at development, it’s even more crucial during production. For that, observability is your best friend. Is the dependency (and the whole application) actually behaving the way we expect? At the end of the day, what happens with the dependencies in production is the truth.

Note: Not all dependencies are alike. A dependency on something another team in your organisation owns and controls typically carries less risk than one that’s fully external.

Another way to keep your dependencies in control is to describe infrastructure dependencies in code, using Infrastructure as Code (IaC). That doesn’t mean the code can handle any infrastructure, but it ensures the documentation used for inspection reflects reality: what’s actually running, not something outdated or guessed. To change the infrastructure, you change the code.

Once we’ve come this far, a dependency swap is starting to feel less like the end of the world and more like “just work”. But tips 1 and 2 aren’t enough on their own, we also need tip 3.

Tip 3 – Don’t let your dependencies infect you

When you depend on another model, for example an API, you can choose how to treat it.

If you conform to the model and use it everywhere in your own code, the dependency “infects" you. That makes the coupling much tighter than it has to be, and swapping the dependency later becomes much harder.

The alternative is to map at the edge and keep your inner code independent. In Domain-Driven Design (DDD) terms, this is expressed as preferring the Anti-Corruption Layer pattern over the Conformist pattern.

Somewhat related to this is preferring “necessary-evil”-use over “every-little-obscure-feature”-use of, for example, a framework The latter is a trap which is easy to fall into (been there, done that). It often starts off as wanting to learn all the ins and outs of something, but ends with burned wings. So, even if a new tool looks impressive, keep it simple!

One effective way to reduce this risk is to focus on a rich domain model for your core business logic, rather than letting a tool handle some of it. That means describing your business logic in a layer which is only about this and nothing else – definitely not mixed and affected with infrastructure dependencies. Done well, it can become so clean and clear that non-programming domain experts will be able to follow the most interesting code in discussions with developers.

Another way of reducing the risk is to favour tools with single purposes over “swiss army knife” tools. This idea of a component to do one thing and do it well is called the Unix philosophy. Multi-purpose tools are tempting – once you depend on it for one thing, it’s easy to just keep adding use cases. After a while, replacing it becomes very hard.

Any good shortcuts?

At this point, you might wonder if there are any good shortcuts for deciding which external dependencies to take on. Let’s explore a few.

A common shortcut is to choose a vendor and follow their path. I strongly dislike that and consider it a reliable way to end up trapped. I recommend evaluating each dependency individually each time. I touched on this subject in this text about preferring a tech-agnostic approach.

What about always writing your own code instead of adding external dependencies? Well, both have their advantages. Your own code:

Easier to fix immediately
Does exactly what you need – nothing more
You need to be in control, so you might as well own it

External dependency:

Proven and widely used
Faster time to value
Not primarily your responsibility to maintain
Often stronger from a security-review perspective

Unfortunately, this isn’t a good shortcut either. There’s no universal rule. You need to decide what is right in each specific case.

Final comment

To summarise, make your decisions regarding dependencies with wide-open eyes.

Dear @Community, do you have any additional tips for system owners (non-developers)?

Special thanks to Daniel Melin, Katharina Damschen and Daniel Raniz Raneland for their help with this text. Any remaining mistakes are mine.

This article has also been published on LinkedIn. Join the discussion here.

Expert generalists

2026-02-11T00:00:00Z

When I started my first large project as an independent consultant 33 years ago, I remember how I was welcomed by one of the most senior developers in the team I was hired to work with. He asked me if I knew “a-certain-development-tool-you-hopefully-haven’t-even-heard-of”. I said no and he asked me why I was there then.

I was super young and hadn’t expected that kind of questioning, but I replied something along the lines of: I thought I could learn it fairly quickly, since I’d worked a lot with “another-development-tool-family-that-was-quite-similar”. It turned out fine.

It only just occurred to me that this may have been a formative moment for me, and perhaps one of the reasons why a tech-agnostic approach has made so much sense to me...?

Fast forward 33 years. If I were asked a similar question now, I think my answer would be that I try my best to be what’s described in the text Expert Generalists by Martin Fowler, Unmesh Joshi and Gitanjali V. Thanks guys, I really like that text! It makes so much sense. It’s also a very good description of the kind of people we would like to hire at factor10. I only wish I’d had that text a long time ago, but better late than never.

When I read an early draft this autumn, I was genuinely moved, to the point of getting wet eyes. That’s not my usual reaction to a tech text. :) I’m not sure why, but perhaps it felt like being understood and not being alone in an ambition I’ve had for a long time. An ambition that’s often been seen as a bit weird, or at least not mainstream.

I do have one issue with the text though, and that’s the word “expert”. Maybe it’s a Swedish thing, but the word has been so overused and abused that I almost automatically distrust it. I find it’s more often than not used for people who aren’t very skilled and experienced at all. There are exceptions, of course, but it’s still a troublesome word for me. But that’s just a minor detail in an otherwise excellent piece.

This article has also been published on LinkedIn. Join the discussion here.

An example of architecture modernisation, 15 years later

2026-02-10T00:00:00Z

The other day I found myself thinking about an architecture modernisation project that I was fortunate to be involved in 15 years ago, together with Equinor (then Statoil) in Trondheim.

That team was without a doubt one of the best I’ve ever worked with, and I have very fond memories of the project. So, I decided to reach out to one of the people who was involved back then, Atle Haugan. To my great joy, he told me that the system was still alive and kicking, even blossoming!

They’ve continued evolving the system ever since the renovation project, and that’s the main reason it’s in such good shape today and can support new opportunities. To me, the fact that they’re still investing in its evolution is a strong signal that it’s still a genuinely valuable system. Also that continuous adaptation is smooth for them.

Another team member from that time, Ellen Lippe, and I gave a presentation about the project at Øredev 2011. Back then, most conference talks were about what could and should be done. Therefore it was especially fun to talk about what had actually been done – and what the outcome was. Unfortunately there were issues with the sound recording, so the video was never published.

I gave the same presentation again at NDC Oslo 2012, this time by myself since Ellen couldn’t make it. The version we did together was definitely better, but this one is still reasonably informative, I think.

Oh, and during this project was the first time I met Gøran Hansen and that was a blast. He joined the team after a while and I definitely learned a lot from him too!

Three years after the renovation project, I got the following comment from another team member, Kjell Einar Mikkelsen (translated to English by me): “I look back on the time of that project as the most important in my career. An amazing learning experience.”

It was definitely an amazing learning experience for me too! A big thanks for that, and for all the fond memories, to the great Sing team at Equinor!

Initiatives for architecture modernisations / renovations / remakes / transformations / adaptations can be incredibly valuable, that’s what they all have in common. That said, every situation is different and context is king.

This text has also been published on LinkedIn. Join the discussion here.

Dual-use

2026-02-04T00:00:00Z

The defence sector in the free world is currently talking a lot about dual-use technology. In this context, dual-use refers to civil products that can also be put to effective use in military settings. Especially when cost, ease of use, time to availability and volumes are considered. A typical example is the use of consumer drones.

Reading about Ukraine’s successful use of its system “DOT-Chain Defence”, a digital platform that allows military units to order defence products directly from manufacturers, made me realise that dual-use also works on a conceptual level, and not just for hardware.

You can read more about it in the article "How DOT-Chain Defence is changing rules of game for Ukraine’s drone industry".

The article covers many things, but my main takeaway from it is four concepts that I think about, and work with, all the time in the civilian world:

1.

Moving from “economies of cost” to “economies of speed”. Just-in-time deliveries (pull rather than push) increase adaptability. (Ironically it also reduces the risk of large stocks becoming worthless.)

2.

Using “platform as a business strategy”. It creates “network effects”, but also help distil quality and surface the most effective solutions for different situations.

3.

Balancing centralisation and decentralisation, to reach effect.

4.

The system’s success is achieved even before adding self-service for custom configuration. I assume that addition will unlock a greater level of effect.

Maybe it’s a stretch to call it “dual-use” when applied to concepts. Concepts are generic by their very nature. That said, I found it interesting to see how well those concepts work in a defence context. In the civilian world, we’re usually applying them “only” to create value for businesses. According to the article, the same concepts can also be helpful when lives, freedom and democracy are at stake.

At the same time, I know that I’ve learned a great deal about architecture and organisation by reading about military philosophy. It goes both ways. (More about that in another post.)

Where else do you see concepts moving between civilian and defence contexts, in either direction?

This text has also been published on LinkedIn. Join the discussion here.

My first Solution Designer initiative

2025-12-10T00:00:00Z

The first time I was involved in an initiative of this kind was 30 years ago, with Dynapac – a company known for its compaction and paving equipment. As I remember it, they had been building the best machines on the market for a long time, but were beginning to feel increasing competition. The trend was clear, and it was worrying.

Luckily, an entrepreneurial person at Dynapac got an idea. He and his team realised they were sitting on years of research about how to compact different soil and asphalt materials in the most effective way. Since compaction is a critical part of, in particular, road building, they decided that this knowledge shouldn’t just stay inside the company – it should be placed directly in the hands of their sales engineers and customers in a helpful way. I was brought in to help out with the development.

The application we created became very popular, globally. Suddenly, customers cared a lot less about the purchase price. Dynapac’s tool helped them select the correct equipment for their – often huge – projects in an optimised way: which machines to combine, how to operate them, number of passes, ideal amplitude and speed, and so on and so forth. This helped them save a lot of time and money while ensuring the right quality. And it also deepened long-term customer loyalty.

At the time, I was surprised by the scale of the impact. Now, after having been involved in several similar initiatives, I know that this is what happens when you focus on helping your customers reach their global optimum instead of just selling them a product.

For Dynapac, it wasn't only about providing the best machines, it was about truly helping their customers achieve the best outcomes.

This old story is very much in line with the concept of a Self-service Solution Designer, that we at factor10 have tried to describe here.

This text has also been published on LinkedIn. Join the discussion here

Is DDD becoming even more crucial?

2025-12-09T00:00:00Z

I keep hearing Domain-Driven Design (DDD) mentioned as a helpful foundation for agentic coding. Agents seem to benefit from a DDD approach in much the same way living developers do. And the same goes for integrating LLMs into your overall architecture: they perform better when surrounded by a DDD-inspired strategic design and when they can use a rich domain model.

DDD feels more crucial than ever (if that’s even possible). Perhaps this means even more people will discover one of my all-time favourite concepts/tools?

That said, somebody asked me the other day when DDD is of most value, and my spontaneous answer was during architecture renovation/modernisation. You know those situations where every small change in the software is painful and the business is hurting because of it. (It feels kind of silly to pick just one situation, but this one really stands out for me.)

We’ve tried to capture that, and a few other situations as well, in this DDD overview.

This text has also been published on LinkedIn. Join the discussion here.

Surprise-Driven Sharing, hardware and software development are similar?

2025-09-19T00:00:00Z

A couple of weeks ago, I left my comfort zone (software development) and went to a conference for another “world”. The conference was hardware development-centric and for a specific business domain. I was very curious to find out what was going on in that context and wanted to learn. Quite unexpectedly, all they talked about was the need to increase the speed of going from idea to delivered product, and how that could be achieved.

An old friend who was also at the conference has spent his entire career in that business domain. He said there was an urgent need to think disruptively: “What if we did everything differently? Maybe be five in the design team rather than 200, maybe let all the designers collaborate every day. What else?”

Ah, another total surprise for me!

I instantly recognised his wild and crazy ideas regarding hardware development, as some of my favourite modus operandi for increasing the likelihood of achieving effective software development. This was yet another big surprise and good reason for re-learning. And for sharing some thoughts in my SDS-series. Therefore, here is my take on five superpowers from software development, which actually might be helpful to hardware development too, at least if speed is crucial.

Let’s start with the first suggestion, which is very much in line with my friend’s first idea…

1. Extremely few

Always start a team with as few members as you could possibly get away with for the tasks at hand. In fact, better too few than too many! Later on, when there is a real, urgent need to grow the team, do so. But delay it for as long as possible.

There are many reasons for this approach, but the first that springs to mind is that this way the team will have to focus on the absolutely most important things and nothing else. There is always a possibility of adding more things later on. With too many people, they will all start adding things. With some luck, some of those things will be useful and good. Most probably, it’s all guesswork and most guesses will prove to be wrong. But even before that, they’ll be in the way and cause friction. Which is actually much worse than being worthless. “Worseless”? :)

I do understand that people need to build things in the hardware world. However, in the software world, building things is an automated task performed by the build server, not the developers. (The build server takes instructions written by developers in source code as input and produces a program executable by a computer in machine code.)

If you build repetitive hardware things, you should go for automation in the hardware world too. That makes it possible to keep the number of people down to a bare minimum. A focus on automation leads to the possibility of focusing on quality over quantity, which is the subject of the next section.

It is, of course, important with redundancy so that everything doesn’t grind to a halt if a team member wins the lottery and quits. That could be a reason for growing more, but we have another, better way of dealing with that concern…

2. Only the right people

If possible, focus on finding expert generalists for your team (especially early on). Expert generalists have shallow knowledge about many things (and a few special areas with deeper knowledge). However, they are curious and quick to learn new things. They are also very collaboration-oriented and customer-focused making them effective bridges between different teams and functions.

If you manage to get people like that on board, you need fewer team members to cover everything since each person can take on several roles. That way, you’ll get redundancy built in without the normal overhead cost.

The right people are passionate about the result. It’s not just a job – accomplishing the outcome, is a mission for them. In the TV show “Australian Master Chef” a couple of years ago, a guest chef describe the importance of passion something like this:

If you work with your hands, you're a worker.

If you work with your hands and head, you're a craftsman.

If you work with your hands, head and heart, you're an artist.

It’s not only about finding people who will do stuff. Neither is it only about finding people who will do the right stuff. It’s about finding people to who will passionately do the right stuff.

Finally, you should take explicit care to mix people of diverse backgrounds, experiences, and characteristics in your team. Again they will cover a much larger spectrum together and think differently about challenges and solutions. Very powerful, as long as they work as a real team…

3. Great collaboration

With a tremendous amount of luck, you might be able to create a great product by having each person in the team work in total isolation. But we are not in the business of optimizing for luck, so we don’t even try. We aim to work closely together.

I’ve been fortunate to get many chances to help companies analyse and suggest ways to improve their software delivery performance. Overall, I think the most common problem has been challenges regarding collaboration. It’s not a margin problem, it seems to be ubiquitous.

As I understand it, in the hardware world, there is another possibility of friction to which I’m less accustomed nowadays: a big gap between development and production people. I would definitely try to bridge that gap or delete it completely. Not only to minimise friction but also to maximise opportunities for learning and improving!

This leads to a need to balance what I just said about tight collaboration and being extremely few. Sooner or later, a single team just won’t be enough (and a team should be tiny). One way to succeed with the collaboration outside your team is to keep your outside dependencies in control.

Domain-Driven Design (DDD) is a powerful philosophy, concept and toolbox often used in software development. It’s a big topic, but at its core is the idea that we succeed in developing software in complex situations by using effective collaboration between developers and domain experts, by speaking a shared language within a specific context, and by focusing on the most important subdomain.

One area of DDD, called Strategic Design, is about the big picture, for example, how different teams relate to each other. To take a simple example, which team should define something to be collaborated on? Both? No matter what you choose, there are pros and cons. However, if you don’t make explicit decisions, you risk mostly ending up with cons. Strategic Design is an excellent source of inspiration for designing your dependencies to keep them in control.

Talking about DDD…

4. Everything should start from the business needs

To some, it’s evident that everything should start with the business’s needs. Others consider this approach wrong. I’m definitely in the first camp.

So, how do you learn to start from the business’s needs if that’s not your usual approach? The above-mentioned DDD is an important source of inspiration in the software world, and I suspect it could work in the hardware world too. I haven’t tried, but the dynamics should be similar.

“Domain-Driven” means starting from the business perspective rather than the technical details. Ironically, the opposite is more common. But as software developers, we really shouldn’t worry too much about the development itself, we can typically manage that. The hard part is understanding the business and how to solve the business problems! DDD could probably be a source of inspiration in the hardware world too.

That said, even if you start from the right place with the right stakeholders, every single step you take risks leading you astray. It’s not just about the start, it’s about the entire journey. That needs to be dealt with…

5. Extreme feedback

We need early and frequent feedback. Not only so that we can learn when we are wrong but also so that others can come up with ideas and better solutions. Actually, it even helps us identify better needs. This is how breakthroughs happen!

For real feedback to flow effectively, we need continuous deliveries. Delivering early and often is the way to go. This happens to be a mantra of Extreme Programming, a way of thinking regarding software development. Essentially, it’s about using what is known to work and be effective, and then turning the knob up to ten on those things. For example, if it’s helpful to have automatic tests to check that you haven’t broken any assumptions after making a change, why not write those tests before you write the code? Or if it’s effective to integrate different people’s work often, why not do it after each change by every person? And so on.

Again, automation will be key to make sure the team doesn’t drown in overhead. This is also tightly connected to the focus on increasing the speed of going from idea to delivered product, which I started the text talking about.

I realise that “deliver early and often” is generally more challenging in the hardware world than in the software world. However, I see it as something to strive for rather than a requirement to deliver a fully functional product every working hour. It’s a direction, not an absolute. And many other things are easier to do, such as mockups, prototypes and simplified A/B Testing. The same goes for batch sizes of 1 and just-in-time (at least early on).

Another kind of feedback is regulation. It’s often said that certain businesses are so regulated that they require manual work. I believe the opposite is true. If it’s regulated, we must use automation.

Oh, finally something that is easy to overlook if you are used to it and take it for granted, but is super crucial and will stop everything if you don’t have it. Some fundamental things…

0. Fundamental things

Fundamental, as in “must be in place,” or there is no need to even try suggestion 1-5 above.

The fundamental things I’m thinking about are just that, the fundamentals:

Trust and psychological safety Alignment on values (here are factor10’s values as an example) Common purpose and goal (here is a short text about this as well, although in Swedish)

On the other hand, suggestions 0-5 are reinforcing each other. For example, being extremely few makes all the fundamental things much easier and more likely to succeed!

Thoughts?

Nine years ago, I wrote that hardware souls can’t become software souls, and that’s not what I’m suggesting we try now either. But I do think that we can learn from each other.

I imagine some of you who consider yourselves hardware souls think this now:

“Jimmy, you don’t understand. This is hardware! We are different and unique!”

And that may very well be true. But what if some of the ideas I presented above could provide some inspiration? It can’t hurt to try, can it?

Ironically, quite a few code bases aren’t soft at all. Some of them are so rigid that they are harder to change than hardware. Perhaps the two fields have more similarities than we think?

So, where did I go wrong? What should be number 6? Thoughts?

This article has also been published on LinkedIn. Join the discussion here.

About the Series

Surprise-Driven Sharing (SDS) explores moments when established viewpoints are challenged, sparking reflection and learning. Read other parts of the series:

Part 1: Surprise-Driven Sharing (SDS)
Part 2: Surprise-Driven Sharing, again
Part 3: Surprise-Driven Sharing, yet again
Part 4: Surprise-Driven Sharing, hardware and software development are similar?

AI thoughts, June 2025

2025-06-10T00:00:00Z

It’s been over 1.5 years since I last posted anything about “AI” so I felt it was time to share a few more thoughts. That last post explored how LLMs can be used in customer solutions. Today, I’ll focus on how LLMs will impact software development. The number of writings on this subject increase by the day, so one more text may not be that wished for. But who knows, perhaps someone will find something here worth reflecting on. And considering the speed of everything right now in this space, it’ll be fun for me to reread this in six months’ time. Never pass up on a chance to laugh at yourself! :)

So, should we care about using coding agents?

Of course we should care about what’s going on. As always, it’s important to stay curious and try new things. Relearning is what we live for, isn’t it?

When it comes to using AI in software development, there seems to be just as many positive as negative voices in the community right now, and some of the debates are getting quite polarised. So, who’s right? In my opinion, it doesn’t really matter. We should do as we’ve always done: giving it a real try, again and again, in a responsible way. Worst case scenario, we learn something – and that’s actually a pretty good outcome. Most likely, there will be more impact than that.

I was pretty active early on, but ended up disappointed over and over. Then came a period of not experimenting that much, but now I’m eager to dive back in. Kent Beck said it the other day that it feels like having an exoskeleton. I could definitely use one of those! :)

Another iteration on an old problem

Twenty years ago, a common solution to finding enough development speed and power was to outsource the work to people far away. I remember Charles Simonyi saying it would be a thousand times quicker (and cheaper), if a machine could do the job instead.

Manually writing 3GL code is sometimes simply too much effort for the value it delivers. Inspired by Charles, I thought meta-programming might solve the problem. Like most solutions, it had its place, but it didn’t revolutionise the industry at its core.

Over the years, I’ve had this nagging feeling that we as a community are not actually making that much progress. At times, it’s felt like we’ve not done that much progress ever since the Visual Basic-days. :) I started wishing for a new and good “VB” fifteen years ago. Coding agents might actually be the answer, though definitely not what I had in mind back then.

Not all developers would like to

Not everyone will want to use coding agents, even if they prove to be genuinely useful. And that’s totally fine, of course. Some people will prefer to write all code manually forever, even if there are faster options.

If you’ve come across the metaphor of forest and desert by Beth Andres-Beck and Kent Beck, I think that applies well to this subject too. Speed and improvements simply aren’t priorities for companies living in the desert. One indication of this is that, even after all these years, practises like TDD, DDD and continuous delivery are still only used by a small minority.

So why aren’t improvements important in the desert? One reason is that any gains would just be drowned out by all the other pressing problems. What does matter to those companies, though, is reducing cost, so change will still happen in one way or another.

Cost

One common assumption is that AI-accelerated coding could allow companies to cut down on the number of developers while achieving similar results. That will probably happen in some places. In others, the goal won’t be to maintain the status quo, they’ll be aiming for more, and better, results.

This shift also puts a new cost on the table in the form of tokens and GPU-time. Developers have always benefited from fast hardware for development and pipelines‚ but this operates at another level entirely. It might become quite visible in the bigger picture.

Another major cost to consider is energy use and CO2e emissions. At least some of the increased gains made possible by coding agents will have to be redirected towards lessening the problem, for example by drastically reducing the burning of fossil fuels.

Inexperienced or experienced developers?

There have been some comments suggesting that inexperienced developers will outperform experienced ones when it comes to learning and using these new possibilities.

Thinking about this reminded me of the concept of leaky abstractions, which Joel Spolsky coined 20+ years ago. To be effective as a developer working at any given level of abstraction, you need to understand the level beneath it. It also reminded me about the value of knowing who to ask and when...

I assume it will as most often be good with a mix of different backgrounds and experience levels.

Another dimension regarding experience level

Amount of experience as a developer is only one dimension, of course. Persona is another one. Already today, entrepreneurs who don’t see themselves as developers are beginning to create executable prototypes on their own, without involving developers at all. Something that simply wasn't possible earlier.

It reminds me of something from 30 years ago, when I was a subcontractor at an IT-department. People there were very concerned that business people had started building application-like things in Excel. "This must be forbidden", they said, probably for good reasons. They knew who would ultimately have to take responsibility when the apps were put into production. But still, it was definitely very helpful input for developing something production-worthy.

At the other end of the spectrum, we have senior, super-skilled, passionate developers working in an extremely slim codebase, carefully crafted and maintained for a decade or two. At the moment, many of them are struggling with coding agents that go rogue, or at least don’t do exactly what they want.

I expect the entrepreneurs are just the beginning of a bigger movement. The brilliant developers will continue evaluating AI to discover where and when the gain is bigger than the pain.

Guessed effects after a while

In my opinion, the speed of writing code hasn’t been the real bottleneck that often, not even in the forest. It was rather architecture, teamwork, domain understanding, organisational culture, UX, … But if we do increase the speed of writing code, it will free up some time for more value-adding work in the other areas I mentioned. It will also make it possible to try out many more ideas and experiments, increasing the chance for even earlier feedback than before.

I think all this could lead to more people embracing a long-held message of mine, but now sharpened. Development teams don’t need to be big. In fact, quite the opposite. Two-three developers might be all you need, but now they could achieve even faster time to market and better long-term outcomes.

Or, worst case, we learned something.

Again, these are for sure exciting times to live in! Stay curious and keep re-learning!

This article has also been published on LinkedIn. Join the discussion here.

Some thoughts about trust

2025-03-26T00:00:00Z

Recent happenings in the world

It’s been interesting (depressing) to see how a superpower nation we used to trust now makes it impossible to trust them. Lying, betraying and exploiting have that effect. Maybe trust is also out of fashion?

A few reflections

Many years ago I started hanging out with a person from a country and culture far away. After he had done some work in Sweden he said that we had a very high level of trust and how wonderful that is. I totally didn’t understand what he meant. After all, I had lived and worked in the same rural part of Sweden my whole life. I didn’t realise how lucky I was and how good that situation was for the outcome and impact of collaborations, short and long term.

Now many years later I have operated in environments of low trust and now I better understand what my friend meant. In an environment of low trust everything is slow, frictional and hard. Lots of suspicion, low psychological safety and derogatory thoughts crop up. It’s the opposite of a collaboration-friendly situation, and a setup for conflict.

“Who needs trust? Just set up a very detailed contract.” I couldn’t disagree more, trust is sooo much more valuable for collaboration than contracts. In situations of high trust, a contract is not really needed. In low trust, a contract won’t help. I know that contracts are for later on if something goes wrong, and not for early on when everybody is hopeful. But going back to where I started, with the superpower nation going rogue. For contracts to possibly help at all, there must be the rule of law and that too seems to be in limbo for the superpower nation…

In situations of high trust, a contract is not really needed. In low trust, a contract won’t help.

To put that in a professional perspective, let me take one more reflection. A CIO at a large company was repeatedly disappointed with the vendors of their strategic initiatives. He asked me how to pick a vendor to avoid that. I was caught off guard and said “pick the one you trust the most”. He replied that this was the opposite of what they were doing. Their contracts were getting thicker and thicker and they talked to their vendors with louder and louder voices. It didn’t seem to help, it just got worse.

Explanation models

My initial thoughts about why I was so familiar with high trust environments was about small-scale communities where “everybody knew everybody”. But a problem with that explanation is that trust was in place from the start no matter if you knew the other person or not. Kind of like the opposite of the old saying that trust must be earned. Trust was rather the default. How come?

Fortunately, I’m lucky to hang out with people who challenge me all the time and a colleague suggested Hofstede's cultural dimensions theory as a possible explanation model. One of the six key dimensions for comparing national cultures is called the Power Distance Index (PDI). It describes the degree to which authority is accepted and followed. As I understand it, my habitat has a very low PDI which seems to lead to “early high trust” in many situations. I realise how internalised a low PDI is for me, I cringe when I read about the opposite. :) I will learn more about this. It’s super interesting! Also, as you know, there is a risk of oversimplification with such models. All models are wrong, but some are useful.

Another explanation is alignment on values. If you don’t align on values, you can still hang out and learn new perspectives from each other, but collaboration can probably be expected to suffer. That makes sense, but the problem is how to know that you align on values. Even though you can exchange information about values, that’s at best an indication. To know, you probably need to work together, to see the values in action. It might not be clear by just talking, that one person doesn’t see lying as a problem if it helps, while another person would rather fail than lie.

Oh, and aligning on values doesn’t mean that you only hang out with yes-sayers. At least our values (at factor10) means the opposite, for example that everybody has a responsibility to care for their colleagues and therefore challenge them when they see a better way.

If the trust is gone?

You can’t force anybody to be worthy of your trust or to trust you. It might be sad, but you don’t have to continue working tightly together forever when the trust decreases, for example because of a misalignment in values. If that happens, you use the protection needed while you fulfil your commitments. This might be a very stable setup, a setup which is worthwhile for all involved and thereby also long term.

If the trust is gone at some point, you might end the relationship. You just change and collaborate with someone else, with whom your values align. That’s in the best interest of all parties. It’s as easy as that.

Finally

The more I think about trust, the more dimensions and aspects crop to mind. I will dive into that in another text. I hope you have time to share some thoughts also!

I started with a question whether trust is out of fashion. For me it’s a no.

This article has also been published on LinkedIn. Join the discussion here.

Why tech agnostic?

2025-03-21T00:00:00Z

When working with Suzi Edwards-Alexander and trying to find out what is good (and bad) about factor10, I've realised there are a few unconventional things about us that I'm proud of, but I don't think of much since I'm home blind. They’re things we’ve had since we started 18 years ago, such as flexible work time, transparent and equal pay, work time for personal exposure, …

Another of these unconventional things occurred to me last Friday when I wrote to a maybe-future-customer that we are technology agnostic for our customer's sake and ethical reasons. :)

How could that be the case? I think it becomes clear when describing the opposite. Let’s assume you only work with one vendor and the client is currently using tools from another vendor. You would then have to talk your client into changing, even though it might be for no valuable reason. Related, and perhaps even worse, is to have the agenda of a vendor involved in discussions that should be about what’s best for the client.

This decision to aim to be tech agnostic wasn’t something we ever fought about, if even discussed. It was just natural. We pick tools that we think are the best for the job, without holding on to a decision forever. When there is something better, we pick that instead. Assuming that the best tool would always come from one single vendor… Well, that just doesn’t make sense. It’s also riskful from a lock-in perspective, having all your vendor dependencies with a single vendor.

Somewhat related is to standardise on protocols rather than on tools/products/vendors. Those of us that were around when REST became popular might have forgotten the competition. Several large application server vendors told the world that as long as you built all your software for that vendor’s application server, you would be fine. The REST people rather said to look at the web. It’s chaos, everything is built with different products. But it works. The single application server world didn’t.

Even if we find this mindset to be natural, there are drawbacks of course. Those that specialise on a single vendor will typically get some benefits from the vendor, for example discounts and leads. It’s not a big drawback, though, to not get that.

Since we don’t limit ourselves to a single vendor, we might not be as good with all the intricacies of a certain tool as some that are specialising and we can never simply claim to be ‘experts’. (That’s not a word that I like anyway, but let’s not go there now.) On the other hand, even if we learn “all” there is to learn about a tool, we are always careful not to overuse it. It’s better to keep a healthy distance for dependency reasons. And as always, there is a diminishing return. As long as you know enough, other things make the difference. You will typically also evolve your skill in programming language A, by working with language B. It’s not a zero-sum game, it’s rather 1+1=3.

Talking about other things that make the difference, Test-Driven Development (TDD), Domain-Driven Design (DDD) and Theory of Constraints (ToC) spring to mind as extremely important for creating the most value for clients. Coincidentally, they are also tech agnostic. (By the way, I wrote about TDD (or rather XP), DDD and ToC as related in something like a stack form a few years ago. But to benefit from those, you need to have “enough” skills in the programming language you are using.)

Also, as a consultant in software development it’s important to learn fast. That might be the single most important trait to have. Aiming to be tech agnostic is a wonderful way of getting to learn a lot!

Finally, it occurred to me that it’s quite easy to explain why we aim to be tech agnostic since it connects directly to our values which are to excel, challenge, care and lead. A tight partnership with a single vendor and only working with their products puts an unnatural constraint on aiming to challenge or just doesn’t fit with caring for the customer for example.

As usual, there are pros and cons, but I will continue to aim for tech agnostic. What’s your opinion and what are my blind spots?

This article has also been published on LinkedIn. Join the discussion here.

Feeling trapped in a US cloud? — Common modernisation pitfalls

2025-03-18T00:00:00Z

Two weeks ago, I wrote an article to you (a non-developer) who is responsible for a core system running in a US cloud. It provided some guidance on how to proceed. Today, I will continue my attempt to share helpful tips for the same audience. This time I will focus on common pitfalls to avoid when you investigate how to execute the transfer to a new runtime environment.

The tips are generic for different types of architecture modernisations, not just for moving between different runtime environments, but they should be useful in that specific situation. Of course, context is king as always, so keep that in mind as you read on.

@Community, please help out with solid advice on how to move from US clouds to a new runtime environment. The target audience is non-developers.

Pitfall 1: Blame

It’s common to become surprised when reviewing decisions that were made, perhaps ten years ago. When stress levels are high, it’s easy for blame to arise. However, if blame starts being thrown around, the environment can turn toxic very quickly. Trust goes out the window and psychological safety is low. This is for sure a significant pitfall and a common one.

It’s unproductive to dwell on why what now seems as strange decisions were made and whose “fault” it was. A more constructive approach is to recognise that these decisions were made with different information than we have today, and very likely deemed sensible at the time. And even if they weren’t effective in hindsight, it ultimately doesn’t matter (except for possible learning of course). You can’t change history. You need to look forward and solve your current challenges.

Pitfall 2: Analysis paralysis

Another common pitfall during the analysis phase is the endless amount of information and things to check out, you just never run out of it. Many people also feel uncomfortable moving forward without perfect understanding and a flawless plan. There are many problems with this. One is that time is running and running without any real progress being made. We need to get into action. Another is that the value of each additional day spent analysing is quickly decreasing (diminishing return). It can also result in uncertainty spreading in the organisation as people wait for the analysis to be presented and decisions taken.

A simple and powerful solution to this problem is to dedicate a certain amount of time to the analysis, like a timebox. And favor keeping it too short, rather than too long. That way it’s super clear when the analysis is “done” and ready to share. In the worst-case scenario that there is no valuable information to share, that’s actually an important insight on its own. But more often than not the timebox will result in a lot of insights so that a decision can be made whether further analysis is needed or if it’s time to take action. (Or quite often both, but for different areas.) After all, it’s super important to start doing things. Executing the first steps of what might be a very rudimentary plan will typically provide extremely valuable new information.

Pitfall 3: ONLY tech reasons

Finally, the most critical—and the most common—pitfall when it comes to architecture modernisations, is to allow the initiative to be driven only by technical motivations. While getting rid of technical debt for example might make a lot of sense, if the business value isn’t clear and substantial, there’s a significant risk that the modernisation project will end long before it’s “done”. This can lead to an increase in the technical debt because of a new “generation” in the codebase, while the old is still there. (If the modernisation for getting rid of technical debt is successfully done in baby steps that continuously are deployed to production, this is not a pitfall.)

Driving the modernisation from a business perspective such as increasing revenue or decreasing business risk—increases the chances of successfully finishing the initiative. Running it like that is actually much easier for the techies too, since a clear understanding of the ”why” helps guide a thousand micro-decisions that arise every day. This is also a reason why the concept of Domain-Driven Design (DDD) is so important and popular.

@Community, any more common pitfalls and solutions to share?

Hope is getting stronger, right?

As you might have noticed, none of these pitfalls are really centered around tech, but more around human mindsets and behaviours. That’s no coincidence. As strange as it might sound, tech is rarely the problem. Compared to human dynamics, tech is actually quite easy and manageable.

I hope that knowing that will bring hope to people outside of software development! And don’t forget, taking action is also a real hope creator!

This article has also been published on LinkedIn. Join the discussion here.

An old story I want to share

2025-03-07T00:00:00Z

This is me repeating a story from memory I read 30 years ago in a magazine. I’m afraid I have no references, but I like the story a lot so I’d like it to live on.

What characteristics do your most productive people have? AT&T (I think) asked themselves that question and did a study on all their developers. They thought it was strange that some seemed to be magnitudes more productive than others, and it was consistently the same people. Before the study they expected the result to be a difference in education and/or experience. What they found wasn’t that.

The investigation showed that the most productive people were those who knew when to ask for help and knew who to ask. That was their superpower. That made those people not get stuck, but talk to the right person very early and find a good solution together.

I remember people getting annoyed by the story. “Shouldn’t education and experience matter? That would be to ridicule years of hard work, wouldn’t it?” I’m totally sure that those things matter a lot of course, but maybe if everybody has enough of it, it’s something else that matters more.

If asking a similar question today, I guess my spontaneous guess would be that it’s a matter of psychological safety. Maybe the AT&T-study actually is in line with that. If you don’t have psychological safety, there’s no chance you would ask a question that might be stupid. And you might be stuck for a long time for no good reason. Also, knowing when and who to ask could be seen as a step in the right direction toward better collaboration.

Finally, I’m aware of the trouble of defining “productivity”. But I think this fuzzy story is quite interesting even so. :)

This article has also been published on LinkedIn. Join the discussion here.

Feeling trapped in a US cloud? - It’s time to take action

2025-03-04T00:00:00Z

Dear person who is not in the community of software developers but is, in one way or another, responsible for your organisation’s most important system running in a US cloud. This text aims to bring hope.

A few days ago, I wrote “Don’t panic, but it’s time to take action.” As I said there, I hear lots of people suddenly being worried about their core systems running in US clouds. They see a new situation, and they feel trapped. I said that there is hope, and I will try to share some orientation and tips for you on how to tackle this together with your best friends, your tech team.

I also expect colleagues in the community to chime in with more helpful information.

Note

Since I think time is very important today, I chose to publish this in a sketched format.

Target audience

Please note that this text is not for the community of software developers. It’s rather for you who is somehow responsible for the most important systems of your organisation. The systems that are custom developed to provide differentiation and competitive advantage. The systems that determine whether your organisation fails or succeeds. The same systems now happen to run in US clouds which for many is an unwanted situation considering the evolution of global politics.

Eight months ago I wrote something related (in Swedish) regarding the EU regulation “Digital Operation Resilience Act” (DORA). The companies being affected by that should have this under control since January 1, as I understand the regulation regarding the requirement of an exit strategy. This text is rather meant for all the other companies, not “only” those that are important for the financial stability of EU countries.

The text also assumes that you work in a European company and that your system has European users and/or manages information about Europeans. That said, quite a lot in the text is generic to any move of a custom-developed system though.

More people who are not the target audience

Of course, running standardised systems in US clouds might also be risky, but that’s a different story altogether. It also requires work to solve, but in that case, you are among a big group of other companies sharing the same challenges. I will not talk more about that in this text. I’m sure others who are much more knowledgeable about that than me will share advice.

@Community, please help out with solid advice on how to move from standard package X to Y.

Why now?

I think a lot of people have been considering for a long time to use European cloud providers rather than the US ones, to avoid transferring data about Europeans to US companies. The current agreement for allowing that is called EU-US Data Privacy Framework and has been at play for almost two years now. (That is after the two prior agreements had been considered invalid by the European Court of Justice). The current one seemed like a weak construction from the start, I think it’s just waiting to be invalidated. That said, I think the convenience of staying in US clouds has been considered by many to be stronger than the risks. After all, even if the paper construct was weak, there used to be quite good trust between the EU and the US.

In the last few days, the trust situation has changed (understatement of the day?) and the risk has skyrocketed. It will require work and therefore cost money to move, but the valuation of cost vs risk has changed. The legal situation is probably troublesome very shortly, and the moral situation since a long time ago. Add to that the risk of threats to close down access to the US clouds, unthinkable just days ago.

I think it’s reasonable to follow the law, to not expose information about users, to avoid vulnerabilities and keep dependencies under control. I’m sure you do too. If that means that you should do the move or not for your system, that’s for you to judge.

Common misunderstandings

Before we continue with the subject of this text, how to move from US clouds to EU ones, I just want to briefly clarify a common misunderstanding. It does not help that the US cloud you are using stores the data on European soil. What matters is the country of legal residence of the mother company. The reason: they could be required by US law to provide data to US authorities.

Another common misunderstanding is whether you are handling sensitive information or not. From a European law perspective, what is considered personal data is very broad. Take an IP address for a user of your system, for example.

With that out of the way, let’s dive in.

Cost

It’s of course hard to say much about the cost before doing the analysis which we will talk about shortly.

I was just thinking about a situation quite many years ago as a reflection to this discussion. We were doing technical due diligence for a prospective buyer of a big software company. We were very concerned because we came to the conclusion that it would cost a couple of millions of euros to fix the architecture and to get them in a reasonable shape for future development. We reported that in one of the daily meetings with all the different due diligence teams. The prospective buyer thanked us and said that we were done then because that was peanut money compared to the other real problems. :)

My point is that cost is always relative and a matter of context. To a techie, it might seem extremely expensive to do the move. To the business owner the cost might be almost negligible compared to the risk of staying.

Time for action, where to start?

Again, we are talking about your custom-developed system, unique for you to differentiate your business. Therefore, the situation is unique and context is king. That said, there are also similarities between the situations, and common approaches could be applied. I’m not talking about “best practices” here, those are scary to use in unique situations. I’m rather talking about some common and proven ideas‚ rules-of thumb if you will, that you can see how they fit your situation. When they are applicable, use them. When not, do something else.

To start from the beginning makes a lot of sense as usual. A generic approach would be to first do an analysis to understand the current situation then to come up with a vision, and then to understand the gap between now and the vision.

The generic approach fits well here. The second and third steps will be easier than in many other situations though, and that’s good.

1. Current situation

Regarding the current situation, first focus on finding out where you have tight dependencies to the specific cloud you're currently using. When those decisions were taken, that was probably for good reason (even though I suggest the default would be to aim for being cloud agnostic). Now those decisions have become problems that you will have to deal with. Common problems will be infrastructure dependencies such as:

message queue
database
logging

Most systems use all of those. What we are looking for is dependencies to cloud-specific solutions that you won’t find in your target cloud. Please note that it’s much worse if such dependencies are spread out in many different places in the codebase. The difference can be enormous. From having the possibility of changing and testing the change in one place to having coupling to the database for example “everywhere”!

If you don’t find any dependencies to the specific cloud, part of the analysis should be to make a test move and thereby get a list of less obvious challenges.

2. Vision

Most often, architecture modernisations are driven by the possibility of a new or bigger revenue stream. In the case we are talking about today, it’s rather driven by the will to reduce risk. Maybe not as inspiring, but just as important. And actually quite a bit easier. The “vision” in this case is probably something very straightforward, like “host our system in a European cloud”.

A decision that is probably less straightforward is of course the choice of a new runtime environment. I will not delve into that here, but only say that even if it might be a hard decision, I don’t think of this as a dramatic one. You should of course choose as wisely as possible, but you should also use this transformation to create flexibility for moving again if the need arises. After this first move, you will actually be in a much better position in many ways!

@Community, can you please help out with advice on how to choose a new runtime environment?

3. Gap

Again, this step is quite easy compared to a modernisation journey, where you’re aiming for something that hasn’t been done or even thought of before. In the case of moving to another cloud, we can actually know what we need to fix so the system can be moved to the new runtime environment.

A checklist to evaluate for possible initial actions

I don’t suggest that you create the perfect plan with steps for all the actions in your gap analysis. Rather that you decide on the most important first and minimal action and execute it. Then you re-evaluate and decide on the next minimal action. Getting as quick feedback as possible and keeping manoeuverability is key.

Even though I’ve said that the vision and the gap might not be as hard to come up with, you are still operating in a dynamic environment in many ways. Just to give a simple example, when executing the first action, it might affect the overall situation so that what you thought would be the second action isn’t needed at all or is way less important now.

Another reason is that the business will not shut down during your actions. Since your system is crucial for your company’s competitive advantage, it’s more than likely that changes will be needed occasionally. Those changes will also affect the landscape.

It’s also the case that you can’t avoid learning a lot as you’re progressing through your actions. That learning is super important for making the best progress possible. You will never again know as little as you did before you started.

Therefore, take advantage of the fact that the situation and understanding evolve and re-evaluate what should be done next when an action is taken.

What will be your first actions will be totally dependent on your situation, but I suggest a few areas that I find to be crucial for any modernisation. If you already have them under control, that’s great news and a promising prediction for a smooth process! If you don’t have them under control, the work ahead is probably much harder. But you will also have a very good effect in these areas for the rest of the life of the system. The work will also mature your teams and that investment typically has an even longer lifespan. Doing the work is not throwing money into the sea, it’s rather an investment in your future.

The following are crucial and generic areas you need to have in place. It’s good to have them in place before you make changes. This will make all other changes easier and more risk-free. Without them… Well, then there is quite a lot of work to be done, but just get started!

Full test automation. With this in place, you will run automatic tests to be confident that the system is not broken. This greatly decreases the risk of changes and totally affects how you can work with your software.
Full observability. Even if you have very good test automation in place, there is still the possibility for problems to make their way through the safety net. Therefore you need to have great visibility into what is going on in the software when it runs in production. That’s extremely important so that when there is a problem, it’s quickly sorted out and solved.
Fully automatic deploy. You will probably make quite a lot of changes to your software during the transformation initiative. You want those changes to be deployed as quickly after they were made as possible, and you want each deployment to be done in the same way. For reasons of frequency and repetitiveness, automation is crucial. This deploy pipeline you’ve had or will add probably has a somewhat tight coupling to your environment. That’s also something that has to change, but having that automation is still very positive. It just has to be changed for the new target environment at a certain point.

Action plan

Now it’s time for action! At the time of writing, the risk has skyrocketed, but we are not in panic. We can and should take action in a way that is the best for us. Thereby slowly but surely take steps towards the vision. I suggest that you take the necessary steps in your current development environment and push the changes to your current runtime environment. By doing that, you will be able to continue business as usual with as little friction as possible. You will also start benefiting from the work immediately since you will run the changed and improved code now rather than at some point in the future when you do the move.

This is very much in line with the ideas of “deliver early and often” and “taking baby steps”. The opposite is the “big bang”, and we are not after creating a new universe, only moving our system in a responsible and reliable way. If you decide to do the changes in the new environment, you might find yourself doing a lot of work before the system runs again. It’s like working in the dark, with less-than-wanted feedback.

Another advantage of making the changes in your current environment rather than in the target environment is that you buy yourself time to get used to the target environment, by trying it out. And that is without the pressure of making sure the system runs well in that new and “unknown” environment. You will get to that pressure point, but it’s better to grow into it rather than making a single jump there.

Note

Super weird things are happening every day right now so I might be wrong about the possibility of moving slowly. I actually lean toward panic mode rather, but it’s for you to decide. If so, change the steps accordingly

Still the same feeling of being trapped?

Hopefully you are starting to get a feeling of how you could get out of the trap. That said, a friend said that law wins (I couldn’t make myself write “trumps”) over tech and politics wins over law… That might be the case, but with good tech, you will be flexible and can manoeuver. That’s of course a good thing even if you later decide that you don’t need to move your system.

Trust me, there is hope! After all, the system is just software. “Soft” means that it’s changeable. I think it was Grady Booch who said, 1s and 0s is the best building material in the world.

@Community, please chime in and help out! What did you think about as helpful to tell non-developers at all organisations that would like to move their crucial core systems?

This article has also been published on LinkedIn. Join the discussion here.

The second part in this mini series is found here: https://www.linkedin.com/pulse/feeling-trapped-us-cloud-common-modernisation-pitfalls-jimmy-nilsson-9w4vf/

Surprise-Driven Sharing, yet again

2024-09-02T00:00:00Z

In the second part of “Surprise-Driven Sharing (SDS)” I wrote about how surprising I find it when people say things like “Once we finish this final feature, we are done!” when talking about custom-developed software. However, sometimes they add something like: “Well, apart from some minor maintenance.” This too surprises me.

I think their perception of maintenance is upgrading some dependency once a year because of a security issue, and it is, of course, a good thing that they protect themselves in that regard. But what I find problematic – and surprising – is that they differentiate between initial development and maintenance. Especially if they have one team taking care of the initial development and another doing the maintenance.

Dog food and handovers

The first problem with this setup is that the first team will not “eat its own dog food”. That is, it will never know what was good in the long-term and what was problematic. Therefore, they will continue to make the same mistakes in the next project and the next and the next...

Another problem is the fact that handovers always bring overhead costs, knowledge loss, and time consumption. Typically this mindset is combined with batching up good ideas for a second version and getting another team on board to do most of the new development work. Again this brings overhead costs, knowledge loss, and time consumption. The reason is probably a haunt for efficiency but it comes at the loss of effectiveness (and efficiency).

I suggest a totally different viewpoint. Almost twenty years ago an old friend of mine suggested that it might be helpful to clarify how software development should be thought about. Rather than the common viewpoint of a project for version 1 and then getting rid of the team, he suggested talking about all development as maintenance. “Maintenance starts after the first commit”, he said.

Gardening model

At the first meeting with a prospective client 13 years ago, I suggested a model of “a gardener team” for developing an important piece of software. The gardeners (developers) have a certain amount of time set aside, like a constant minimum pace, which they always use to take care of the garden (software). Sometimes something new needs to be planted (a new feature) without any delay, sometimes there’s old compost to deal with. More or less every day weed is taken away. With the pace and quality given, all the discussions every day are about how value creation can be optimized for. The client told me that this model resonated with him; he was the son of a gardener. :)

As you noticed, I wrote “constant minimum pace”. Of course, the gardener team can grow temporarily at times of need, but the core team is always there and the ramping up and down is done stepwise and without big, abrupt changes. It’s also important to stress “minimum” here. Too much time will create challenges of its own.

Another thing I like about the model of a gardener team is that the best design ideas rarely come about on day one. Not even on day ten. But given time there might be a breakthrough thought, like an epiphany moment. An idea so obvious that you can’t understand how someone didn’t think of it until now. One that is helpful in many respects when put to use. The reason for this delay is that you needed to live in the real situation for a while to see and feel how it really was. Even if this idea somehow had come to you on that first day, you wouldn’t have been able to recognize it for what it was. It would simply have drowned in all the hundreds of ideas which, at that moment, seemed equally good.

In Kent Beck’s latest book Tidy First?, he explains that he learned early in his career that clients valued his work the most when he opened and upheld opportunities in the codebase. It wasn’t about implementing new functionality by speculation, it was about keeping things in good shape for being prepared to take care of the next unknown opportunity or need. Keeping a good balance between new features and new options is key.

Investments vs running costs

I once discussed the problem of viewing development and maintenance as two separate phases with the CIO of a traditional company. He neither agreed nor disagreed with me. Instead, he surprised me by saying they’d always done things that way and it would be impossible to change.

Maybe one reason for this separation is that companies differentiate between investments (initial development project, capex) and running costs (maintenance, opex). And running costs are considered bad by investors and shareholders. I would like to turn this around: Why on earth take the risk of a big investment when you have the option of transforming it into running costs which can be stopped or pivoted at short notice and have a brutal focus on delivering value early and often?

A helpful model?

I know that using metaphors to describe aspects of software development can be problematic. Metaphors are models and all models are wrong. But some are also helpful. I do think the metaphor of a gardening team can help describe how to deal with your most important software development – the one that gives you a competitive edge.

This article has also been published on LinkedIn. Join the discussion here.

About the Series

Surprise-Driven Sharing (SDS) explores moments when established viewpoints are challenged, sparking reflection and learning. Read other parts of the series:

Part 1: Surprise-Driven Sharing (SDS)
Part 2: Surprise-Driven Sharing, again
Part 3: Surprise-Driven Sharing, yet again
Part 4: Surprise-Driven Sharing, hardware and software development are similar?

Surprise-Driven Sharing, again

2024-08-20T00:00:00Z

The other day, I started a small series of texts about having a strong and internalized viewpoint about something you’ve spent your whole work life on, and suddenly noticing that some people you meet hold different, sometimes even opposite, viewpoints. The idea is to share viewpoints I think might be helpful to others, as well as to check my own biases and hopefully get new thoughts from you to look into. I called the series “Surprise-Driven Sharing” and you can read the first part here.

My second text is not about a recent surprise, this is something that originally shocked me a few years ago. However, I do notice it coming back in milder versions over and over again.

The first and strongest surprise occurred when a C-level person I met at a conference years ago asked what our (factor10’s) unique selling point was. With pride, I told him that we are good at developing software with long-term smooth changeability. To my great surprise, he looked at me with disdain and said something like: “What, so you never get it finished?” My jaw dropped, why on earth would he not like something I was so proud of?

Now, I can think of a few situations when business-centric, value-creating software won’t need to be changed:

The software is offboarded and won’t be used any longer.
The company using the software doesn’t exist anymore.
Nothing related to the business that the software is supporting ever changes.
The requirements are extremely well-known and the context is completely closed and static.

But if any of those situations are to be expected, should software be custom-developed in the first place? I don’t think so.

A milder surprise than the one I mentioned above, is when I, quite often, hear people saying something along the lines of “Once we finish this final feature we are done”. And everytime I find myself fighting the urge to say that that can’t possibly be true…?

Reflecting on all this reminded me of being a child and asking my grandfather if his house, which he had built himself many years ago, was finished. Surprised and shocked, he told me that that would never happen! :)

I guess it could be a misunderstanding, I know I can be picky with words. Perhaps (hopefully?) what people really mean when they say “the software is done” is: The software is ready to create value, but flexible for “forever”.

This article has also been published on LinkedIn. Join the discussion here.

About the Series

Surprise-Driven Sharing (SDS) explores moments when established viewpoints are challenged, sparking reflection and learning. Read other parts of the series:

Part 1: Surprise-Driven Sharing (SDS)
Part 2: Surprise-Driven Sharing, again
Part 3: Surprise-Driven Sharing, yet again
Part 4: Surprise-Driven Sharing, hardware and software development are similar?

Welcome to my new old website!

2024-06-18T00:00:00Z

It was sooo overdue! I think it’s reasonable to modernize websites every 20 years. I failed at that. My old website had looked the same since I started blogging in 2003 and, truth be told, it wasn’t nice looking even back then. Its look was one of the reasons I’ve been slow at blogging the last few years. (The other reason is the horrible war in Europe, but that’s a story for another day.)

My colleague Nizar Selander helped me out by using factor10’s Sustainable website platform. The process was quick and thanks to the platform, the technical hygiene is excellent, getting top scores in all tests discussed in this article about sustainable websites. Thanks Nizar!

One hindrance to writing more has been eliminated. Let’s see if the frequency will improve!

DORA och DORA

2024-06-16T00:00:00Z

Som Daniel Melin skrev här så håller jag med om att det är märkligt tyst om EU-förordningen “digital operativ motståndskraft för finanssektorn” (DORA). Finansiella organisationer av samhällsviktig karaktär som inte uppfyller kraven när 2025 börjar riskerar att få dryga böter och de ansvariga för organisationerna riskerar näringsförbud.

När jag först hörde om förordningens namn så tänkte jag på en helt annan DORA, nämligen forskningsrapporten “DevOps Research and Assessment” som bl a för sex år sedan resulterade i boken Accelerate. I mjukvaruarkitektursammanhang så är Accelerate-DORA raka motsatsen till EU-DORA; Accelerate-DORA har det pratats väldigt mycket om i flera år. Inte minst är det trevligt att den med vetenskapliga metoder kommer fram till att organisationer som är framgångsrika med sin mjukvaruleverans är dubbelt så troliga att vara övergripande framgångsrika (t ex lönsamma). För oss i branschen låter det här självklart, men det är trevligt att ha det “bevisat” och refererbart. Samtidigt så är det potentiellt förlösande och glädjande sprängstoff utanför branschen.

Ett av kraven i EU-DORA är att ha en exit-strategi för att flytta sitt system. Jag tycker det är ett bra exempel på krav för resiliens (R i EU-DORA står just för resiliens) och jag använder det kravet som exempel för resten av texten. När jag läste om kravet på exit-strategi tänkte jag att det nog kommer att krävas väldigt mycket jobb för några företag att uppnå möjligheten att på max ett dygn kunna flytta sina viktigaste system så att de fungerar som vanligt igen. Sedan har det lite löst nämnts att tidsgränsen gissningsvis är ett halvår, inte ett dygn. Förordningen specificerar inte explicit tidsgräns, men intentionen kommer förstås att klarna framöver. Mer om det strax.

Låt oss återgå till Accelerate-DORA. Forskarna undersökte åren före boken vilken arkitektur som krävdes för att vara bland företagen som ansågs ha bra mjukvaruleverans-förmåga och de kom fram till följande (citat från boken Accelerate):

We set out to discover the impact of architectural decisions and constraints on delivery performance, and what makes an effective architecture. We found that high performance is possible with all kinds of systems, provided that systems – and the teams that build and maintain them – are loosely coupled.

Jag vet, inte chockerande för er som ägnat era liv åt mjukvaruarkitektur. Jag har använt det citatet många gånger för att motivera till nyttjandet av Domain-Driven Design (DDD), en handbok i lös koppling (balanserat med högt sammanhang, high cohesion). Men behovet av exit-strategi är kanske en ännu mer självklar anledning till att eftersträva lös koppling. Det jag tänker på är att även om det är superviktigt att undvika hård koppling mellan team, så är det ännu viktigare att inte vara så låst till en viss driftsmiljö att det anses ogörbart att flytta systemet till ny miljö.

Det är lite roligt att det finns en korrelation mellan de båda DORA. Om organisationen har toppenbra ordning på sin mjukvaruleverans-förmåga, inklusive sin arkitektur, är det förmodligen “bara jobb” i rimlig omfattning som krävs för att uppfylla de tekniska kraven i EU-DORA också.

Jag gissar att några som påverkas av regelverket tycker att det är överdrivet och orimligt. Som medborgare tycker jag det låter vettigt och närmast som hygien. Jag skulle inte uppskatta att en bank i EU meddelar sina kunder att de inte kommer åt sina konton det närmaste halvåret pga något väääldigt osannolikt (Black Swan?) problem med bankens system. Förmodligen skulle det räcka med ett dygns stillestånd för att skapa väldigt mycket turbulens i samhället. Samhället riskerar att destabiliseras långt före ett halvår om folk inte kan komma åt sina pengar på banken. Därav min gissning att smärtgränsen för exit-strategin i praktiken går vid något dygn eller så.

Jag inser att många organisationer är gravt bekymrade över hur de ska uppfylla EU-DORA-förordningen. Men jag hoppas de kan se det som en möjlighet istället! Detta skulle kunna leda till något bra för dem, bortom att “bara” få ordning på hygienen i form av att uppfylla EU-DORA. Jag föreslår att de, istället för att ilsket kasta pengar på problemet, kastar mjukvaruexcellens på det! På andra sidan hägrar då även den där lilla aspekten av ökad framgång (t ex lönsamhet).

Så låt oss tillsammans få igång diskussionen ordentligt! Hur ska kraven uppfyllas? Vi vill alla över till den andra sidan så fort som möjligt! :)

This article has also been published on LinkedIn. Join the discussion here.

Surprise-Driven Sharing (SDS)

2024-05-16T00:00:00Z

The other day I experienced a very distinct surprise. Picture a situation where you’ve had an internalized understanding for a long time and are convinced that everybody shares this way of thinking. Then, out of the blue, you find out that a person you respect has a completely different point of view.

This happened to me while discussing the creation of an extremely high-end and advanced product that the other person, whom I met at a conference, was involved in. They said that software development wasn’t interesting for their company, as it was mostly about “connecting raw materials”. This took me totally by surprise!

They also said that their IT department might find software development interesting. Well, that might be the case, but I strongly believe that software development doesn’t only affect the IT department. On the contrary, software is ubiquitous for your core domain and for your competitive edge!

After I got over my initial shock, I remembered that very few things, including this, are binary. That said, I do have some thoughts on this matter that I would like to share in the hope that they might prove helpful to others. Surprise-Driven Sharing, eh? :) I am of course also curious to learn more about other ways of thinking about this.

Firstly, I thought about the text “Why Software Is Eating the World”, published by Marc Andreessen in 2011, which carries the message that software-focused companies will have a great development (and why). I think the text was true then and it is even more so today. Let’s, for example, look at the Magnificent Seven Stocks. Their development since Marc wrote the text has been amazing, and one thing they all have in common is a belief in and a culture of software development. In my opinion it’s beyond correlation.

Secondly, I remembered a discussion I had at a big company 20 years ago. They told me that they weren’t about software development; they were about telecommunications. As I recall, they mentioned that even if Microsoft might enter telecommunications within a few years they weren’t too worried about it. That company's valuation development has been negative since Marc wrote his text, while Microsoft (who probably still don’t consider themselves to be about telecommunications) has had a nice development of over one thousand percent.

A third, totally different and more recent example, was when we were discussing the next leap for a certain company. A few years ago they started an initiative to sell software tools to support their hardware business. Now, that initiative has started to get traction. Now, calculations for the probable profit and loss of that new business area are, of course, just guesswork at this point. But almost all predictions show that the revenue will probably grow fast and that the profitability will be higher than that of the old – yet great – business. Instead of 20% profit, my moderate guess is 80% for the new area. Every new customer equals quite a lot of revenue and almost no cost.

So, do I think every company should skip everything else and become a software company? No, I don’t. But I do think that it’s often a very good idea to be evolutionary and add software offerings to what made the company successful in the first place. Your current cash cows are crucial; they just might not be where your strategy for the future says you should focus all your investments. Remember that the s-curve levels out over time. To stay ahead it might be wise to consider breaking the status quo, although one step at a time.

While I’m curiously studying different point of view on this and loving “Think Different”, I do confess that I still lean towards the viewpoint that “software is eating the world” – more and faster than ever.

This article has also been published on LinkedIn. Join the discussion here.

About the Series

Surprise-Driven Sharing (SDS) explores moments when established viewpoints are challenged, sparking reflection and learning. Read other parts of the series:

Part 1: Surprise-Driven Sharing (SDS)
Part 2: Surprise-Driven Sharing, again
Part 3: Surprise-Driven Sharing, yet again
Part 4: Surprise-Driven Sharing, hardware and software development are similar?

Epic relearning

2023-02-07T00:00:00Z

Over the years I have learned that I’m wrong on a daily basis. I have also learned that instead of it being something to be ashamed of, it’s actually something to smile about, learn from and then try to do better. In line with this thinking is the idea that a blame culture is just stupid and counter productive.

However, It’s not always advisable to talk about your mistakes. On one occasion, fifteen years ago, I was in a meeting with some senior decision makers at a large Swedish car manufacturing company. Having told them, proudly, that I probably held the world record in making mistakes, they almost kicked me out immediately. They told me that they never made any mistakes at that company, which was super surprising to me.

I have since realised that one's audience appreciates more careful phrasing. I do celebrate “mistakes” when in experimentation mode, but I try hard to experiment enough so that delivery/production mode is more predictable.

That said, I realised the other day that I’ve needed some epic relearning recently. Not that those mistakes of mine did any harm per se, but they are on a different scale to those I remember being wrong about before. (What proved that the mistakes were mistakes… I mean, what actually happened in the world… Now, that’s extremely harmful.)

As always, looking at mistakes in hindsight makes them look stupid, but I still made them. Here they are:

Even though democracy is far from perfect, almost everybody chooses it over a power crazy dictator every day. - I thought that the whole world has long since believed the same things.
Ugly and primitive wars are something of the past. - I did understand wars weren’t over, but I thought they were decreasing. I thought the trend was clear.
Energy will soon be practically free and in good supply. Also, that in the future, energy is not going to be an instrument of force any longer. - Again, there were large differences between different countries, but the direction and trend was there.

I know, I was utterly naive and wrong on a world-record scale. When I realised that, I no longer experienced the usual joy of relearning. It wasn’t shame, but rather a feeling of misery and sadness.

BTW, it seems like my three errors are connected. If your country abuses your energy system, your country, or neighbouring countries become vulnerable to wars by dictators. That probably goes for abusing your defence and other things as well.

How come I was so wrong? I guess my sheer luck of being born in Sweden is one reason for that. We’ve had democracy for a long time and, overall, it has been good for us. Fortunately, it’s been a long time since we were at war. And thanks to having hydroelectric and nuclear energy for a long time, and wind and solar power more recently, electricity has been cheap. I do know that all this is considered a luxury to many countries. Still, I thought every country was slowly moving in a similar direction, that it was a global trend.

Another reason for my being wrong was that I thought my beliefs made logically sense. Every country should move in that direction while we are coming up with something even better.

Having realised I was wrong on so many different and important matters, it actually took me a while to understand that it wasn’t just a short crumble in the inevitable positive logic sequence. I still hadn’t left my bubble after several weeks. I was sad, but I still didn’t relearn.

When I finally understood, it was a humbling experience. Of course I needed to leave the bubble with an open mind. When I did, I finally became smarter. Unfortunately, I didn’t at all feel like cheering this time. It’s just a period of sorrow.

I hope that there will soon be new epic relearning. Positive this time!

This article has also been published on LinkedIn. Join the discussion here.

Shoemaker’s children and their websites

2023-01-31T00:00:00Z

Let’s assume that you sometimes help companies with strong global brands have a decent technical web presence. What would you consider, from a tech hygiene perspective, when updating your own little website?

A couple of weeks ago, I wrote about how we, as shoemakers, are dealing with our own shoes regarding alignment between goals and metrics. You find the text here (in Swedish):

https://www.linkedin.com/pulse/alignment-mellan-syfte-mål-och-mått-jimmy-nilsson

Today, I continue with that mission with regard to our updated web (https://factor10.com). As shoemakers, what do we have to fix?

I do realise that a website is no better than its content and that’s what really counts. That said, the technical hygiene also needs some attention otherwise it will affect the content readers negatively. Below you will find a few fairly easily used tips for how to improve the technical hygiene of your website.

But before going over to the tips, here are just a few more words about our main character of the day.

What’s the problem with the shoemakers?

Actually, I don’t think there is anything wrong with the shoemakers. On the contrary. Well, of course the kids of the shoemakers should be taken care of, but one way that is done is by having external focus on the shoe buyers. Providing excellent service and quality to the customers is a great way of taking care of their children.

If we move over to the topic of websites… There is only so much time for internal matters such as your website typically is, and since content is king, of course it should come first when there is time over from client work. After fixing the content, maybe also do some tech fix.

I’m rooting for the shoemakers! :) That said, over to the tips. Hopefully you’ll find some of them useful. The first one is…

Tip 1: Check that you have good performance, accessibility and SEO

There’s a multitude of tools out there to check that you have decent performance for your site and that you don’t cause unnecessary friction for consuming your content or finding it. As a tiny consulting company for software development, we don’t rely on search engines for getting new projects, but there is still little reason not to take care of performance in a reasonable way.

Since Google will punish your ranking if you fail in those aspects, they provide a tool that is a good starting point for getting an overview of how they see you are doing. You can find the tool here:

https://pagespeed.web.dev/

Try it out on your own website! Where 100 is max, I reckon 90+ for performance is OK.

Of course this is not a one-off activity because not only will your numbers be affected by changes made to the site (including content) but Google updates their criteria from time to time. Therefore this should be measured on a regular basis (with automation) so as to be proactive about problems cropping up.

In 2020 we had a breakfast webinar on the performance subject which I still think is relevant:

Web Site Performance - Per Rovegård - 2020-11

Tip 2: Not capturing personal information

We have no reason to capture personal information about web visitors, so we don’t. Instead of using Google Analytics, we use Plausible (https://plausible.io) to only gather information about our visitors on an aggregated level. In this way we don’t have to ask our visitors for consent with an annoying popup.

We think it’s reasonable for people to be able to browse websites without unnecessarily revealing identifying information about themselves. Not sending, say, information about Europeans to the US is also in accordance with European law. This leads us to the next tip…

Tip 3: Host in the EU if you’re an EU company

Very much on a hygiene (and actually legal) level, we don’t want to send information about visitors outside of the EU. One easy piece of that puzzle is to host your site in Sweden, for example (and in a Swedish company).

If you are interested in how to think about personal information in the EU, we have hosted a couple of breakfast webinars on this topic. You find them here (in Swedish):

Tip 4: Four eyes content updates

We are strong believers in pair programming and/or pull request reviews for increased quality and knowledge sharing, say. We believe that the same principles also apply for content work on websites.

The content of our updated website can be created/updated with markdown and ordinary git pull requests which are reviewed and approved before they are automatically deployed by build pipelines.

Tip 5: Continuous Integration/Continuous Delivery (CI/CD)

We wouldn’t dream of manually deploying code changes to production. Why do that for content changes? Instead, use a pipeline for taking care of the deployment of those changes too.

The pipeline is also a great place for automatically executing checks. If a problem happens once, a check should be added to make sure the same problem never causes a negative effect again.

Further on, the pipeline is useful to move execution time from when a user visits a page to when the code or content of the page is changed. That means to move from dynamic pages created just in time, to static pages created after a change.

Tip 6: Paying back when using open source

We are big fans of the open source community. When we benefit from open source tools, we think it makes sense to pay back. Some of the open source tools (such as Plausible) were used in a managed manner, so we we’re paying for them that way. On the other hand, with 11ty (https://www.11ty.dev/) we donated a small amount (https://opencollective.com/11ty).

Our company’s design of having a target of 80% invoiced work means the consultants are able to spend work time on open source projects as a way of achieving what we call “personal exposure”. That’s of course a very powerful way of giving back a lot.

Tip 7: Make it harder for malicious actors

Even though we have very few visitors to our website, we don’t want those people to have their safety breached and certainly not due to our site. Therefore we monitor security threats and deal with them when they crop up.

We also use tools to check for common risks. Again, automation is your friend so that your checks aren’t a one time thing, but something that is done on a regular basis and automatically.

The four eyes content updates also help here, making the risk smaller.

Tip 8: And iterate!

After we published the updated website, we used https://webperf.se to get a more thorough review than just through Google’s PageSpeed Insights. A problem well-stated is half-solved. We started with a total grade of 4.36 and, after fixing a few easy things, went up to 4.68.That step took around an hour. My point is that it’s usually easy to quickly fix low hanging fruits. The report mentioned a few weaknesses that we disagreed with, so we skipped them. For instance, we got a lower score since our 404-page is not in Swedish. (Webperf has a mainly Swedish target group, in our case though, and we think that since the site is in English, the 404 page shouldn’t be in Swedish.

We also got a question whether we are fulfilling accessibility to a level of AA for WCAG 2.1. We thought we had a decent level for accessibility, but we had a closer look with https://pa11y.org/ for all the pages and found two contrast problems on one page. That was fixed in a matter of minutes. According to the accessibility expert, we do fulfill AA for WCAG 2.1.

What about the shoemakers?

Going back to shoemakers, it’s always a risk deciding to take care of stuff for yourself which is similar to what you help clients with. One trick might be to take external help to avoid that trap. Therefore we set up a tiny team of our people and external consultant Peter Antonius to do the development of the site.

A fun story is that when the updated site was starting to take shape, we checked performance. While starting the check, I said that I would buy everybody in the company a bottle of wine if the performance didn’t need to be improved in some way. For as long as I can remember the first performance measurement in every situation has always been like that. Not that I was worried, as it’s often quite easy to do the first two performance improvement iterations and get good effects. This time I was totally wrong, the performance numbers were 97+ at first measurement. I have bought wine, and Peter will get two bottles, since he has pulled the most weight. :)

Final comments

These were a few tips on how to improve the technical hygiene for a website when there is time to focus on such things. What do you think should be added?

Finally, is our updated web technically perfect? Of course not! But we do strive for excellence, so when we find something that needs to be improved and we find the time, we will fix it.

This article has also been published on LinkedIn. Join the discussion here.

Miljöhävstång, ett första tidigt bokslut

2023-01-03T00:00:00Z

Då ska vi se, jag har skrivit ett par texter tidigare med förslag till hävstångseffekt för miljö:

Idag tänkte jag dela med mig av vad vi (factor10) har gjort än så länge vad gäller de olika förslagen i de tidigare texterna. Jag fokuserar på de förslagen där vi anar början till en trend snarare än någon enstaka händelse.

Först en kort sammanfattning av förslagen (och ni hittar mer om dem i ovanstående texter):

Sprid info om hur man skriver kod som är mindre miljöbelastande
Fortsätt med remote-first
Gör affärer med rätt företag
Prioritering i tider av hög efterfrågan
Högre PE-poäng för t ex bloggposter om miljön
Föreslå coaching/workshops till företag med miljöhävstång och att det sker gratis
Ny resepolicy
Berätta om miljöeffekt i lösningsförslag till kunder
Ändring av tradition för internkonferens
Klimatretrospektiv på #tillsammanstorsdagar
Låt utrustningen få ett andra liv
Ge bort hjälpsam bok om miljöområdet
Mät och publicera vår CO2-påverkan
Kompensera för det CO2-avtryck som vi inte fått bort

Det var förslagen vi har samlat på oss hittills. Fröet var vår försenade vinterkonferens på Gotland i juni. Över till hur det har gått.

1. Sprid info om hur man skriver kod som är mindre miljöbelastande

Vi har inte gjort så jättemycket här under hösten utöver vad vi tidigare berättat om, men vi har börjat planera för en ny myConf, en kommersiell och global utvecklarkonferens i maj, där detta kommer vara en del i temat.

2. Fortsätt med remote-first

Denna var enkel förstås, det var bara att fortsätta på inslagen bana. Speciellt eftersom alla verkar tycka att det fortsatt är bra.

En oväntad positiv sak (om än liten) för oss som jag lärt mig på sistone är att resor till och från kontoret ska räknas in i företagets klimatavtryck enligt GreenHouse Gas protocol (GHG) Scope 3. (https://ghgprotocol.org/)

Jag trodde det bara skulle belasta den privata CO2-budgeten. I och med detta så har vi alltså ytterligare sänkt vårt avtryck kontra tiden då vi hade kontor.

3. Gör affärer med rätt företag

När vi i höst har valt ut favoritföretag att försöka göra affärer med så har vi i hög grad valt efter vilken miljöhävstång de har framför sig. I skrivande stund så har jag precis kommit fram till två nya kategorier. Det kanske kan bli något att berätta om vid ett senare tillfälle.

En av våra kunder sedan många år som vi är stolta över är Monitor som gör ERP-system för tillverkande företag. De utvecklar och lanserar snart en tilläggsmodul till sina kunder för att redovisa sitt klimatavtryck enligt GHG Scope 1-3 och det kan brytas ner till produktnivå. Vi är inte alls inblandade i den här delen, men jag tycker det är mycket intressant!

5. Högre PE-poäng för t ex bloggposter om miljön

Detta är i sin linda, men den text du nu läser är tredje exemplet på att vi kommit igång så smått med det här förslaget och den fjärde är på gång.

Vi utökar kriterierna för högre PE-poäng för 2023 till att gälla alla sustainable development goals.

7. Ny resepolicy

Denna har vi satt i drift och den har följts fullt ut. I några fall så har det varit resor som tagit över 8 timmar med resesätt som har mindre miljöpåverkan, men som ändå har genomförts på det sättet.

Tidigare så har vi motiverat nationellt flyg med att vi är noga med vår tid och att den ska användas till värdeskapande snarare än att resa. Å andra sidan så är arbetsmiljön på tåg en bra dag betydligt bättre än på flyg (och momenten som hör till en flygresa) så skiftet från flyg till tåg har snarare varit på plussidan.

Med bara några månaders erfarenhet av nya resepolicyn så är huvudfriktionen att utbudet är lägre än efterfrågan på tåg (och då pratar jag inte om jultider). Det leder till stök i bokning och att man inte kan välja de mest lämpade resorna då de helt enkelt är fullbokade. En annan friktion är att långa tågresor t ex blockar möjlighet till videomöten kanske en hel dag.

8. Berätta om miljöeffekt i lösningsförslag till kunder

Ett exempel är en slutrapport vi skrev efter ett analysprojekt helt nyligen. Där beskrev vi risker och fördelar även i termer av CO2 och inte bara utifrån lönsamhet, ledtider och prestanda.

Det är för tidigt att säga hur detta uppfattas av kunder, men jag är ganska säker på att det åtminstone inte är negativt för deras tolkning och val. Ett sätt jag själv tänker på det är att det sällan finns en konflikt mellan olika för- och nackdelar. CO2-perspektivet sammanfaller väl med övriga perspektiv.

9. Ändring av tradition för internkonferenser

När vi hade vår försenade vinterkonferens på Gotland i juni så var en av punkterna att diskutera nästa vinterkonferens á la traditionen. Huvudidéen var Zanzibar. Vi skrotade den idéen till förmån för en plats betydligt närmare och där klimatavtrycket för resan blir en bråkdel. Vi bytte också årstid för konferensen till sommaren för att lättare kunna göra ute-saker i norra Europa. Vår vanliga sommarkonferens (som var en kortare konferens och där respektive ansluter för en fest i slutet) flyttade vi till januari då den inte är lika beroende av väder.

Jag ser denna punkten som genomförd tills vidare helt enkelt. Det sparar i runda slängar 30 ton CO2 för 2023.

10. Klimatretrospektiv på #tillsammanstorsdagar

Vi har i skrivande stund kört detta två gånger sedan vi bestämde oss för det. Vi har helt enkelt reflekterat kort tillsammans om vad vi gjort på området och vilka nya idéer vi har. Det är också en levande diskussion i vardagen och på våra månadsmöten.

12. Ge bort hjälpsam bok om miljöområdet

Inför senaste frukostwebinaret så erbjöd vi deltagarna ett ex av Rebecka Carlssons utmärkta och hoppingivande bok “Exponentiell klimatomställning”. Vi tipsar om att ge boken vidare efter de har läst den.

13. Mät och publicera vår CO2-påverkan

Vi har jobbat på att mäta vårt CO2-avtryck sedan Gotlandskonferensen. Det kommer publiceras om några veckor när vår nya web publiceras.

Överraskande har det visat sig betydligt svårare än jag trodde att åstadkomma korrekta siffror. Det är helt enkelt svårt att få fatt i siffror från leverantörer och t o m att veta hur man bör resonera. Det var för mig oväntat med tanke på att detta är något som organisationer förväntas göra relativt snart enligt EU-direktiv.

Hur som helst så kommer vi publicera vi på samma sida hur vi har räknat (t ex har vi med tjänsteresor såsom flyg och hotell även om kund bokat och betalat, produktionskostnad för vår utrustning och möbler, likaså pendling till jobbet) i förhoppning att det kan vara till hjälp för andra och att vi ska få tips om hur vi räknar bättre.

14. Kompensera för det CO2-avtryck som vi inte fått bort

Vår avsikt är naturligtvis att minska vårt CO2-avtryck ytterligare, men under tiden så dubbelkompenserar vi för det som vi inte har fått bort. Vi har nyss gjort inbetalningar till Trine för vårt uppskattade avtryck sedan Gotlandskonferensen, dvs för juli-december 2022. Detsamma har vi gjort till Creturner. Här är förresten en relativt ny text om Creturner:

https://www.placera.se/placera/pressmeddelanden/2022/11/16/xpecunia-nordic-koldioxid-kan-lopande-brytas-ned-till-fast-kol-xpecunias-dotterbolag-har-lyckats-bevisa-en-egenutvecklad-reaktorteknik-bedomer-det-som-patenterbar-process.html

Sammanfattning på lite högre nivå

Om vi avslutningsvis lyfter blicken lite och funderar på hur vi har förbättrat oss jämfört med tidigare år så verkar vi hamna på strax över 0.6 ton CO2 per person för 2022. (Detta alltså med vår egen beräkning. Vi har beställt tjänsten Go Climate och väntar på aktivering. Där kommer vi ligga lägre då de inte tar med allt som vi har tagit med själva.)

De åtgärder som har haft störst effekt på att sänka vårt eget avtryck är:

7 - Resepolicy
9 - Ändrad tradition för internkonferenser
2 - Remote first

(Dessutom dubbelkompenserar vi som sagt nu för det vi inte har lyckats få bort än.)

Det vi inte har sparat in på är roligheter tillsammans, vi har t ex inte skippat en #tillsammansdag för att undvika några tåg- och bilresor samt hotellnätter.

Jag tycker vi är på rätt väg med vårt avtryck och jag hoppas det kan inspirera till spridningseffekt för att ge hävstång. Med det sagt så handlar det i vår typ av företag om relativt låga siffror. Däremot är potentialen oändlig för att med hävstång hjälpa våra kunder i deras affär och med deras kunder. Där kraftsamlar vi framåt och då inte “bara” med att sänka CO2!

Detta var ett första och tidigt “bokslut” för idéer som vuxit fram sedan i somras. Tre av 14 punkter uteblev då där saknades trend än så länge. Jag räknar med att ha mer att berätta före nästa sommar.

This article has also been published on LinkedIn. Join the discussion here.

Alignment mellan syfte, mål och mått

2022-11-17T00:00:00Z

Jag tänkte här dela med mig av hur vi ser på koppling mellan syfte, mål och mått hos oss på factor10. Vilka förbättringsförslag kommer ni på?

Måttproblem i företag

Goldratt skrev: “Tell me how you measure me and I’ll tell you how I will behave.”

Trots detta ställer företag ofta till det för sig själva med hur de mäter. Ofta är måtten fokuserade på att mäta aktiviteter. Det leder typiskt till att mäta efficiency snarare än effectiveness. Lokalt optima snarare än globalt optima. Det mäter och uppmuntrar till full gas utan att lägga i växel. Det är meningslöst förstås. Värre än så, det är skadligt.

Mjukvarumått

Mjukvaruutveckling har haft liknande bekymmer, men Accelerate-boken har hjälpt mycket! De föreslår följande mått för att mäta “software delivery performance”:

“Deployment Frequency” t ex är ett proxy-mått. Det är inte säkert att kundvärde verkligen skapas, men det är ett leading-mått (som kan mätas tidigt) vilket enligt forskningen som boken bygger på hänger nära ihop med lagging-måttet kundvärde (vilket alltså kan mätas först långt efter att insatsen gjordes).

Tittar man på ett enskilt mått så är det lätt att förbättra. Släpp kod av usel kvalitet snabbt. Det är bra för “Lead Time”. Men det försämrar “Change Failure Rate”. Måtten är tänkta att balansera varandra. T ex att trots att det deployas frekvent så behöver man hålla nere felen. I praktiken visar det sig att “Deployment Frequency” ofta kan öka och “Change Failure Rate” sjunka samtidigt om man förbättrar de 24 förmågor som boken identifierat som de viktigaste!

Vi jobbar mycket om sådant här tillsammans med våra kunder, både vad gäller teknik och affär. Med tanke på att vi finner sånt här intressant, hur är det med skomakarens barn? Frågan är alltså om vi får till vettiga mått för oss själva (factor10) och vår framdrift. Och inte minst hur måttens “alignment” är med våra mål och vårt syfte. Det är dags att berätta hur det ser ut hos oss. Låt oss börja med syftet och jobba oss neråt.

Jag behöll svengelskan då jag inte kom på rätt översättning av “alignment”. Google föreslår “inriktning”, men det tycker jag ger fel association. “Gemensam riktning” är kanske lite bättre? Eller vad tycker ni om “samstämmighet”?

Syfte/ambition

Vårt syfte är:

Vi ska bidra till att göra världen radikalt bättre genom att bli en förebild inom programvaruutvecklingsindustrin.

Det låter förmodligen cheesy för många, men varenda gång jag tänker på det så får jag ståpäls och tycker att det stämmer. :) Mjukvara är ett leverage-område skriver Kent Beck i XP-boken. Det är en del av förklaringen till varför syftet är rimligt att sträva till. Det går att åstadkomma fantastiskt mycket med hävstångseffekt helt enkelt. Antag t ex att du kommer på en utvecklingsförbättring som öppnar en flaskhals och att du därefter sprider den kunskapen då det kan användas i många sammanhang och för många. Effekten blir enorm. Fler sjuka kan vårdas bättre, fler barn får tillgång till skola osv. Bara fantasin sätter gränser.

Mål

Våra mål är:

Kunder väljer och stannar hos oss för att de vill mer med sin affär.
Folk i branschen har utbyte med oss för att de vill mer i sitt yrkesliv.

När dessa mål uppfylls så vet vi att vi jobbar i riktning av vårt syfte.

Vidare så har vi ett mål (eller constraint) för “don’t give away the company”. Vi kallar det guardrail-mål och det lyder:

Stabil kollektiv bonus till de anställda (när resultat >= 20%).

Vi tror också att det målet är kraftfullt vad gäller att uppfattas som förebild. Trots att vi har okonventionella idéer så kan vi ha bra lönsamhet. Rättare sagt… “Trots” ska ändras till “tack vare”.

Mått

Våra mått för de två första målen:

Levererat kundvärde
Poäng för Personlig Exponering (PE)

Måtten för guardrails-målet är:

Antal kunder av viss storlek
Antal nya kunder
Antal konsulter

De fyra första måtten är leading och det femte är lagging. Vi har försökt välja/göra måtten i hög grad till att vara leading. När leading-måttens värden växer fram så får vi löpande indikation på hur vi uppfyller våra mål snarare än långt i efterhand.

PE-måttet

Låt oss titta lite närmare på ett av måtten här, nämligen PE-måttet. PE står alltså för Personlig Exponering och innebär hos oss att arbetstid och budget avsätts för att konsulter ska blogga, prata på konferenser, jobba med open source, osv. När en konsult t ex publicerar en artikel eller håller en presentation på en konferens så uppnås PE-poäng.

PE-måttet är ett proxymått för vilken personlig exponering som vi uppnår totalt för hela teamet. Istället för att mäta på individnivå så tänker vi på artiklar och presentationer som team-arbete snarare än individuellt. Man uppmanas t ex tydligt att ta in feedback från kollegor. Det är dessutom extra viktigt för oss som kör remote-first att stimulera till samarbete.

Även efter parskrivning så ber vi förstås om feedback. Feedback är en gåva, det är upp till mottagaren att bestämma vad göra med feedbacken. När var senaste gången du skrev något som inte enkelt kunde förbättras tack vare feedback av välvilliga och duktiga personer?

Istället för att i slutet av året säga “nästa år ska vi bli bättre på att prata på konferenser osv…” så pratar vi lite om hur det går en gång i månaden. Vi satte för 2022 tre nivåer för att game-a det hela lite på ett roligt sätt. När en nivå passeras så får alla en liten gåva. Vi passerade nyss tredje nivån.

Det var lite kort om ett av måtten. Om det är av intresse så kan jag skriva om övriga också. Vi planerar förresten att lägga till ytterligare ett mått, men mer om det i en annan text.

Vilka förbättringsmöjligheter ser ni bums? Jag är tacksam för alla tips! Och hur ser er "alignment" ut? Det vore superintressant att få ta del av!

This article has also been published on LinkedIn. Join the discussion here.

Miljöhävstång, fler förslag

2022-10-12T00:00:00Z

Det mesta jag skrev om i förra texten om hävstång för miljön (här) har vi (factor10) påbörjat/genomfört. Jag låter det gå några månader till innan vi gör en första utfallsanalys. :)

Intresset för förra texten har varit stort så jag tänkte följa upp med några ytterligare idéer som vi avser att omgående ta tag i.

I förra texten tog jag upp tre sätt för att åstadkomma hävstångseffekt:

Spridningseffekt
Öppna flaskhals
Disruption

Samtliga förslag i dagens text handlar om spridningseffekt. Alltså att bra förslag bara har marginell effekt om de görs av ett företag, men att det blir intressant effekt om alla/många företag härmar. Jag berättar helt enkelt om förslagen och ser om fler tycker de är värda att fundera över.

Över till förslagen. För att förenkla uppföljning i kommande texter så numrerar jag som en fortsättning på förra texten. Därför blir första punkten nummer 10.

10. Klimatretrospektiv

Ett förslag från teamet var att vi bör ha som en stående punkt på våra #tillsammanstorsdag:ar att göra klimatretrospektiv. Alltså att följa upp vad vi gjort på området sedan sist och komma med förslag framåt. Detta har vi gjort ett varv och det är med på agendan för nästa #tillsammanstorsdag.

11. Ett andra liv för hårdvara

Trots att vi medvetet köper hårdvara med låga CO2-utsläpp för produktion (och användning) så kommer det en dag när de inte längre är bra nog för vårt behov. Vi kommer då leta lämplig mottagare för att prylarna ska få ett andra liv före det är dags för återvinning.

12. Ge bort bok som inspirerar och ger hopp

Strax efter jag hade skrivit första texten sprang jag på Rebecka Carlssons bok “Exponentiell klimatomställning”. (Ännu ett exempel på Baader-Meinhof-fenomenet antar jag.) Boken är extremt hoppingivande och rekommenderas! Jag tänkte köpa några exemplar och dela ut i olika sammanhang till personer som är intresserade, t ex på våra frukost-webinarer. Den fysiska boken och transporten har förstås i sig ett CO2-utsläpp, men jag tänker att det kan det vara värt om den läses och leder till positiva saker. Dessutom kommer vi uppmana läsaren att ge den vidare efter färdig läsning. (Och så kommer vi dubbelkompensera, mer om det nedan.)

13. Mät och publicera våra CO2-utsläpp

Vi har påbörjat att hålla koll på våra CO2-utsläpp i verksamheten. Planen är att redogöra för det på månadsbasis på en CO2-sida på vår webb. I och med att vi därmed behöver veta CO2-utsläpp för inköp för egen del så bör det alltså driva rätt vad gäller följande från förra texten:

Gör affärer med rätt företag. Att bara handla av och leverera till företag som på allvar lever en positiv miljöpolicy borde kunna skapa ringar på vattnet.

Jag antar att det också kommer påverka våra leverantörer på ett positivt sätt. Alltså att när de ser att det är viktigt för oss att få denna informationen så kommer de ge den till flera. (Några stora gör detta redan bra, men det är många kvar.)

14. Dubbelkompensera för det vi inte har fått bort än

När vi har kontroll på och tydliggör vårt CO2-avtryck enligt föregående punkt så kommer det driva fortsatt förbättring internt. Dock kommer det förmodligen bli svårt att komma ner till 0 på “kostnadssidan”. Därför tänkte vi försöka väga upp det på “intäktssidan” genom åtgärder som minskar befintligt CO2 eller motverkar kommande utsläpp. Överraskande nog så är det knepigt att snabbt hitta uppenbara val, jag tar tacksamt emot förslag som ni har analyserat och anser bra! De två spår jag hittat som verkar mest lovande just nu är att:

Investera i Trine

Vår investering blir en liten del av stor investering i projekt med stor CO2-minskande effekt. Ett typiskt exempel kan vara solcellsprojekt i Nigeria. Som för de flesta investeringar så riskerar vi vår insats. Det finns också chans att vår insats ger viss avkastning (ca 5% om året), men det är sekundärt i sammanhanget.

För mer information, se https://trine.com

Köpa CO2-eliminering av Creturner

Creturner omvandlar blöt biomassa, främst stubbar och sly, till biokol. Det är alltså restavfall som normalt inte tas tillvara och som till sist förmultnar. Biomassan torkas med hjälp av överskottsenergi från den pyrolys som i en syrefattig miljö omvandlar biomassan till biokol. När biokolen är färdig blandas den med vatten för slutförvaring i uttjänta gruvhål. Därmed elimineras koldioxiden från klimatcykeln.

För mer information, se https://www.creturner.com/

Tanken är alltså inte att strunta i factor10s egna förbättring, bara att överkompensera för det vi inte lyckats förbättra bort än. Kompenserar vi våra egna utsläpp dubbelt upp så tar vi höjd för olika fel i beräkningarna.

Avslutningsvis en extra notering till denna punkt. Jag tycker alltså att det än så länge är svårnavigerat vad man lämpligen gör för att kompensera för de CO2-utsläpp man inte fått bort. Det verkar finnas flera fallgropar. T ex känns det inte solitt att inköp av utsläppsrättigheter sägs ge säljaren fem år på sig att agera. Något längre tid än vad jag tycker är rimligt. Ett annat exempel är att “carbon capture” verkar lida av en del barnsjukdomar. T ex nämns här att flera av de stora projekten inte har levererat i närheten vad det det var tänkt:

https://www.newscientist.com/article/2336018-most-major-carbon-capture-and-storage-projects-havent-met-targets/

Inte chockerande kanske med tanke på att det är i sin linda. Värre är det som nämns i artikeln att:

...in many cases is used to extract more oil from reservoirs

En utvikning på det ämnet som spontant är uppseendeväckande är denna video:

Money Is Pouring Into Carbon Capture Tech, But Challenges Remain

Hur som helst, de förslag jag nämnde i denna punkt är hittills mina bästa förslag, men jag kommer förstås undersöka dessa och alternativ framåt också.

Jag är som vanligt nyfiken på fler och bättre förslag till miljöhävstänger. Vilka är dina bästa idéer?

This article has also been published on LinkedIn. Join the discussion here.

Platform strategy; here, there, and “everywhere”

2022-08-23T00:00:00Z

Some years ago, I wondered why so few companies thought they needed our help. Not that we had too few customers, but it was a small clientele that wanted to engage in deep discussions with us. From the start, we have been at our best working with great companies which are deeply software skilled. An advisor told us to change how we speak and behave in order to become more relevant to the most traditional companies. I can tell a few fun stories from those conversations and experiments, but that’s for another day. That said, we put some effort in that direction. The effect was zero.

I concluded that I was on the wrong path. It wasn’t that we should become more traditional; it was the traditional companies that needed help to make software thinking an integral part of their business thinking. If they, for example, are Tayloristic in every fiber of their being, well, there’s probably not much we can do for them until they see a significant reason to change.

We have continued using our old strategy, namely helping customers to get rid of tech hinders to their business development and open bottlenecks to create new - and enlarge old - revenue streams. At the same time, I have been intrigued by the “platform as a business strategy” for some time now. We’ve learned a lot and I think we will be a great partner for implementing such a strategy.

Instead of a company just selling their products/services to their customers, it is often possible to create an eco-system for the old customers and other vendors, for example. If well done, it will attract more customers and, consequently, more vendors and other service suppliers. And then yet more customers and so on and so forth. The power of the network effect could be tremendous. My old dream of helping many traditional companies is resurfacing! The typical examples of companies using the platform as a business strategy are Uber, AirBnB, and App Store, but the principles are also interesting to more traditional companies.

Since I’ve found this strategy so interesting and inspiring, it came as no surprise to find myself experiencing the Baader-Meinhof phenomenon. It’s like when you are about to become a parent; you see child carriages everywhere you look. I’ve seen possibilities for platform strategies with most prospects and customers ever since. Strangely enough, that wasn’t the case with one of our oldest customers and my closest context.

A while back, I met with an old customer of ours whom we have worked on projects with a few times over the years, although it’s been a couple of years since the last time. I told my customer how eager I was in helping customers with their platform strategies. His response was “that’s what we started 15 years ago and are very successful with, don’t you remember?” At my age, I don’t blush that often any longer, but this was one of those moments. How on Earth didn't I think about them/that the first time I started investigating platform strategies…? When thinking about it, back then, I didn’t realise that they were executing a platform strategy. With my current understanding, it would be very interesting to help out with it in an improved way at the technical level and also overall.

Over to my closest context, which also escaped the Baader-Meinhof phenomenon for some reason. At factor10, we hire the best and most passionate consultants who could just as well have been running single-consultant-companies. (That has actually, from the start, been a descriptor for the people we are looking for.) We provide them with very good skills enhancements and expose them to the most interesting colleagues, and the most interesting customers. The more great consultants, the more great customers. The more great customers… factor10 is creating the eco-system and adding value to it and benefit from it as well. A typical win-win-win. My colleague said to me, “Isn’t it obvious that we are a platform company?” :) To some extent, maybe we are?

Well, of course platform strategy isn’t and won’t be everywhere, but we will probably find it in more places when moving forward. Next time, I’ll write about software architecture and development concerns for implementing platform strategies.

This article has also been published on LinkedIn. Join the discussion here.

Not cornerstones; it’s a stack

2022-08-18T00:00:00Z

Ever since the start of factor10, I have considered Extreme Programming (XP) to be one of our cornerstones. So, as part of the onboarding for newcomers, we thought it would be fun to have a book circle about Kent Beck's “Extreme Programming Explained: Embrace Change (second edition)”. Everyone else jumped on board as well. Such a lovely read; I realize it’s some kind of record in confirmation bias. :)

On re-reading it now, one thing that made a strong impression on me was something Kent wrote on page 53, at the end of the chapter called “Primary Practices”:

The big payoff of XP comes once these practices are firmly in place. Then comes the big step forward: business relationships that directly support further perfection of software development.

That sounds a lot like that Domain-Driven Design (DDD) would fit perfectly after XP, not as another cornerstone next to it which is what I have thought in the past.

It resonates very well with me as, time and time again, I’ve seen that only the most tech-savvy developers find DDD interesting. The newcomers couldn’t care less, if I may generalize. Yes, I know that all generalizations are wrong. ;)

So you have to be fluent with the tech first, standing on solid ground. Probably it’s more correct to split between tech and XP and say that become fluent with tech first and then XP. After that, DDD.

As I write, it occurs to me that I have often wondered why schools don’t teach the students XP practices from the start in every course where it would be helpful. Why do we have to re-program skilled people? I don’t have the answer, but it’s probably a decreasing problem.

By coincidence, I read the foreword by Eric Evans to my book “Applying Domain-Driven Design and Patterns” and found the following section which further explains it (page xxix):

Ironically, to render clear and useful domain concepts in software, to keep them from being suffocated under technical clutter, requires particularly deft use of technology. My observation is that those with the greatest mastery of technology and architectural principles often know how to keep technology in its place and are among the most effective domain modelers.

I recognize this situation in myself right now, in the project I’m currently spending most of my time on. I’ve worked a lot in the past with the main programming language of the project, but it has evolved a lot since I last did real stuff with it. So now I have to fight to get things working, and much of my focus is currently spent on that.

So, XP and DDD aren’t cornerstones; they are more of a stack. That fits well with putting Theory of Constraints (TOC) there as well. Not as a cornerstone, but on top of the other in the stack. Something like this:

Understand development, with a passion for delivery
Understand how to evolve development, XP
Understand business, DDD
Understand how to evolve business, TOC

This article has also been published on LinkedIn. Join the discussion here.

Miljöhävstång

2022-08-16T00:00:00Z

Vi (factor10) har förmodligen ett rätt litet miljöavtryck och det har blivit bättre på sistone. Men vid snabb brainstorming med teamet så kom vi bums på en hel bunte grejer som vi enkelt kan göra…!

Låt oss börja med nuläget innan vi går över på förbättringar.

Nuläge

Vi har numera väldigt lite transporter, inkl flyg, trots att de flesta av oss bor på landet långt från storstadsregioner. Vi kör remote-first vilket innebär närapå slut på vardagstransporter. Remote-first kommer också med en del andra positiva miljöeffekter som jag skrev om här.

En annan (om än liten) sak vi har är att vi för sex år sedan införde supermiljöbils-policy. Dvs att om de anställda ville ha kostnadsneutral förmånsbil så sa företaget ja om det var en bil utan utsläpp. Det låter inte så märkvärdigt, men åtminstone i början så var det dyrt att skaffa en elbil om man ville ha räckvidd på åtminstone 40 mil. Ett sätt för privatpersoner var om företaget lyfte fram de rabatter som företag fick av staten i Sverige. Dock ställde det krav på företagen då bilarna blev dyra i inköp och därmed omöjligt att passa in i många företags “finansieringspolicy” (har jag fått lära mig). Så kanske det var en större grej än jag förstod. Om än liten.

De anställda styr över sin teknikbudget själva, men företaget ser gärna att de försöker välja dator och telefon som duger i 3+ år. Våra huvudverktyg behöver förstås vara vassa, men om de väljs med omsorg så behöver de inte bytas så ofta.

Över till hur vi kan förbättra oss enkelt. Det finns en mängd saker på hygiennivå, av karaktären “just do it”. Det ska man ju så klart göra, men vi är ute efter stor effekt. Hävstångseffekt.

Förbättringsförslag med hävstång

Vi heter factor10 för att vi strävar efter att åstadkomma hävstångseffekt för våra kunders affär och vår omvärld. Det är hög tid att försöka göra detsamma för miljön. Hur gör vi då det…? Vi brainstormade lite och kom fram till en lista som vi kommer börja genomföra bums, men låt oss först prata om hur hävstång kan uppnås.

Spridningseffekt

Jag tänker att hävstång kan skapas genom att vi gör något som är miljöpositivt och som många blir inspirerade att göra detsamma. En liten effekt när vi gör det, men stor när tusentals andra också gör det, gigantisk när det når sin “tipping point” och blir det nya normala för alla.

Öppna flaskhals

Det andra sättet är att vi hjälper till att öppna en flaskhals som i sig lösgör stora miljövinster. Exempel på ställen att leta borde vara inom industrin då majoriteten av utsläppen kommer därifrån eller på ställen som äter utsläppen.

Disruption

Slutligen det tredje sättet att uppnå hävstång är att disruptera en affärsmodell så att det helt enkelt blir överlägset det gamla sättet. Inte med tio procent utan tio gånger bättre (eller mycket mer). Detta handlar typiskt om att tänka helt annorlunda än tidigare, t ex genom att flytta en idé från en annan bransch till en ny situation eller att nyttja en plattformsstrategi.

Nedan följer den initiala listan vi kom fram till.

Sprid info om hur man skriver bättre kod. Raniz presentation som han kört på CraftConf i Budapest och JFokus i Stockholm är ett exempel på detta där han berättar att man kan sänka kallstartstiden från 11s till 0.3s om man skriver om en service från Java till Rust. Men även utan omskrivning så kan man få nästan lika stor effekt med att bara byta runtime från JVM till GraalVM. Potentialen för spridningseffekt är god vad gäller den typen av information och det är bl a därför vi har ett koncept vi kallar Personlig Exponering (PE). PE innebär att budget och arbetstid avsätts varje vecka så att konsulterna kan göra insatser för communityn. Konsulterna förväntas helt enkelt dela med sig av intressanta saker i branschen. (Naturligtvis är allt kundspecifikt skyddat.)
Fortsätta med remote-first. Att vi kör remote-first har vi bl a berättat om här https://www.linkedin.com/pulse/kontanter-bensin-kontor-jimmy-nilsson/ och som sagt här. Eftersom vi tror att det har god miljöeffekt (t ex pga mycket få vardagsresor och mindre uppvärmd yta) så hamnar en fortsättning på det området på listan. Än mer att fortsätta berätta om det för att se om fler fortsätter och hakar på nu när kontorsarbete verkar bli det normala igen.
Gör affärer med rätt företag. Att bara handla av och leverera till företag som på allvar lever en positiv miljöpolicy borde kunna skapa ringar på vattnet. Likaså att ändra kriterier för önskekund. Tidigare har miljöprofil inte vägts in när vi har valt önskekunder. Det nya blir att om kunden har miljöhävstång i sin affär så väger det tungt för oss.
Prioritering i tider av hög efterfrågan. När vi har svårt att boka in alla kunder och prospekt under en kommande period så kan vi använda miljöhävstång i deras affär för prioritering, t ex för att få vara med och genomföra disruption. Vi lämnar naturligtvis aldrig en kund som vill jobba med oss i sticket, men detta är alltså med som en faktor i planeringen.
Högre PE-poäng. Vi har alignat vårt syfte, våra mål och våra mått. Ett av måtten är vad vi kallar PE-poäng. PE-poängen mäts på teamnivå och tilldelas vid publicerad artikel eller konferenspresentation t ex. De blir hädanefter 50% högre om t ex presentationen har tydlig miljöhävstångskoppling.
Föreslå coaching/workshops till företag med miljöhävstång och att det sker gratis. Vi tar alltid betalt för tjänster och vi har en platt prisbild, alla kunder betalar samma. Men vi kan tänka oss ett undantag, att aktivt föreslå gratis coaching och workshops till företag som har miljöhävstång i sin affär. Eller så kan sådana företag höra av sig själva förstås. :)
Ny resepolicy. I väntan på att flyget tar betydande kliv för miljöanpassning så flyger vi bara om alternativet tar dubbelt så lång tid och mer än en arbetsdag. Vidare så vill vi helst ha remote-möten, men det är typiskt vettigt ur lära-känna-synvikel med resor vid uppstart av nya initiativ, vid specifika behov eller för att prata på konferens förstås.
Berätta om miljöeffekt i lösningsförslag till kunder. Det är vanligt att använda sänkta kostnader och höjda intäkter för att jämföra effekter av olika lösningsförslag. Miljöpåverkan passar bra in där också framöver. Vi ska också undersöka om t ex https://www.gaiagen.eu och liknande kan vara hjälpsamt för kunder att få CO2-mätning så att det kan användas som ett KPI.
Ändring av tradition för internkonferens. Tidigare har vi åkt till t ex Mauritius och Sydafrika för vinterkonferens. Det har varit trevligt i januari att få en ljus-boost. Men detta är förstås enkelt att skippa till förmån för kortare resor. Ironiskt nog är resmål i närheten lika dyra som långväga. Vi var nyss på Gotland och det kostade ungefär som Mauritius-resan per person. I och med ändring av denna tradition så ändrar vi tiden för två av våra årliga träffar och har vår huvudkonferens (tidigare kallad vinterkonferens) i augusti och sommarfesten med respektive flyttas till januari.

En idé ytterligare jag hade var att låta anställda som kan och vill gratis ha bisamhällen. Då fick jag frågan om det var som ett bi-drag… :)

Ett exempel från häromdagen

Förresten, jag tror vi kan göra hävstångseffekter i kundprojekten även om kunden ifråga inte har hävstången i sin affär. Vi gjorde nyss ett litet projekt hos en stor kund där ca 30 servrar för CI/CD idle-ade 99% av tiden dygnet runt, året runt. Det ersattes med en lösning motsvarande ungefär en halv server i CO2-förbrukning plus att servrar läggs till automatiskt vid behov till spotpris. Om vi antar att de gamla servrarna fick dålig ström så handlar då besparingen om ungefär 25 ton CO2/år (enligt denna texten).

Förutom att ändringen sparar CO2 och pengar så är det dessutom mycket bättre för deras software delivery performance vilket var det primära målet med projektet. Det behöver alltså inte finnas en motsättning mellan bra och miljövänligt‚ man kan få både och. Märkligt hur win-win oftast är tillgängligt!

När resultatet av detta första projekt har använts ett tag så tror jag företaget ifråga kommer tänka på liknande sätt för många andra områden också. Detta var bara ett litet subset av deras servrar som går på tomgång den mesta tiden. När de sedan börjar prata om det till sina kunder så stimulerar de sina branschkollegor. Det kommer helt enkelt framstå som otroligt slarvigt att inte fixa sådana här lågt hängande frukter. (En kollega nämnde ordet “waste-skam som beskrivning.) Extra viktigt om det är en bransch av väldigt likartade produkter och liten anledning till att stanna som kund hos viss leverantör… Om utfallet blir ungefär som jag tror så infinner sig alltså hävstången. :) Och win-win i alla led.

Faktor 10

Vi heter ju factor10 (alltså \ ˈfak-tər ˈten ), men blir ibland kallade för “faktor tio”. Faktor 10 minns jag var ett begrepp i Tyskland för drygt 15 år sedan. De sa då att om vi ska klara klimatet så räcker det inte att bli 10% bättre. Vi behöver bli 10 gånger bättre. Eller helst mer. Här finns mer info:

https://sv.wikipedia.org/wiki/Faktor_10

Det var det närmaste en namnkrock vi hittade när vi hade valt vårt namn, men där och då kändes det som ett helt annat sammanhang än vårt. Jag inser nu att så inte var fallet. :)

Vilka ytterligare hävstångssaker har ni gjort som ni vill tipsa om?

This article has also been published on LinkedIn. Join the discussion here.

Remote-first, två år senare

2022-08-09T00:00:00Z

Vi lämnade våra kontor i början av Covid-19 (april 2020) och vi har bestämt att vi fortsätter med remote-first. Det finns tecken på att det börjar bli omodernt, men vi kvarstår vid “borta bra men remote/hemma är bäst” som utgångspunkt.

Nedan följer lite tankar skrivna ett par år efter förra texten på remote-first-temat som finns här:

https://www.linkedin.com/pulse/kontanter-bensin-kontor-jimmy-nilsson/

Vad tycker andra?

Elon Musk har på sistone fått mycket skriverier då han verkar anse att det är kontorsarbete som gäller. Det verkar dock finnas andra åsikter bland arbetstagarna. Här är en intressant text om att flexibel arbetsmiljö för många är en extremt viktig fråga:

https://hrnytt.se/arbetsmiljo/flexibel-arbetsmiljo-hogsta-prioritet/

En intressant tweet i juni av @AdamMGrant löd så här:

“You don't need people in the office every day.
The evidence is clear: hybrid work boosts productivity, creativity, well-being, & retention.
Great collaborations don't involve constant contact. They alternate between deep work and bursts of interaction.”

Du hittar hela posten här, inklusive hjälpsam bild:

https://twitter.com/AdamMGrant/status/1534169600522346496

Jag hörde att en myndighet varnade mot att säga till sina anställda att de fick jobba hemma mer än 49%. Annars blir man som arbetsgivare tvungen att köpa bra grejer till hemmakontoret. Jag har inte kollat upp om det stämmer, men oavsett så ser vi det tvärtom. Vi vill naturligtvis att alla har utmärkt utrustning och arbetsmiljö hemma!!!

Varför gillar jag det fortfarande?

Utöver ovan… Jag trodde för två år sedan att konsulterna skulle vilja ha kontor igen efter Covid-19. Men alla har vant sig av med det så pass att det t o m känns som en liten ansträngning att sitta ihop en dag några stycken för att jobba på något specifikt tillsammans. Helt plötsligt inser man vilken overhead man hade varje dag förr. Stiga upp tidigare för att hinna sitta i bilkö t ex. Då ska man känna till att jag bor på landet, en riktigt jobbig bilkö här lägger på kanske 5-10 minuter. Å andra sidan så är den optimala restiden jag tänker på ca 25 minuter också overheadigt värre… :) Otroligt svårmotiverat som en vardagsgrej. Jag har utvecklat en närmast sjuklig aversion mot sådana rutinbilresor. Bör jag söka hjälp? :)

När man har vant sig vid att huvudsakligen jobba från hemmakontoret så känns det också med tanke på miljön märkligt att rutinmässigt transportera sig till och från kontoret. Visst, många av oss kör elbil, men även det innebär viss miljöbelastning. På samma gång har långväga resor också minskat. Betydligt färre resor minskar miljöbelastningen. Likaså att vi skippar att värma upp och städa kontorsytor för kanske 20% nyttjandetid.

En annan reflektion på miljötemat är att jag tror sparad overhead-tid har gjort att jag blivit lite duktigare på att minska matsvinnet. Enligt siffror från Naturvårdsverket står matsvinnet för 7% av CO2-avtrycket att jämföra med 2% för flyget. Båda är petitesser i jämförelse med industrin på 30+%, men samtidigt enkla för oss att minska. (Det är svårare för oss att fixa industrin såvida vi inte får till uppdrag som kan göra skillnad.)

En reflektion som jag inte riktigt vet var jag ska sortera in, men som ändå var rätt intressant i stunden. Häromdagen åkte jag bil och jag hade bekväma sneakers på mig. Efter fyra timmar hade jag fått ont i fötterna! Det hade aldrig hänt förr när jag hade hårda skor nio+ h/dag på kontoret. Är det bra eller dåligt? :) Någon sa att det är hälsosamt att gå utan skor, men för nu får detta vara bara en observation.

Ytterligare en reflektion som jag fångade häromdagen var en kompis på andra sidan Atlanten som sa att han behövde fortsätta jobba hemifrån för att minska risken att få Covid-19. Covid-19 vore förenat med livsfara för honom pga av annan sjukdom. Detta är väl dubbeleggat i det generella fallet. Förmodligen blir vi känsligare när vi inte ständigt utsätter oss för “okända” bakterier och virus. Å andra sidan så är det färre förkylningar, influensor och vinterkräksjukor sedan vi stängde kontoren.

Avslutningsvis så har det definitivt sänkt min stressnivå att jobba hemifrån de senaste två åren. Tyvärr så har det också blivit några kilo upp. I höst får det bli fokus för mig på att använda den sparade tiden till att röra på mig!

This article has also been published on LinkedIn. Join the discussion here.

Kontanter, bensin, … Kontor?

2021-09-13T00:00:00Z

Nu har vi vant oss vid att kontanter och bensin typiskt inte är så viktigt eller typiskt inte är det bästa. En insikt från i somras var att för mig börjar kontor - såsom den centrala platsen för företaget där arbete primärt utförs - hamna i samma familj. Kanske är det fler där ute som har kommit fram till liknande slutsats att "remote-first" är att föredra även framöver?

Vi tar det från början, men först en “disclaimer”.

Context is king

Det jag skriver här gäller för en situation som liknar min, mitt sammanhang. Innan jag går in på min “spaning” för dagen så berättar jag lite mer om min situation.

Jag hamnar ofta och lätt i djupt fokuserat arbete och i långa perioder. Jag är åt det introverta hållet och får helt enkelt energi av att vara själv då och då. Jag har familj hemma så jag får mycket tid med andra människor varje dag.

Mitt företag (factor10) är ett konsultföretag i en kunskapsbransch och vi försöker vara extremt noga med att vårda vår tid. En typisk arbetsvecka innebär arbete med minst två olika kunder och typiskt (pre-covid) arbete hos kund i snitt 1-2 dagar per vecka (vilket jag alltid uppskattar mycket). Arbetet är nästan uteslutande teamjobb och dagligen pratar jag med minst tio olika personer i videokonferens.

Vidare så bor jag på landet, långt utanför storstadsregionerna. Boendeyta här är billigt och äldste sonen av två har flyttat så vi har gott om plats hemma.

Alltså, förmodligen en rätt speciell situation och därmed kanske speciella åsikter.

Kontanter och bensin

För ca 25 år sedan hade jag sällan med mig kontanter i vardagen, plastkort fungerade överallt. Utom när man ville köpa lite bullar till fikat hos en kund eller så, konditorierna var de enda ställena som bara tog kontanter. Idag är det svårt att använda kontanter.

För ca 15-20 år sedan tänkte jag att det nog någon gång skulle bli vanligt med alternativ till bensin och diesel för att driva bilen. Vätgas verkade vara ett intressant alternativ. Kanske el+batteri, men det lät där och då lite löjligt. Nu börjar det kännas märkligt att välja en fossildriven bil.

Mitt liv med kontor

När pandemin tog fart mars 2020 så lämnade vi våra vanliga kontor och alla övergick till att jobba hemma. Vi möblerade och utrustade för att ha bra arbetsplatser, men trodde där och då att det skulle gälla för något halvår eller så. Vi diskuterade när vi skulle skaffa kontor igen och var de skulle ligga. Ett och ett halvt år senare sitter vi fortfarande hemma.

Att jobba hemifrån är för mig personligen ingen stor omställning. Jag började med det för ca 30 år sedan och först för 15 år sedan vande jag mig sakta men säkert vid att sitta på kontor igen när vi startade factor10.

Under min tidigare sitta-hemma-period så fick jag väldigt ofta kommentarer såsom att “ja jag skulle aldrig kunna jobba hemifrån, då skulle jag städa, tvätta osv och inte få något jobb gjort”. För mig var det sällan något problem, jag var alltid fokuserad (ibland stressad) för att uppfylla löften jag ställt ut. Det var snarare oftast enklare att hamna i zonen - när tid och rum försvinner - när jag satt hemma själv än i andra miljöer.

Att huvudsakligen sitta på kontor de senaste 15 åren har definitivt haft sina fördelar. Det är t ex väldigt effektivt att samlas runt en utmaning i ett fysiskt rum och alla som behövs är i samma zon. Och hur många problem löses inte spontant vid fikabordet? Likaså, om man tycker att ett samarbete inte fungerar så bra som det skulle kunna med person på annan plats, då är det ju standardåtgärd att prova att jobba ihop på samma ställe några dagar förstås.

Men sedan vi lämnade kontoren så är också en mängd fördelar uppenbara… Den viktigaste är nog att upptagningsområdet växer för oss för att hitta de bästa framtida factor10-konsulterna. Vår nyaste kollega bor i Varberg, vilket är långt från något av de tre kontoren vi hade tidigare.

En annan möjlig fördel öppnar sig för individerna. Kanske det framöver blir vanligare att man vill bo på olika ställen över året. Kanske leva som nomad eller ha korta lägenhetskontrakt för att byta stad/land ett par gånger om året eller bo hos kompisar under några av sommarmånaderna? För vissa kan detta nog vara en intressant fördel. Fullt ös på jobbet, i övrigt optimering för vad man själv och familjen önskar! :)

Och nu när vaccinet börjar ha effekt och covid-risken minskar så är det också väääldigt roligt och kvalitativt att träffa kollegorna varannan vecka på våra tillsammanstorsdagar.

OK, inget nytt tänker ni nu.

- “Vad är det nya som har hänt som fick dig att skriva denna text?”

Över till spaningen.

Insikt (för mig)

På semestern i somras så körde jag ganska många rundor till Karlskrona och den staden är också en tänkbar plats för ett factor10-kontor. För mig personligen så innebär det en biltur på ca 20 km som tar ca 30 minuter dörr till dörr.

Trots semestertid och att tidpunkten för turerna varierade kraftigt, så hade jag en ständig och tydlig känsla av frustration. Varenda gång tänkte jag att det för mig vore fel att rutinmässigt lägga en timme om dagen för att ta mig till och hem från vårt eventuella kontor. Visst, jag kanske kan klara av några samtal i bilen och det är troligt att det dyker upp lite idéer när man låter tankarna flöda fritt. Fast jag föredrar att motionera eller bara gå en runda istället på den tiden. Idé-effekten blir typiskt större.

Sammanfattning. Med hemmakontor som min huvudsakliga arbetsplats sparar jag tid (över 100 timmar per år), frustration, miljö, olycksrisk, transportkostnad och till och med en bil utan att anstränga mig det minsta! I min kontext, så har jag svårt att få ihop logiken med att jag rutinmässigt ska köra till ett kontor. Blir det 15 år nu med “remote-first”? Vi får se, men för mig känns det nu lika fel att rutinmässigt åka till kontoret som att förlita mig på kontanter och bensin. :)

Nästa steg?

Avslutningsvis, hur kan vi behålla och öka gemenskapen i denna “nya” värld? Vi har lite tankar på området som vi kör, men också en ny och obeprövad idé som vi rullar igång med i höst… Mer om det när vi provat det ett tag. :)

This article has also been published on LinkedIn. Join the discussion here.

What really matters, second suggestion

2020-05-20T00:00:00Z

- suggestions for better outcomes by really working together

Suggestion 2: The business and its outcome is the context

Thanks to the first suggestion, we have the basis of a preliminary bridge for walking over to the other groups to start collaboration, albeit fragile and really just the start. We must continue.

Even with a shared purpose in place, specialists often have a tendency of forgetting the context, and seeing the world from their own area of expertise. They may end up protecting their professional reputation instead of remembering that the business is the context and that they have to constantly think about how to contribute to the outcome. This is even more of a risk when the specialists are working together with other specialists in the same area. They may end up doing activities in isolation...

If you are into Domain-Driven Design [DDD], it will come as no surprise to you that the business is the context. We DDDers are perfectly aware of that, of course. Business == Domain. We don’t stop there, however. Not only do we think about the business overall, we also try hard to understand its different sub-domains/bounded contexts, the relationships and think about which are the core, supporting and generic sub-domains.

Just using the company’s overall business as the context takes as sooo far compared to many whose only concern is their own speciality, for example programming. And what they don’t realize is that not only are they creating less value, it also makes them worse programmers! Oh the irony!

Another example for getting help to focus on outcome is to use XP stories and BDD-scenarios:

As a
I want to
So that --- Outcome!

Given
When
Then --- Outcome!

How come we so often see that activities are just done rather than focusing on outcome? Is it because activities are measured and you “get what you ask for”? Sure, they are often easy to measure, but that doesn’t mean it’s a good idea! There is a high risk of creating a local optima. Only use the measurement if it is perfectly aligned with the global optima and the outcome! Often we create our own worst obstacles to success!

An example that you might have experienced a variation of first hand is to measure and use the number of open problem tickets in the operations department as a basis for bonus. That might lead to a situation where the operations department prioritizes not opening a ticket, or at least not really helping the person in need. Instead the ticket is closed with a comment that rationalizes why. A typical example of local optima. Another example involves a friend who used to work for one of the big three who received a lot of flak during their bug solving week. He and his team hadn’t solved a single bug since they had no known bugs. The manager was furious since it affected his bonus.

So, let’s assume you are planning a trip abroad. There is always someone telling you to “before anything else, get yourself some sunscreen”. Well, it might be necessary… but it’s DEFINITELY NOT sufficient, it won’t take you anywhere! Let’s put that in the perspective of business development.

When it comes to business development, should you focus on being offensive or defensive? Well, just as in soccer, the trick lies in balance and adapting to the situation.That said, it’s each to their own. Some will only ever talk about sun protection. :) It’s a matter of whether people are driven by fear vs driven by excitement, improvement and evolvement.

Examples of defensive focus areas could be compliance and control of risks such as old technology, and these are about focusing on cost. Examples of offensive areas would be to find new markets and expand old. These are to do with revenue.

Of course, you can’t just choose one of them, you need a balance, just like in soccer!

That said, I personally automatically tend to focus on offensive and revenue growth instead of cost cutting. Cost cutting might actually hurt revenue, and you can’t save more than going down to 0 cost. There is no limitation for possibilities of increasing revenue.

A friend of mine has created a concept for invention creation and investigation. He told me the other day that he will give a workshop for a huge company regarding this. Ironically the preparations and setup is a mess because the company is fighting back, doing everything to maintain status quo. :)

So we’ve talked about whether to go forwards or backwards, but what should the organization look like? That is just as relevant, and you can stimulate focusing on activities or outcome with how you organize.

A typical organization might have one department for each area such as marketing, construction, development, and test. An idea is kicked off in the marketing department. It then moves over to construction, who think long and hard and deal with it the best they can - of course this includes having long blaming sessions against marketing, but held in isolation. Then the initiative moves over to development and the pattern is repeated. Lots of blame, almost no feedback. After traveling through a few more departments, the initiative finally reaches the customer.

Each step between the departments means additional friction and delays. It’s also the case that each department has its own budget which it has to motivate and protect. Again, it’s about measuring activity. And on top of that, in this example, marketing is far removed from the client which,of course, is not good at all.

I find the outcome is often far better for the second variant organization which is organized around products instead, having people from each area of speciality working together [AIOD]. You will find there are fewer delays (no departments to toss stuff over the fence to each other) and a much closer proximity to the customers. In this variant, feedback also flows more freely and eagerly.

Developers often hate this at first. “Hanging out with a sales guy? Ouch!!!” It won’t just be a matter of helping out to achieve a better outcome (as if that isn’t a lot in itself), the devs will also become better devs. And, of course, the different specialities can, and should, have their time to hang out too. Outcome first, speciality second.

“Oh, we are doing similar things in two places… That’s super expensive! :(“
Be prepared for such reactions...

If such reactions arise, ask how they would deal with a crisis situation themselves. If they have already experienced it, they might say that all there is time for is working tightly together towards the goal …! “Put everybody involved in a room, lock the door and tell them they can only come out when they are done.” So they have it in them after all… :)

Yet another gap we can do wonders with bridging is the one between business managers and developers. Just as we as developers need to learn about the business, and benefit tremendously from doing that, the managers will benefit by learning more about our area of software development. It’s our responsibility to help them with that. Nowadays the code is mightier than the sword and we have to spread the knowledge!

Let’s have a look at a model. It’s a good example of ”All models are wrong, but some are useful.” Let’s assume the developers’ interest lies in the code and the managers’ lies in money.

Yet there are similarities between money and code. For example, we write code to create value and value is measured in money. Furthermore, maintaining more code requires more developers than a small codebase does. Developers cost money.

So, a model of translating the size of a code base into the maintenance (not initial creation) cost can be very useful.

I know you can tear it down in seconds (for example “then I will write very long lines”), but you do understand the intention and it makes managers really happy. All of a sudden they understand that when you are whining about not wanting to create bad code, it’s only because you are watching over not only their maintenance cost but the possibility of moving quickly when new opportunities open up! The model may not be perfect, but it leads in the right direction!

The size of the codebase matters a great deal! A bigger codebase will drive costs, delays and bugs, and the larger it becomes, the more developers are needed. And more developers will create more code… A vicious circle. :(

Also remember the Mythical Man Month [MMM] even though it’s 40 years old. It describes a formula for how much more delayed a late project will be when one more developer is added.

One challenge with keeping the codebase small is the risk of a desire to predict the future and allowing those predictions to affect the codebase today… Predicting the future is amazingly hard. An example in the Black Swan [Black Swan] describes the controlled situation of a pool table. Even there it very quickly becomes tricky to calculate what will happen. Working out the angle of the first stroke isn’t that hard, but predicting the angle after 56 strokes requires taking into consideration every atom in the universe. Unfortunately, what makes it even harder is that the atoms also move.

When choosing between prediction and being prepared, I prefer the latter. Having a tiny codebase is a great way of preparing for the unknown and to be able to create outcome!

We now have pillars for making the bridge stronger. In the next part we will see how we can bridge the gap even more by using a certain style of work. You find it here << URL coming up within a week or two >>.

References

[AIOD] Sriram Narayan; Agile IT Organization Design
[Black Swan] Nassim Nicholas Taleb; The Black Swan
[BDD] https://dannorth.net/introducing-bdd/
[DDD] Eric Evans; Domain-Driven Design. Tackling Complexity at the Heart of Software
[MMM] Frederick P. Brooks Jr.; The Mythical Man-Month

The series published so far

Part 0: Typical problem situations
Suggestion 1: Start with the purpose
<< This >>

This is an adapted extract from the presentation called “What really matters” that has been presented in cities including London, Sydney, Hamburg, Frankfurt, Berlin, and Cape Town.

This article has also been published on LinkedIn. Join the discussion here.

What really matters, first suggestion

2020-04-30T00:00:00Z

- suggestions for better outcomes by really working together

Suggestion 1: Start with the purpose

With the problem situations and the overall mindset problem of Typical problem situations fresh in our minds, we have a large gap to bridge. Let’s get started with the first question, namely how and with what can a new initiative be started?

Assume we are going on a trip. Should we use a boat, car or plane? It's a silly question... It depends. Are we going to the neighbor for a drink? Or going to live on Mars?

Of course, start with the…

…purpose!!!

Starting with the purpose is the first - and maybe the single most important - step of bridging the gap to really working together.

This may sound obvious and simplistic but in my experience it’s extremely underutilized. Go back home to the office and ask different people in your organization, or your clients, the question ”where shall we start?” I bet you will be disappointed by their answers. And when you suggest that purpose is the right starting point, they may ask what the purpose is…! Others will tell you that this is all nonsense, you are just an idealist. You have to make money. Of course you have to make money, no-one said you didn’t have to. But starting with the purpose and having everyone on board will lead to the positive outcome that you also make more money! There’s no conflict, on the contrary. It’s just a question of what comes first.

Why is the purpose important? For example, if you really love to help people in need and you are working on a project to help beat cancer then you will jump out of bed every day, full of energy and eager to get to work. Every day will be fulfilling. (For further reading, start with [Start with Why].)

Notch, the creator of Minecraft, published on his site in the very early years that the game had to be FUN, everything else was secondary. I have to admit that I was personally a bit annoyed by the quality back then. My youngest son wanted to run his own server and he learned what the word ‘bug’ meant. But according to my son and to a huge population, Notch achieved his purpose. And Minecraft also went on to enjoy success from a financial standpoint.

As a young Swede, I could choose between doing military service or going to jail. I thought about it for a long time, but decided in the end to do military service. As a matter of fact, it turned out to be worse than I had expected… I had a great job and life, but all of a sudden I found myself in situations where officers were screaming like crazy at me and spitting in my face.

However, in the last few years I’ve been reading quite a lot of military theory (for example [Art of Action]) and of course, the militaries understand quite a lot. In fact, I found out that they understood how microservices really should be designed and used 150 years ago! Amazing! A key thing for small, autonomous units to work, to work together and work well in a dynamic setting is that they are aligned to the purpose! Alignment to purpose creates the possibility of autonomy! I forgive my old officers, all they wanted was to turn me and my fellow soldiers into great microservices!

So how do you find the Purpose? A start might be to talk about it with your team all the time and spread energy and positive thoughts about how fulfilling it is to find that you are moving to the purpose every day in all the things you do. Get your team involved in the process and some of them will jump on board. Remember that they also want to have fun, be creative and create value - and find fulfillment. But finding the overall purpose of the organization you are working for can’t really happen without it coming from the very top of the organization and sprinkle downwards. So after warming up on your closest surroundings, go there and inspire them to take action!

This suggestion was a first step of bridging the gap, but the bridge we have now created is still fragile. It might be possible for one person to cross the bridge… But not in bad weather, and not if he carry bags… We have to continue, and my second suggestion is coming up here....

Suggestion 2: The business and its outcome is the context

References

[Start with Why] Simon Sinek; Start with why
[Art of Action] Stephen Bungay; The Art of Action

The series published so far

Part 0: Typical problem situations
<< This >>
Suggestion 2: The business and its outcome is the context

This is an adapted extract from the presentation called “What really matters” that has been presented in cities including London, Sydney, Hamburg, Frankfurt, Berlin, and Cape Town.

This article has also been published on LinkedIn. Join the discussion here.

What really matters

2020-04-28T00:00:00Z

- suggestions for better outcomes by really working together

Part 0: Typical problem situations

The question is how to really succeed with your projects and initiatives, to elevate the business. I’m not just talking about staying within time and budget constraints. Take Microsoft Word, for example. It was launched late and cost more than was budgeted for, but I’m sure most people would agree it was a success. So, how is real success achieved? There are many suggestions and in my 30 years as a consultant in software development, I have created a list of what I think really matters! I will share five of those with you in this blog series, and I’m looking forward to hearing what your suggestions are.

Let’s start by discussing four different situations which I think will help to set the scene. Let’s see if you recognize any of them.

The first situation is from when I was running a workshop about software development and Domain-Driven Design [DDD] for a bunch of military grade security experts. They asked me how new development initiatives are normally started in my field. They were shocked to hear that we didn’t start every initiative by doing a full scale security assessment and information analysis from a security perspective. “That’s incredibly reckless!” they said. I was as shocked as they were, but for a different reason. To me, this was like talking about, say, how big a door should be, without first establishing a context. Who said we were talking about a house - it could just as well have been a bike.

Then we have the top level manager who decides to buy a workflow package off the shelf, before anything else. When the needs are discussed with the domain experts, the conclusion is that there is a need for collaboration support, but it has to be very ad hoc and different every time and mostly about working on the same data.

The third situation comes from a discussion that took place while hanging out in the operations department one day. I mention a potential upcoming initiative to a hard-core operations professional. She becomes pretty irate at not having been asked about the kind of servers needed, the overall capacity, the framework versions, the SLA and the ports to be used. There is nothing to tell since so far it’s just a vague idea, nothing more. She lets me go when she has made it very clear that before anything else, she will be the one to make all the decisions after having received all the detailed information!

The final situation is the example of a newly recruited but very experienced project manager who comes in to run an upcoming initiative. He spends months of work creating a documentation tree and adding a lot of documents. But none of the documents has any content, only headers - because they are templates. Six months later the initiative still hasn’t been described, let alone started…

This is the tip of the iceberg. All these people mean well and are professionals, yet they still managed to run smack into a wall all too easily.

And just so as not to make it sound as if we developers are sitting on our high horses, we might also suffer from similar problems. Who wouldn’t find it even a little bit thrilling to change to the latest and greatest UI framework every third month. And to use Kubernetes and Kafka and…so we can deal with Twitter scale load from day one. You never know… Or the new storage technology that will make the CAP theorem obsolete or to start using the technology that will help services start in a few nano-seconds or even in negative time? :) Or...

Those situations were wrong in different ways, yet there were similarities. To focus on one speciality in a vacuum is not typically a good start. You will achieve “busyness” instead of “business”. It’s similar to riding an exercise bike. It’s nice and smooth to use, easy to measure, no rain… But it won’t get you anywhere.

Don’t get me wrong, I love working with a superb security person, PM, operations expert and so on! They are not wrong as people or functions. The mindset is wrong (in the specific examples I provided)! The collaboration suffers!

So, there were a lot of problem descriptions. The situations I mentioned were all wrong and yet fun to talk about, although that doesn’t help us much. I hate staying with problems, I sooo prefer solutions!!! Let’s leave the problems and move on to something useful. The interesting question is: How can we increase our chances of success in the initiatives we are working on in our daily lives?

I have collected five suggestions. They are able to help solve the sad, negative and overall destructive situations I think we have all seen out there! And, rest assured, there will be a happy Hollywood ending! :)

Let’s get started. All five suggestions address the collaborative mindset and climate. I WANT to bridge the gaps because it’s in the gaps that a lot of interesting potential lies. Let’s discuss what really matters!

First out, suggestion number one, which may be the most important of them all.

First suggestion

References

[DDD] Eric Evans, Domain-Driven Design. Tackling Complexity at the Heart of Software

The series published so far

<< This >>
Suggestion 1: Start with the purpose
Suggestion 2: The business and its outcome is the context

This is an adapted extract from the presentation called “What really matters” that has been presented in cities including London, Sydney, Hamburg, Frankfurt, Berlin and Cape Town.

This article has also been published on LinkedIn. Join the discussion here.

What's in a name?

2018-10-29T00:00:00Z

A few months ago I decided to set up a conference about a subject that excites me (Language Oriented Programming). The subject was easy to pick, naming the conference was harder. With the help from a few colleagues, we finally came up with "myConf".

Maybe you wonder why I think that's a good name?

First, "my" could mean "micro" and I think micro describes the format of the conference. Many other good conferences are very large with at least seven parallel tracks and a thousand or more attendees. That means a plethora of possible presentations to choose from. But in this micro conference, the experience will be quite different. Since there will only be one track, you can expect everyone to have listened to the same talks and that makes the discussions between presentations typically richer. And since there will only be around 50 attendees, you will meet the same people all the time during the day and learn to know a few new friends who share your interests and you will have lunch and dinner with the speakers as well. It's also the case that in a micro conference you will not get a boxed lunch, but a sit down lunch and a very nice dinner, again with your new friends and the speakers. Finally, the conference won't either crash a full work week. After a single, but long day, you will find yourself back at the office, full of energy and inspiration. So, just as I value a very small codebase, I think there are merits to a very small conference as well. :)

The second reason for "my" in the name is that this year the conference is "mine". I picked the subject and invited the speakers that I wanted to listen to. (Of course I got loads of help with all the practical things from colleagues.) For example, I picked speakers that are living legends such as Erik Meijer (creator of Linq and Rx) and Martin Ward (who wrote the initial LOP paper found here: http://www.gkc.org.uk/martin/papers/middle-out-t.pdf). But next year all the fun of picking the subject and the speakers will move on to someone else who will have the feeling of having his or her own conference. Therefore, it will be a conference created out of passion each and every year.

See you at http://myConf.io !

This article has also been published on LinkedIn. Join the discussion here.

Four ways to really motivate

2018-03-23T00:00:00Z

Let’s assume a person has a good income and feels he’s in a secure place. What will motivate that person daily to do his utmost to create value in what he does? Giving that person a raise over and over again won’t do that much, at least not more than for a few weeks or possibly months. With the basic needs dealt with, you need to look elsewhere for creating motivation. The question, then, is where?

The other day I read “Agile IT Organization Design” by Sriram Narayan (highly recommended by the way) and one of many interesting things he wrote was the explanation of how to stimulate intrinsic motivation, namely by mastery, purpose and autonomy. This rings very true for me.

Over the years I have often thought that there are few things as motivating as being in a situation where you feel that you are doing a really good job. This is always fulfilling and is a perpetual motivator. Consider the opposite of going to work everyday with a feeling that all you are doing is a load of garbage, things that nobody cares about and that are of no value to anyone. Could anything be less motivating?

I also think that by becoming good at more tasks (becoming broader) than your “first” speciality is actually helping you to become better at your speciality too. Having a T-shaped competence (or several Ts) is to make your speciality more useful. Overall, I think “doing a really good job” is in the same ballpark as “mastery”.

Perhaps it’s even more important to know about the why of the situation and feeling that it is something that you would love to help out with. If you haven’t read it already, Simon Sinek’s ”Start with why!” is a must. Also, it highlights the entire route from your “highest why” down to the why of every little task. For example, maybe your highest why is to help people globally out of poverty through education, so your daily task of giving lectures is perfectly aligned with your highest why. Consequently it’s easy to see that your everyday life is full of purpose.

I often say that it’s misconduct (in situations that aren’t dysfunctional) to work on tasks if you don’t know why you’re doing them. It’s demotivation on steroids. “Starting with why” is same as “purpose”.

Finally, what about autonomy? I was recently invited to a university to speak to prospect and new students. To my surprise I was twice asked the question “How do you avoid burning out?” I was not expecting that question at all and my spontaneous answer was probably a bit sloppy. I said that if you work with something that you are passionate about and you are in control of the situation, then you won’t get sick. I do realize that this isn’t the full answer, but I do believe it might be very bad for the health to feel helpless and unable to affect your situation over a long period of time. It's not just demotivation, it might even become a health problem.

So, doing a really good job, starting with why and being in control of the situation are all crucial in themselves. Having them all, that’s it!

A wise friend said the other day that it’s important to also have fun in whatever you do! Mastery, purpose and autonomy will lead to fun days, definitely, but it doesn’t hurt to add some extra laughs every day too.

This article has also been published on LinkedIn. Join the discussion here.

How do you overcome a hardware soul?

2016-08-25T00:00:00Z

The other day this painful article comparing Tesla's AutoPilot and Mercedes' DrivePilot was published:
The War For Autonomous Driving: 2017 Mercedes-Benz E-Class VS. 2017 Tesla Model S

The main point of the article is that Mercedes' DrivePilot isn't working well and the tester also even considers it to be life threatening.

I guess that Mercedes beats Tesla when it comes to the build finish and the feeling of quality, but if what the article and the linked articles say is correct, the current DrivePilot function should be taken out of the Mercedes.

Even though Mercedes has a great deal of money, people and hardware competence, for some reason entering a totally new, software focused area is not working out for them. Or could it be for those exact reasons?

As a rule, having a lot of people and money hinders software development, but let's take a look at another hindrance. I call it "hardware soul". You may be fantastic at hardware development but it doesn't automatically follow that you are good at putting together a great combo where development of software plays a large and important integral part.

At the end of 1980s mini computers were hot and at one time I worked a lot with software development aimed at machines from Prime and Bull. When you bought a mini computer from Bull for example, you got the software bundle practically for free, such as Oracle's database server. It was said that Bull's sales people's performance was measured in the number of kilograms they sold. What was important, what was the soul, was hardware. It's been a long time since I heard of Bull and Prime, but Oracle is doing well.

When iPhone was launched, my company carried out consultancy projects for a traditional large terminal vendor. They invested in software too, but from a solid hardware background. We imported iPhones from the USA at the launch, but when we showed them to our customer to shake them up a little, they were totally uninterested and just laughed at it all. I guess they grew tired of hearing about this several years ago. By the way, I think iPhone is a good example of a combo that had a lot of new thinking when it came, both regarding hardware and software.

There are many other examples: due to their software, graphical cards and printers have created a great deal of frustration over the years. A more widely known example was when "smart TV" started out - the whole experience felt anything but smart.

Could it be that in companies with hardware soul, the software is dealt with in a step-motherly way and those employees that are seen as being the least skilled regarding what is "important", i.e. hardware, are put in just to make it? Or that the "not invented here"-syndrome messes with the hardware soul so they think they are also the best at doing software on their own? Or that they hire the cheapest consultants they can find?

Anyway, there's nothing new here. A colleague mentioned this phrase that stuck with him something like 25 years ago: "You have to see software as the heart and soul of a system, not a coat of paint."

I totally realize that I'm kicking in open doors here. But let's end with what is interesting. As an organization, how can you deal with the problem of having a hardware soul when you don't want to share the same fate as the dinosaurs?

I think that just leaving the whole thing alone and letting it slowly evolve into a balanced soul is a recipe for disaster. Staying true to the hardware soul and skipping the software ambitions is probably a good way of maintaining the status quo for quite some time. But it's also like giving up, I think.

I think one easy solution that stands a good chance would be to start a new, tiny, autonomous organization and leave the old one alone. That way, the soul of the old organization will not fight back too strongly for the new initiative to succeed.

But having just one suggestion for dealing with such a large, common problem is a bit poor... On the other hand, is it really possible to change your soul? As I said in the title, is it at all possible to overcome your soul in order "to overcome a hardware soul"? It's like a teenager telling her grandmother that she looks weird in teenage clothes, but instead of getting the grandmother to relax and accept who she is, she tells her to work on getting really with it. To change her from inside, to overcome, which of course doesn't make sense.

Could that be why I only came up with one good solution and that that solution wasn't about changing, but creating something new? Is the answer not trying to "overcome your soul", but creating a new one instead?

A powerful gift (tool)

2016-05-04T00:00:00Z

This Easter I was skiing in Austria with my wife and youngest son. It was odd to see a sign saying +14 degrees Celsius when entering a lift gate, but it was still possible to ski. Well, somewhat at least. And only until noon. :)

Yet something I remember even more happened a minute later in the same lift queue. The three of us were lined up next to each other to go in the same lift when a small eight-year-old boy leaves his skiing school group and says to his teacher in English that he wants to go with us. We find it a bit strange and try to gently suggest that he stays with his group, but he's very persistent. Anyway, as we are all going to the same destination it shouldn't be a problem.

As the lift moves away, he starts talking. A lot! And in Swedish. He tells us that he lives in Belgium, but that he's from Sweden. He's fluent in English, German and French. His family has a holiday home on Gotland (Sweden's largest island). And he tells us a lot more. :)

The main reason I remember this small event was that it brought something else to mind. He didn't know us. He had never seen us before. He only heard us in the lift queue quietly speaking Swedish for maybe fifteen seconds. That was all, and he immediately identified with us and wanted to be with us.

What an amazingly powerful gift (tool) it is to share a language, especially in the context of lots of other languages, such as Swedish in Austria. In no time at all, it creates understanding and togetherness. Mind blowing!

As a developer this can be used to a huge advantage if you really want to connect with your domain experts. Make an effort to speak their domain language, and you will stand out next to most other developers.

The opposite is also true. Just try speaking developer language with a domain expert, using words like higher order function, repository and bitwise operation. It only takes a second for them to zoom out, become bored and leave, not just mentally but also physically! If you stick to the domain language, they will love to hang out with you!

As with any tool, the language can be used both to your advantage and disadvantage. Used well, it's a very powerful tool! Used poorly, it's also a powerful repellent!

Which curve do you choose?

2012-03-23T00:00:00Z

Important code should be tiny, beautiful, and in control. Anything else is a waste of money. To me it's so obvious and internalized that I forget that not everybody sees it like this. It's hard to have a quality discussion with someone if your opinions differ greatly as you will both be puzzled and then – nothing. It recently occurred to me that many people automatically agree that bad software quality is expensive, but don't really believe it deep down.

Let's have a look at two realities (curves) that we can choose between. To many it's a law of nature that it becomes extremely costly to make changes in software. They think that software must rotten over time and it happens pretty fast.

Boehm's curve (from the book Software Engineering Economics) indicates that the cost of correcting an error will increase exponentially over time in a project. I guess it's possible to understand it so that costs will continue to increase after the first version is in production, leading to changes becoming more and more expensive. This means that all decisions must be taken very early in the life cycle so as to not cost a crazy amount.

Of course it doesn't have to be like this. Beck's curve (from the book Extreme Programming Explained) indicates another way it can be; instead of the cost growing exponentially, it will level out.

This is where how beautiful the code is, how large it is and if it is in control comes in. To create the second curve, there are very high requirements for the state of the software and how it is continuously cleaned up, how it is redesigned, and if it has good automatic tests and automatic deployment, and so on. A combination of many well executed actions will lead to the software being changeable. The value of this for the business is, of course, potentially great.

Maybe the two different beliefs are the reason behind stupid decisions you see being made. But when you have realized that there might be the differences in basic beliefs, it's suddenly not so strange anymore. That's not to say that you necessarily agree with the decisions, but when you understand where the other person is coming from, at least it's possible to understand why the choice was made.

By the way, if you think that you and your organization are careful when you develop, but you still arrive at the first curve, then unfortunately it's probably the case that the code isn't all that great after all.

To summarize: if the software is changeable without incurring dramatic costs even late in the life cycle, it will change everything in the software development thinking.

Unfortunately there's a catch. The "flat" curve is way harder to achieve. It's possible, yes, but not something to take lightly. Anyway, it starts with a choice and I will return to how it can be achieved in an upcoming chronicle.

Have you decided which curve you would like?

(First published in Swedish as a developer chronicle here.)

Don't cheat with the user interface

2012-02-19T00:00:00Z

It's a paradox that many developers who have a large interest in design and maintainable applications often say something like: "Anyone can take care of the UI, it's not possible to do that much damage there anyway."

Part of the paradox is that the largest amount of code, the ugliest and therefore also the largest maintenance problem, has a tendency to end up in the user interface (UI).

Another part of the paradox is that the success of an application largely depends on the user experience. Sure, the better the code/design is that the UI consumes, the larger the chance that the UI can also be good. But it doesn't happen by itself that the UI code becomes good. In fact, it's often the opposite.

You might recognize some of these examples.

The rendering of UI and logic has been mixed into a soup. When the rendering is to be swapped, it's clearly obvious that the logic is affected too.
In the large application the logic has been split in different parts - in a good way. For example in accordance to how often they change. The exception is the user interface that is one single monolite where it's very hard to change the different parts separately.
After a lot of pain and effort, the team is gaining a lot from automatic testing. Except for the user interface. Unfortunately it often needs refactoring and thereby needs the safety net that automatic tests provide.
Good design is used in the domain model, for instance, so that with little code and right abstractions it successfully describes the solution to the problem. But the user interface is done in a "brute force" way, almost totally without abstractions.

Most developers are resilient sorts, but I don't think we should accept what we get from the tool vendors as-is. Tools should often rather be seen as platforms that can be used to develop specific frameworks on top.

If you do as the vendor proposes, you can often expect verbosity in the code and large, hard to maintain codebases. Most often, the vendor hasn't eaten its own dog food. It's not until the tool is used in real projects that the experience and knowledge of what is good and bad emerges - and how the good is used in an effective way.

An indication of the problem is that to most developers design means quite different things, such as in the domain model and the user interface. Of course good software development design in the UI as well is extremely useful (and not only "look-and-feel"-design)!

The user interface has always been important, but has often been treated as the poor relation. The largest maintenance bottleneck is often found in the user interface. Now and in the future, that area requires and deserves to receive a lot of focus.

An interesting approach is framework oriented user interface development. It's anything but trivial to do well. Yet the potential is enormous!

(First published in Swedish as a developer chronicle here.)

The next big thing is extremely small

2012-01-18T00:00:00Z

In software development we are constantly looking for the Next Big Thing. We haven't given up hope of the silver bullet... one day it must show itself.

It might not be the silver bullet, but I bet a nickel on the next big thing being small, extremely small. We are at the beginning of the era of tiny.

We've had three different eras:

The era of following one big vendor and nothing else.
The era of using many large open source frameworks.
The era of tiny.

If we go 10-20 years back in time, we find ourselves in the time I call "follow one big vendor and nothing else". You found all you needed at one single place. It seemed to be simple and it seemed to be safe. You were taken care of and didn't have to think for yourself all that much.

Often the tools helped you quickly create loads of ugly code that you then had to maintain. There was a lot of focus on "drag till you drop" instead of writing code.

Large database oriented programming models and large solutions to create the illusion that it wasn't the web when you were developing for the web were often used. When the vendors were demonstrating their solutions they often said: "And all this without me writing a single line of code." When you looked at the result behind the scenes it made you cry, but not tears of joy.

After a while some people lost their tempers and there was something of a revolution. About ten years ago and up until now there has been more and more focus on open source and strong communities. Large, generic and important frameworks grew up and were used a lot. Let's call this era the "use many large open source frameworks".

The focus was on agile development, DDD, elegant code, TDD, craftmanship, MVC, O/RM and REST. A lot was good and sound, but a common problem was that whoever used the most number of design patterns in his solution won. It was also now many of us learned – the hard way – that large, generic frameworks shouldn't be invented. The chance of success increases radically if you harvest them instead.

The third stage which is currently emerging is more evolution than revolution. I call it "the era of tiny".

A lot is still around from before, such as test-driven, real DDD and focus on superb code. However, there is a little less focus on using communities and open source projects in order to find all you need in the form of large generic frameworks.

Instead the focus is on turning inwards and solving tasks with tiny, specific framework solutions without all the unnecessary extras. An alternative is to have dependencies to extremely small code snippets that solve one single specific task in a good way. Often those are used as code instead of as binary.

A typical example to make the cooperation between developer and client even better is to use domain-specific languages so that the documentation is also executable.

If you receive the following comment...

Have you solved the problem with that tiny solution? That's not very "enterprisey".

...then you have done something good.

(First published in Swedish as a developer chronicle here.)

Developer Chronicle: Too many chefs spoil the code

2011-05-10T00:00:00Z

Let's start with a fairly common question:

"Ouch, we're so behind with the project, what on earth shall we do?"

A response that is just as common is:

"Add more resources! Increase head count as much, and as fast, as possible!"

Honestly, how many people have responded so spontaneously?

Over 35 years ago Frederick Brooks wrote the book "The Mythical Man-Month", where he shows a formula for how to calculate how much the delay increases in a delayed project if you add one more person. How is it, then, that so many think it'll help?

What is even worse, apart from the delay being likely to increase, is that projects with too many people involved have a tendency to lead to a large code base. It is to be expected as a law of nature. It can of course be too large a code base for many other reasons too, but this is one important factor.

Each developer would naturally like to be productive and, just like the others, add X number of lines a day. So the growth of the code base size is directly related to the number of developers.

Even if I am allergic to projects that become overcrowded over time, there's something I dislike even more. That is projects that start to be overpopulated on day one. On top of the problem with too large code base there is an additional problem with X amount of people that are waiting for something to do, which costs a lot to no avail. Pretty soon everyone starts to create their own architecture. Similarly, requirements are created wildly on speculation. The project is simply in a very bad position from the outset.

Why does this happen? I think one reason could be that many people see software development as a keyboard intensive task. Sure, it never hurts to be fast on the keyboard, but it is mostly because the keying should not distract the thinking and the mental models.

If you are twice as fast at the keyboard as your colleague is, are you twice as good as your colleague?

Perhaps, but if you believe a quote from Bill Gates where he should have said that a super programmer is worth 10 000 times higher salary than a mediocre one, your double speed keyboard skills should be a very small advantage. Probably other stuff is way more important.

When I think about it, we have a saying for this phenomenon; the adage is probably much older than Brooks's book and it goes: "too many chefs spoil the broth." So, avoid adding loads more head count on the problem at all costs.

(First published in Swedish here.)

Developer chronicles

2011-04-18T00:00:00Z

I've been writing the developer chronicle for Computer Sweden (in Swedish) for a couple of months. I'm going to republish the articles as blog posts. The first one is called "Lasagna is not a good role model".

Developer Chronicle: Lasagna is not a good role model

2011-04-18T00:00:00Z

How about a spot of banter about an architectural phenomenon that I often see in various projects? Since I've made the same mistake in many projects, I guess it's okay to joke about it.

The phenomenon I'm referring to is that there seems to be an architecture principle in many projects which says "the more layers the better." The principle is very common in .net and java projects, especially in the projects known as enterprise projects.

Why does this happen? There are many explanations, but the following stand out as the most common:

"It can be good to have many layers. You never know when a layer might turn out to be useful."
"Person X / Book Y says it should be like that."
"Everything should be similar and follow the same structure."

I think all the reasons above are really bad. The first is an excellent example of accidental complexity. Speculation in advance increases complexity. It is best to resist speculating and make things as simple as possible instead so that they are changeable when, or if, needed.

The second reason is lacking "context is king". No solution is always the best; it obviously depends on the situation.

But perhaps worst of all is the third reason. The code should not be similar because there are different problems and different situations or if it can be similar, it sounds like a serious violation of the DRY (Don't Repeat Yourself) principle. Probably it should not be hand written at all.

Someone wrote a while back that "Architecture is like lasagna. The more layers, the better. "I totally disagree, both in terms of architecture and the lasagna. The taste is not in the number of layers. In fact, that quote makes me long for spaghetti.

What are the drawbacks when having too many layers?

When something is changed, there is a tendency that the change affects more than one place in the code due to all the layers.
You get tons of completely uninteresting code which means that there is more to read and it takes longer to locate what you are looking for.

In short, it becomes more expensive to maintain.

There seems to be a common tendency for developers to follow a cyclical pattern. At school an early project starts with all the code in a single layer.

Then you move on to an extreme amount, maybe eight to twelve layers, finally becoming situational and allowing the solution to the problem decide the right number.

The approach I recommend is that you do not focus on layers at the start of new projects, but focus on understanding the problem and describing the solution as simply as possible.

As the need for more layers proves itself you add them, but only after having critically evaluated the value relative to the cost.

You won't win by using more layers than anyone else.

(First published in Swedish here.)

More than 10 000 km apart...

2010-03-23T00:00:00Z

...but the problems are the same.

I was in a phone meeting some time ago with a big Asian company to discuss their problems. They were eight participants, and only one spoke and understood English. So when I said something, the English speaking guy spoke their language and I didn't understand at all. And the same when they discussed things before telling me. The situation and meeting was very tricky and made me nervous and uneasy. Large distances in language, culture and geography... Until they told me about their problems. All of a sudden, the meeting was transformed into well-known territory.

New TDD course

2010-02-18T00:00:00Z

factor10's course "Test First with TDD" (or "TDD på riktigt" in Swedish) is given as an open course for the first time in Malmö in Sweden in April. You can find more information and book a seat here.

Oh, and the DDD course is taking place next time in Stockholm in April.

It works both ways

2010-02-18T00:00:00Z

I've spent a good part of my career trying hard to better understand the businesses I'm developing software for, since that helps a lot in delivering more value. This is not anything I'm done with. On the contrary, it's something that I find increasingly important. You can't program what you don't understand. Period.

This works both ways. If a business person wants their software development projects to be more successful, it pays off immediately to show an interest in the projects, to get involved with them and learn more about software development and all the changed and rapidly changing rules. For instance, in order to be able to adjust a software project for the better, it helps if you understand what is going on so you know what you'd like to change.

Drivers for NOSQL

2010-02-18T00:00:00Z

About two years ago I gave a few presentations about how relational databases are facing more and more competition and that several factors indicate that we will be choosing other ways of storing data in the not too distant future.

The term NoSQL was created last year and has morphed into NOSQL lately (Not Only SQL). This trend is rapidly gaining strength. Below I have written down some of the drivers behind the NOSQL movement. Which ones are missing?

TDD and DDD
For many, this changes the picture completely. The focus moves away from the storage technology.
Application databases instead of integration database
Then the storage technology that is used is a private concern of the service/application itself and the decision becomes less dramatic.
Internet scale
The need for scaling out is changing the scene for certain scenarios and eventual consistency is most often good enough.
We don't need many of the common capabilities for certain applications/services
And we just don't want to pay a high cost for impedance mismatch if we don't get other large benefits.
Querying and analysis finally moves away from the production databases
Just an example of one reason why we have less of a need for functionality in specific situations.
Certain types of applications don't fit the relational model very well
A classic example is "bill of materials". Nowadays social networks is an often mentioned example.
Event sourcing is growing in popularity
This might mean that you only need a persistent log file for that part, a pretty basic need.
Need for rapid schema evolution
Or very many schemas, or no schemas.

The DDD course in Malmö

2010-01-20T00:00:00Z

It's time for factor10's course "Fast track to Domain-Driven Design (DDD)" again (in Swedish). This time in Malmö in a few weeks.

A new and good "VB"

2010-01-20T00:00:00Z

As I write this, the yearly SAW is under way. One of the subjects I put on the table at last year's workshop was that I thought (and still think) it's about time for a new and good "VB".

What do you think? Has it become significantly easier to build software since 1991? Have we as a group become significantly more productive? (If so, would you say "yes" even if we take maintenance into account?)

VB had its merits and its flaws, but I think it represented a big shift in productivity for a big crowd. That said, it's not exactly a new VB I envision. It's something kind of in its spirit, but something that doesn't put lots of obstacles in the way of creating good software. It should help in creating software that can be maintained and taken further, maybe by more skilled developers if needed after the first successful application is built and used for some time. Probably also in making it easy to involve business analysts, domain experts, testers...

As I wrote here, there is no lack of new RAD tools ("drag till you drop" etc), but they are not focusing on creating expressive and beautiful code, maintainable software. Is it a law of nature that approachable tools must create bad results below the surface? I don't see that. (Please note that I don't expect a tool to make design and software development easy, that's definitely not what I'm talking about. I just don't think it has to add lots of accidental complexity either.)

Why so little (no?) interest from the big vendors? It seems quite easy just to harvest some obvious and proven good ideas and concepts to put together in a nice and approachable package to take a big leap, and I think it would represent a huge difference for loads of non-alpha geeks. Sure, it's a moving target, but this might not be moving at all as fast as some of the current RAD attempts...

I put together my own toolbox as do many others, of course. We would probably do that anyway, but that's not the case for everybody. As I understand it, lots of developers go with the tools they get in the single package from the single vendor of their choice.

OK, there are attempts here and there for what I in the header called a new and good "VB". Those attempts are as far as I know from small vendors (and open source of course) and I guess this will spread.

Or maybe the "situation" will have been solved at SAW in a few days?
:-)

The big picture of software development

2009-12-16T00:00:00Z

Very often when I have tried to understand certain situations that have cropped up over the years and tried to explain where I believe the problem lies, I find myself using a certain simple model again and again. I should have written it up a long time ago, but better late than never, eh?

The model is based on the fundamental questions of Why, What and How.

Why do we exist?

That's a pretty philosophical question. However, in the context of why we as developers exist, why we are needed, why companies pay us to write code, I believe the reason is that we are expected to create business value. That answer would seem to be pretty reasonable for most people in most situations.

What is it that we do to create business value?

I think the answer to that question is code, great code! It's not only the code itself, but its surroundings too, like tests, docs, build scripts, and such. Yet the very code itself is of crucial importance.

If we are in control of the code, then the business people can come with a request for a new feature that will create a new business opportunity and we can achieve it in a matter of, say, a few weeks. A couple of changes in the codebase might translate into millions of dollars. That codebase leads to high business value and the cost for achieving it is low.

The opposite is a codebase that has rotten to the extent that nobody dares touch it at all. The developers walk around it, they even leave the company just so as not to have to work with it. That codebase might need years before it can achieve the afore-mentioned business opportunity. Time to market, risk and cost of change mean that the business value of this codebase is very low.

(There are of course ways of transforming a bad codebase into a great one, but that's another story.)

How do we create great code?

How you achieve great code varies. Some techies would spontaneously suggest Test-Driven Development (TDD), Domain-Driven Design (DDD), architecture-focus, refactoring, and so on. You just add here what works for your team, the stuff that let your codebase add business value.

What I find over and over again is that a good many companies have focused all their attention on implementing a new process. Which process doesn't seem to matter, it varies over time and lately it has been Scrum. It has been seen as a panacea. At first it seems to go very well, but after just a few sprints, the velocity drops. The reason is that the codebase and the architecture haven't received any attention at all... Sure, a suitable process can often help a good team to become even more productive, but it won't compensate for lack of skills. So, I added "Iterative process" as an example of something that is part of the picture for achieving good code. My point is just that it's most definitely not the only thing, of course it isn't. (Also read my factor10 colleague Niclas' blog post called "The holistic view".)

If I had to pick the one answer to how, I believe that the single most important way of achieving great code is to have the best people that you could possibly find. To have only a few, as few as possible, but not fewer. On top of achieving great code that would actually also let you achieve it cheaply. Of course you would have to pay more for the best, but they will be extremely productive (for real, not a fake) and since you only have so few, that also makes the financial side very appealing.

I find that quite a lot of people strongly believe that products will help a lot. After 20+ years in this business, I believe that products are more often the problem than the solution so care must be taken.

In the same way there is the comment about companies believing they need expert help from the vendor of the product they are having trouble with. To me, that's a smell regarding that product.

"We can't solve problems by using the same kind of thinking we used when we created them." --Albert Einstein

Another silver bullet that doesn't work – on the contrary – is trying to solve the problem by increasing the head count. That's just a good way of increasing the problem and the cost. Quality over quantity, every day!

To summarize what I said above, here's a sketch:

Some more comments

Techies immediately seem to agree with this model. But, and this might come as a surprise, business people seem to like it even more. They might say something like: "So that's why the developers are complaining that I don't value quality. I used to think it was just whining, but now I realize it's about sustainable business value."

Quite often I find that developers ask questions such as: What feature shall I do first? Where shall I focus my refactoring efforts? What automatic tests are the most important? According to this model, there's a clear and simple answer to those questions that points us in the right direction. Choose whatever gives the most business value.

A colleague of mine goes as far as using the code quality of the important codebases for determining if a company will have a chance for success or if it will go out of business. If we aren't fully in control of the codebase, that's a setup for failure. (Obviously, these companies are not automatically doomed, not if they grasp the situation and act with power and intelligence.)

So, the codebase is probably quite important, perhaps the most important asset of the company. It's not something you allow just anybody to work with and make changes to. It's like if you need brain surgery; would you allow someone who had just done a crash course in brain surgery to operate? Of course not, you would probably try to find the best and most experienced person there is. That's quite the opposite approach to how codebases are dealt with in many companies.

Fast Track to DDD in Sweden

2009-10-23T00:00:00Z

factor10's course "Fast Track to Domain-Driven Design" goes to the Northern hemisphere too, in Stockholm in November by little me. More information (in Swedish) here.

It should be easy to build good software.

2009-08-20T00:00:00Z

Earlier this year I was asked by a large vendor to review an early draft of a new tool. The idea of the tool was to help developers become more productive, that is, to make it easy to build software. But as soon as I started looking, I got the feeling that it wouldn't help the productivity when creating good software (and the more I looked, the more apparent it became).

That particular tool doesn't matter, but thinking more about it, unfortunately it actually feels like it's been the same thing for quite a few years and for quite a few development tool vendors. It's obvious we need a much more interesting goal, isn't it?

It should be easy to build good software!

DDD in the cloud

2009-08-20T00:00:00Z

I'm going to give a workshop about DDD in the cloud at Progressive.NET in Stockholm next week. See you!

Fast Track to DDD in South Africa

2009-08-16T00:00:00Z

I think Aslam Khan has written some of the most interesting pieces related to DDD lately. Now he will teach the two day course "Fast Track to Domain-Driven Design" in Cape Town in early September. You find more information here.

The CCC-article translated to Chinese

2009-04-14T00:00:00Z

Xiaogang Guo has translated my CCC-article into Chinese. The article will be published in Programmer Magazine in an upcoming issue. You find the translation here.

Article: Chunk Cloud Computing (CCC)

2009-03-29T00:00:00Z

As a follow up to this blog post I have written an article called "Chunk Cloud Computing (CCC)".

Some observations over the last few years

2009-03-27T00:00:00Z

Before: Focus on layering
Now: More focus on partitioning

Before: Focus on loose coupling
Now: A balance (include high cohesion)

Before: Huge teams
Now: Extremely small teams

Before: Integration database
Now: Application databases

To be continued...

Strategy workshop about Data Access

2009-01-06T00:00:00Z

I've developed a workshop called "Strategy workshop: .NET data access" and Programutvikling in Oslo, Norway, has invited me to run the workshop as an open workshop in a few weeks. You find more information here (in Norwegian).

Here are a few extracts from the description in English:

"There's a lot going on right now in .NET land when it comes to data programmability.
...
There are many choices available now and each choice has an impact on code quality, maintainability and, overall, bottom line costs.
...
At the same time lots of .NET developers are starting to embrace Domain-Driven Design (DDD) and Test-Driven Development (TDD), which change the scene much more than most people at first realize.
...
Suddenly, the choice of data programming options is a strategic decision. What data programming option must I choose so that my teams can spend more time on solving the problem and less time on how to get and save the data?
..."

NWorkspace == Nilsson Workspace?

2009-01-06T00:00:00Z

I heard a rumor about someone being upset with me because I had named a little framework after my own name. He thought the N in NWorkspace stood for Nilsson. Well... No.
:D

And when I'm at it, that's not the case for NUnit, NHibernate, NPersist, NDepend or NCover either...

Oredev 2008

2008-11-16T00:00:00Z

There is going to be a DDD-track at Oredev this year - the first time this has happened at a conference. I'm going to be giving a presentation in that track, which I have also been given the honor of hosting. The other speakers are Randy Stafford, Dan Bergh Johnsson, Einar Landre and Eric Evans.

Of course there are more DDD people around, such as my factor10 colleague Aslam Khan from South Africa. I'm pretty sure he will be DDD-centric in his talks as well as in his workshop. Other DDD-centric presentations will be given by Patrik Löwendahl, Rickard Öberg and Claudio Perrone.

Swedish surnames

2008-10-24T00:00:00Z

A friend of mine here in Sweden told me a story about when he worked for a large telco here in Sweden and they sent him to one of their offices very far away to work for a few weeks. When he arrived, he was treated as a king and he couldn't understand why. But after a while he understood that they thought he was the son-son-son of the founder of the company Ericsson since his last name was just that. Here we wouldn't think like that since Ericsson is a VERY common surname here.

Another very common surname in Sweden is Nilsson, the second most common actually. Even so, more or less every week I hear somebody who thinks that one of my colleagues in factor10, Niclas Nilsson, is my brother. That's not the case. I just wanted to work with him because he is brilliant and very nice.
:-)

Something I'm not that used to though is what happened the other day when Niclas met an old student of mine. My old student asked Niclas if I'm Niclas father! Hey, I'm not even three years older than Niclas...

DDD anti-motivation

2008-10-24T00:00:00Z

OK, I've published a long list of very positive blog posts about DDD. Now I think it's time to balance that a little bit with some problems. Here's the first one:

New (to most developers)

Even though DDD in itself isn't at all new, it's new to those that haven't tried it before, of course. And if you work in a big team with no prior experience of DDD, then it's very risky using it for a new and time constrained project. There are ways of reducing the risk, but it's still there and it's real.

As a matter of fact, DDD is new to most tool vendors as well. Unfortunately that means that quite often the tools don't help us that much. Sometimes they are even more in the way than they are helpful.

Strategic Design (DDD Motivation 7)

2008-10-16T00:00:00Z

A single domain model and a single application typically aren't isolated things, without anything around them. You need to think about the big picture as well. Strategic design is about that.

Eric Evans has said that if he were to rewrite the book, he would put the chapters on Strategic Design at the front of the book and not at the end because nobody reads that far but that part of the book is perhaps the most important.

I know, this is no reason for you to try out an alternative to database-driven design because strategic design isn't the opposite at all, it's not at the same level. No matter if you go for db-driven design or domain models, I think strategic design is very important and therefore it felt important to mention it as a reason to have a closer look at DDD.

A new course on implementing DDD and LINQ

2008-10-16T00:00:00Z

My factor10-colleague Anders Janmyr and I have developed a new course on implementing DDD and LINQ. Anders will teach the course for Cornerstone in Gothenburg and Stockholm next week as well as in December. You can find more information about it here (in Swedish).

Have you heard about LINQ?

2008-09-22T00:00:00Z

I'm pretty sure you have, of course. The father of LINQ, Erik Meijer (Microsoft), will be giving a mini-event together with factor10 in Malmö on October 3rd. It's free of charge. Read more about it and register here (some of the information is in Swedish). First come, first served...
:-)

DP Advisory Council at Microsoft

2008-06-19T00:00:00Z

I've been invited by Microsoft's Data Programmability team to be a member of an Advisory Council for Data Programmability and Domain-Driven Design (DDD). I'm really looking forward to it, it's going to be interesting and a lot of fun. More information here.

And my book goes farther east!

2008-04-28T00:00:00Z

So cool!

Not only has my latest book, "Applying Domain-Driven Design and Patterns" been translated into Russian (more information here), but now I've been informed that the Japanese translation has been published as well. The Japanese version looks like this:

Track chair at Devsummit 2008

2008-03-27T00:00:00Z

One of the highlights of the year is approaching. I'm thinking about DevSummit in Stockholm in two weeks' time, where this year I have the honor of being track chair. My track is "Building for the Enterprise" (some of the page is in Swedish).

The theme I came up with was that when building for the enterprise it's not just the big things that matter, but also the "small", daily things. They both matter a lot, so there are presentations about the coarse grained things that you probably decide about only once in a project. For instance, how to apply enterprise scale middleware using the cloud as the middleware and, perhaps, applying a new paradigm, like composite-oriented programming. There are also presentations about more fine-grained things, the sort of things that you think about every day, such as developers' ethics, how every single code line matters and how to test.

Those speaking will be:

You're going to love it!
:-)

Dealing with complexity (DDD Motivation 6)

2008-03-27T00:00:00Z

The subtitle of Eric Evans's DDD book is "Tackling Complexity in the Heart of Software". So, dealing with complexity is at the very heart of DDD.

One way I see it is that we would like to work with essential complexity, avoiding accidental complexity. The accidental complexity will hurt us, probably by distracting us so it is not possible for us to take care of the essential complexity.

There will always be some accidental complexity around as well, but we should at least try to partition it out from the very core. For example, don't let the infrastructure mess up your domain model.

TDD-supporting (DDD Motivation 5)

2008-03-19T00:00:00Z

Quite a few have tried, and failed with, TDD. Pretty often I believe they have tried to use TDD for an old application structured with Transaction Scripts together with an Anemic Domain Model and quite often every test will touch the database. TDD just doesn't work well in such a situation before you have taken pretty big steps to make the whole situation more test-friendly.

On the other hand, if TDD is used together with an application that has been structured according to DDD, I find the combination is very strong and you don't have to fight to make it work. (Sure, it still requires a lot of work and attention over time, but it's much more harmonious.)

I have quite often been asked whether you should choose DDD or TDD? To me, that's obviously a question that I want to answer with "both". When I have a first sketch of my model, I try it out with TDD. It's like thinking about the model from DDD as a clay model, and the tests of TDD are like hands working the clay.

O/RM might potentially save manual code/time (DDD Motivation 4)

2008-03-14T00:00:00Z

It's a bit dangerous to declare that you will save a lot of time by using O/RM instead of writing manual data access code. There are situations when you won't, but when O/RM fits well, it can save a lot of time and free up resources that can be put on the core logic instead of the data access logic.

During work on a large application I made the following observation. When I needed to make a change regarding data access that only affected the code using the O/RM, it was done radically (almost a magnitude) faster than when I needed to make a similar change to code where manual data access code was used (because of optimization).

But before you see that potential save in code/time, you do of course have to pay a learning curve. Nothing new there. All new tools/techniques have a learning curve that will kill your productivity for a while, but hopefully you will come out and be more productive than when you started.

Do you prefer better or worse code over time? (DDD Motivation 3)

2008-03-07T00:00:00Z

Have you ever worked on a code base that gets worse and worse over time? I would guess all professional software developers have at some time, and I have for sure. At the same time, I think most of us value maintainability very highly, and maintainability is very dependent on good code.

Of course, one way of getting better code over time is to use refactoring, but another is to add knowledge to the code as you learn more about the model by applying those examples. All of a sudden you might see a breakthrough in your code, so it's not just about small incremental improvements; sometimes it can be pretty dramatic.

Eric Evans talks about how we shouldn't expect the first model to be the best, or even good. It might take several versions of the application until a really good model shows itself. For that to happen, you have to keep the code extremely nice and clean all the time.

I remember one specific application a few years ago where I saw something like this happen pretty clearly. We had built a new application and it was up and running in production, but there were numerous requirements for the next iteration that were hard to fit into the code without creating a mess. After a while we came up with an "activity" abstraction. I know, in hindsight it's almost silly to talk about it because it's so obvious now. Isn't it always like that afterwards?
:-)

Anyway, the abstraction couldn't be found in the domain, so it wasn't just a matter of listening to the domain experts and just building what they said (it never is of course). We invented the abstraction and, after much arguing, we and the domain experts decided that it would solve lots of problems in the current application as well as deal with the new requirements. The production manager was pretty skeptical at first, but six months later she told us that she not only couldn't but didn't want to work without the activities any longer.

When this happened, it made the code better, not worse, and in order for it to happen, we kept a tight focus on the code all the time.

Kind of the opposite of this would be the quite common situation where, early in the project, you can hear "we have to set the database design so we can start working". In my opinion, when there is a database focus that, that also means a pretty static view on the solution. That in turn means that new learning will quite often come as hacks in the code base and the code has already started on its way downhill...

Collaboration and feedback-focus (DDD Motivation 2)

2008-03-04T00:00:00Z

Even though most people agree that waterfall is not the most optimal process for software development, it's still very common to see specs being thrown over the fence from the domain experts to the business analysts, and the analysis documents over the fence to the designers and the design documents over the fence to the developers and the binaries over the fence to the testers and finally to the customers... Information is lost, feedback is at a minimum. All this leads to blame. (Interestingly, blame seems to go both ways over the fence.)

Instead of this blame-driven process, what I think we need is an approach where collaboration and feedback is at the very heart. In my experience this is a much, much better way of working. To me, DDD is very much about that, gathering the WHOLE team around the model and the ubiquitous language and the code. Collaboration and feedback. So powerful!

DDD Motivation

2008-03-03T00:00:00Z

Has Domain-Driven Design (DDD) reached its tipping point? It feels like it has. For example, these days we at factor10 get lots of requests about help with DDD, way more than just six months ago. And it seems to be a global trend because the requests are coming from everywhere.

On a recent DDD coaching project I was asked if I could motivate why I think it is more interesting to look at DDD style instead of a more DB-ish-driven design style (typically with Transaction Scripts and possibly with an anemic domain model or recordsets). I thought that was a great question and I'm going to write a series of blog posts about my answers to it. The first one comes here.

Focus on technology or semantics? (DDD Motivation 1)

2008-03-03T00:00:00Z

To me, this argument is in itself almost all that is needed. As technology people I think we are still, after all these years, a bit too quick with technical details, while at the same time the semantics and the business problem/solution isn't getting the focus it deserves. To me, DDD is very much about moving the focus to the most important place and the place that we typically focus too little on.

This is not to say that technology isn't important, of course it is important. Every software solution is comprised from both sides. It's just about where I would like to put more of the emphasis, for example to get a better maintainability story.

API Design, part I

2008-02-25T00:00:00Z

API Design might to some not be the coolest thing around, but if you ask me it's extremely important. A few months ago I was playing with it a little and came up with a list that is inspired by the Agile Manifesto:

API design manifesto

:-)

Code over comments
Immutability over mutability
Testability over encapsulation
Context over generality
Small and simple over completeness
Backward compatibility over revolution
Encapsulation over transparency

I know, I need to explain my thinking for each line above. I think I'll put it into a series of blog posts, but first I'd like to improve the list. A few weeks ago I discussed this topic with a couple of friends at a workshop and I got loads of ideas about how to improve it. Before starting the work I also wanted ask around here for even more input. If you have ideas, please email me: jimmy dot nilsson at factor10 dot com.

Value Safety

2008-02-16T00:00:00Z

While listening to my colleague Niclas Nilsson's presentation called "Dynamic Languages for Statically Typed Minds" last week at PBT Group in Cape Town it occurred to me that what Dynamic Languages lack in type safety, they gain in value safety.
:-)

Niclas showed that in static typed languages such as Java and C#, if you instantiate an int with 100000000 (one hundred millions) it's still an int. If you then multiply that int by itself and store it in the same int, it's still an int, but the value is 1874919424. Doesn't look right, does it?

If you do the same in Ruby, instantiate a member with 100_000_000, it's a FixNum. If you multiply that FixNum by itself, it becomes a BigNum. But the value is 10000000000000000 which seems to be more correct than in the Java/C# case. Type safety? No, but Value safety!

Code Litmus test

2008-02-04T00:00:00Z

A few weeks ago an email was going around about how you could diagnose a stroke without any medical training just by answering three simple questions and get the person to the doctor in time for treatment.

I spoke to my colleague Andreas Brink about using that idea in another context, a little less serious one such as code. He said immediately that only one question is needed and that would take people without much development experience a long way. That question is "Is there any duplication?" Lots of other problems boil down to that simple question. I'm sure we can get Andreas to expand on this further...
:-)

Another similar question I've often heard is "Is that testable?" (but that requires experience in test automation). Do you have another favorite?

Volta thoughts

2008-01-13T00:00:00Z

A month ago Microsoft released Volta, which is a technology preview, but to my surprise not very many reactions have been published. Sure, it's been the holiday season, but even so, and some of the comments weren't as positive as I had been expecting either. I quite often find that early comments to newly released stuff are overwhelmingly positive. However, when COmega was released a few years ago, it was also a bit quiet, and then a few years later some of the COmega pieces received very positive comments (such as LINQ). That said, here are a few comments about Volta I have written after a VERY quick look.

Several of the early comments were reactions to how making the network jump implicit again seems to be a step backwards after the recent trend of making it explicit. Sure, I also reacted to that, but as I see it, design never goes out of fashion. You should still make informed and conscious decisions about the design regarding network jumps. Volta gives you a very simple programming model for doing it.
The new idea (new to me at least) with Volta is the IL to IL-rewrite. An example that is shown is to use declarative annotations to a Volta WinForms application and thereby make it distributed and with asynch methods. This is just an example of the rewrite-technology. What's the next thing we'll find we need in this space? Very interesting!
Retargeting is also very interesting of course. The current example of that is to write code in C# and retarget it to JavaScript.
Volta promotes a focus on the core, a focus on the interesting stuff, the domain problem. The other stuff (infrastructure/plumbing) just distracts and shouldn't uglify our code. That's pretty much what I talk about all the time, but Volta's approach is pretty different from the route I normally take.

Singapore and South Africa

2008-01-07T00:00:00Z

January starts in a whirlwind with a trip to Singapore for a project and the day after I get back I'm off to South Africa for a workshop. I will also be giving two presentations in South Africa after the workshop; the first at a conference in Johannesburg which will be about LINQ+DDD and the second presentation is called "Is DDD more than Entities and Repositories?" and will take place at an event in Cape Town in collaboration with PBT Group. More information here.

Two problems collaborating

2008-01-06T00:00:00Z

I don't know how many times it has happened that I have a problem that has mystified me, only to realize after a while that there are two very simple, natural problems collaborating. Does that mean that three problems in collaboration would make it close to impossible to understand and solve?
:-)

Another change

2008-01-03T00:00:00Z

It's been pretty quiet here on my blog for a while for one simple reason. It's been an extremely hectic year! Some of the larger and more unusual things that happened were:

A new house

Not new as in brand new, but new as in another. Moving is really hard work (and we aren't actually done yet - the garage is still full for one thing), but it was definitely worth it!
A new bike

OK, not that big a thing, but a fun thing with an engine.
A new company

I have moved all my work efforts to factor10. We've had a fantastic 2007 and everything is pointing to it being an even better 2008!

But the title of this blog post was "another change". The next change for me is that I have given myself the gift of being more active on my blog for 2008. See you around and Happy New Year!
:-)

Oredev

2007-11-07T00:00:00Z

As I've said before, the conference arena in Sweden is very hot. Next week it's time for the third Oredev in Malmö and it just keeps on growing. I'm going to speak about "Applying LINQ" for DDD, so hope to see you there. I think it's going to be a great event!

Free Our CLR Objects

2007-11-07T00:00:00Z

My friend Kim Harding Christensen had a great idea because of IPOCO and all that. Perhaps it's time for a "Free Our CLR Objects" movement. Let's call it FOCO.
:-)

Pretty close, but far away

2007-10-21T00:00:00Z

LINQ to SQL seemed so promising... of course there were quite a lot of quirks here and there, but promising nonetheless. BUT, it lacks support for Value Objects. I don't even have a decent workaround, because it won't work decently with querying... However, it might be that something can be done with the expression tree to solve the problem, but...

To give a quick and simple example of what I mean, I find it common that I would like to have Customer and Address as two different classes, but as one table (Customers) in the database. Another simple example, assume that your Order has a Price object and the Price object has a Discount object. In the database, there is just an Orders table...

I was looking forward to a solution out of the box from MS, since I thought that would lead to a wide interest in DDD. To me, the problem with Value Objects is a show stopper, but it might not be that big of a problem for everyone.

The Entity Framework, you ask? Well, I don't know too much about it but it looks to be a giant thing. I'm a bit allergic to giant things, and they seem to be a long way from PI at this point. They have even invented something they call IPOCO which is miles away from PI in my opinion, more like anti-PI... So not even the stuff after Orcas seems to be what I need... Why?

Our society as a metaphor

2007-10-05T00:00:00Z

We all know that metaphors are hopelessly hard to get right. Perhaps you have heard that awful one about how developing software is just like building houses?
;-)

Even so, a metaphor can often be useful when explaining something particular in a certain context.

I came up with another (non-perfect) metaphor today, new for me at least. It occurred to me today that where I live, our society here in Sweden is pretty similar to building software (and it's no doubt exactly the same in lots of places). We try to get rid of as many repetitive, uninteresting tasks as possible, and we do it by automation instead of adding head count. For example we want to have lawn mower robots, vacuum cleaner robots, self cleaning windows, and so on. What we are left with are interesting tasks that we WANT to do on our own and/or that are best done by us, such as playing with the kids, eating and socializing. Oh, and taking care of the robots so they know what to do.
:D

Expo-C

2007-10-01T00:00:00Z

Once again, Anki and Magnus are arranging their very popular conference called Expo-C. A special thing with Expo-C is its focus on the learning experience.
:-)

In October Expo-C will be in both Växjö and Karlskrona. I'm giving a tutorial on TDD in Växjö and I will be moderating the seminar days at both locations. See you there!

Erlang, take 2

2007-08-29T00:00:00Z

For the last few years, Erlang has been receiving lots of positive comments and interest. One of the most recent examples of that was Ralph Johnson's great blog post the other day called "Erlang, the next Java".

I think it has been something like 15 years since I first "saw" Erlang when some of the creators gave a tutorial for the department at the local university where I worked. I still remember that I just didn't get it, blush... I guess I wasn't alone in that since even Ericsson, the company where Erlang was developed, decided to go another route after a while.

Anyway, that is history. It's probably not too late to try to get it now, is it?

Power balance?

2007-08-22T00:00:00Z

Who holds the power in today's IT world? The guys with the budget? The testers? The developers?

I would say that the operations department has lots of power in many big companies. The operations department sets the scene and it's relatively concrete and rarely changed... Introducing new things to the operations environment isn't done without lots of calendar time passing and lots of friction along the way. You, as a developer, must have very good reasons indeed to want to take on the task of trying to bring about a change in the operations environment.

I believe this situation, regarding where the power is nowadays, is a very strong reason for the potential success of JRuby (and IronRuby as well). I'm thinking about the possibilities that JRuby brings for the developers, without causing problems with the operations department. I mean that even if the operations department is strictly orthodox when it comes to introducing new runtimes in the operations environment, you can now write apps in Ruby and execute them on the plain old Java runtime (POJR?) that the operations department has probably already decided to support.

Persistence Ignorance important in the .NET-world now?

2007-08-20T00:00:00Z

The other day I was googling and, to my surprise, came across quite a lot about Persistence Ignorance. That "property" seems to have grown in importance and my guess is that LINQ to SQL is the driving force.

To develop the subject of this post, I think that before too long there will be lots of attempts with DDD in the .NET-world compared with how it is today. We'll see.

My book goes East!

2007-08-20T00:00:00Z

My latest book, "Applying Domain-Driven Design and Patterns" has been translated into Russian (more information here).

Sooo cool!
:-)

I just spoke to my publisher and the rights for a Japanese version have been sold as well, although it will be a while before it's available.

factor10

2007-08-19T00:00:00Z

I mentioned earlier this year that I have been working on a startup that is currently in stealth mode. We are slowly leaving that mode and have actually started several real world projects for real world customers, it's just that we haven't talked much about it in public.

The company is called factor10 and is a consulting company based in Sweden (Gothenburg, Ronneby and Malmo). The basic idea is that by hiring the best people we will be able to help customers in the best way.

You find the web here:
http://factor10.com

And the rss here:
http://factor10.com/rss.xml

What this means for me personally is that after almost 15 years in my one-man-company, I will now have colleagues at the same company. And not just any old colleagues - I'm going to be the stupidest one in the company, but I think that's very inspiring. Just to take an example, my colleagues have a long background in and lots of experience with dynamic languages (such as Python and Ruby) and functional languages (such as Haskell).

Another difference for me personally is that I will be more available for hands-on coaching projects, for instance. However, I'm very much of a doer, so that will still be my main thing.

Java is dead, long live Java

2007-08-16T00:00:00Z

Not too long after Java started to feel tired and worn out, well, as a commodity at least, JRuby has appeared and is making Java hot again. Not hot as a language, but hot as a platform.

It will be very interesting to keep tabs and see which virtual machine (VM) will be the favorite choice for Ruby two years from now. I've heard some criticism of the C-based VM, so perhaps the Java VM has a good chance, or maybe the CLR VM, when it arrives.

The law of friction

2007-07-10T00:00:00Z

At a fun lunch-time chat the other day, we collectively decided that the friction has to go somewhere in a project. Assume that for some reasons there is friction between the architects and the developers. That could be solved by letting the architects implement and the developers have a simple, open and direct channel for feedback, say. What happens? Perhaps the friction moves somewhere else, possibly between the new real team of developers and architects and the project managers. How should it be solved? Perhaps to really add the project managers to the team, so the friction moves between project managers and product owners. The solution? You guessed it. Now the friction is between customers and product owners... and you can probably find a solution to that as well...

OK, what happens now? We might have a very big team which means friction as well... So we decide to split it and we have some friction between the teams...

So, there seems to be no perfect solution.
:D

But perhaps we can make an educated decision about where we WANT to have the friction (or rather, where it hurts the least).

OOPSLA in Montreal

2007-07-02T00:00:00Z

I'm going to be giving the same tutorial as last year (slightly improved, of course) at OOPSLA in Montreal along with my factor10 colleague Niclas Nilsson. The tutorial is targeting both .NET- and Java-developers.

Ralph Johnson's mission

2007-07-01T00:00:00Z

I had the pleasure of meeting Ralph Johnson (one of the GoFers) a couple of weeks ago, which was, of course, extremely interesting. I found out that Ralph is on a mission to push a certain "concept". Guess which one? It makes a lot of sense...

Yep, you're right, it is DDD.

Ralph was very much in favor of DDD and wanted it to be much more prominent in the industry. He saw it as a major factor to improvements in our industry as a whole.

JAOO2007: LINQ for Domain-Driven Design (DDD)

2007-06-29T00:00:00Z

As I've said before, I believe LINQ will be an enabler for lots of .NET developers to become interested in Domain-Driven Design (DDD). Kim Harding Christensen and I will be giving a presentation at JAOO where we will show and discuss how we have applied LINQ in DDD-ish projects.

Experience reports on DDD

2007-06-29T00:00:00Z

The DDD-site has collected a couple of very interesting experience reports. You find them here.

Buy vs build

2007-06-29T00:00:00Z

The discussion regarding buy vs build for software is as old as software itself. Is it possible to find one answer? No, of course not, but having said that, lately I think that a push towards "buy" is quite common. Of course this is very good in some situations, but quite often I think "build" is to be preferred.

You probably don't want to be standard when it comes to the domain specific parts where you have your competitive edge. It's as simple as that. Another factor is that the business of software development has become much more efficient at building domain specific application (because of domain-focus, agile practices, experience, craftmanship...), while at the same time the standard packages have grown too colossal, often being harder to configure than to build what is needed. It's also the case that typically the standard package won't do exactly as you want, no matter how much you configure.

The time to market with good quality is much better today than before when it comes to "build". Dare to take the build decision!

The competence crisis, part 2

2007-06-14T00:00:00Z

(You find part 1 here.)

OK, so it's hard to find developers to hire. What should be done about it? As far as I'm concerned the obvious answer would be to think about how to boost the ones we already have. I see great advantages in that: you get more for less; the developers will be happier; you avoid the "adding head count trauma"; and if your problem really is to get more things done as opposed to increasing your numbers, this problem is solved.

Of course other companies will come and try to grab your developers seeing how they don't have the people either, so you will also have to become the best possible employer. That will increase your costs a bit, but it is nothing compared to the cost of bringing in loads of new developers and losing lots of old ones. When it comes to customers we usually say something along the lines of how it's much easier and cheaper to keep the old ones than get new ones. The same goes for employees.

Oh, and all of a sudden more people will understand that it's nice to be a developer, so that the competence crisis will lessen over time...

I guess I'm kicking in open doors again...
:-)

Post ADDDP

2007-06-14T00:00:00Z

It's now 13 months since my most recent book (Applying Domain-Driven Design and Patterns [ADDDP]) was released and I have (fortunately) learnt a few things.
:-)

Not that I regret what I wrote in the book, not at all! It will be contemporary for a good many years to come, if I may say so, subjective as I am. What I'm thinking about for instance is LINQ which fast approaching, and I believe it might be a signal to lots of Microsoft-developers wanting to go for DDD. I also see LINQ as a technique that solves what I solved with NWorkspace, but without you having to write your own abstraction.

That said, there are clearly things I didn't write much about that I'd like to get to grips with at some point. The first thing that springs to mind is that I don't think I devoted enough space to Value Objects [DDD] in ADDDP. I now believe that they are extremely important in order to understand the heart of DDD and something to explicitly work hard on.

With a rich flora of Value Objects in your model, DDD newcomers would not get the "the-domain-model-is-very-similar-to-the-relational-database-model"-feeling that is quite common. Starting to learn DDD with Value Objects is probably a good pedagogic trick.

The Value Objects are also very powerful in connecting with the Ubiquitous Language [DDD]. What's more, you can use them for creating a little internal DSL (or several, of course) in the ordinary programming language of your choice, without having to swap immediately.

The competence crisis

2007-06-04T00:00:00Z

In Sweden at least people are talking about a competence crisis, referring to the fact that almost nobody is studying IT at university these days and that companies are consequently having huge problems finding people to hire. How bad will it be in a couple of years?

When a discussion has been a bit one-sided for a while, there must be some grumpy old man who jumps in and says the opposite. I don't think I'm extremely grumpy and not all that old either, but I'd like to toss a few words into the debate.

Please note that I know there are problems in the lack of skilled people so I am not saying it's not a problem. OK, now that's out of the way, over to my arguments.

Nope, I don't see off-shoring as the solution to the whole problem. Sure, off-shoring could be an interesting alternative in some cases, but it's hardly going to be the mainstream solution when the hype is over. And if the project is easy to specify in details, why should humans have to transform that specification into code instead of using another approach? Letting developers and domain experts work together, in one and the same room, is extremely efficient and something you don't want to or should give away easily in many projects.
If we look back, we can find several instances of forecasted crises that never happened. One example that springs to mind is the story about the expected amount of horse droppings on the streets of London. Quite some time ago a researcher did some extrapolation and stated there would be an enormous problem a few decades later... then came the car and the problem never arose. (OK, there were other problems of course and you might wish for the horse problem instead, but that misses my point here.) Something might radically change the scene. What will that be? We'll see...
Brook's law is well known and often referred to ("Adding manpower to a late software project makes it later"). Even so, strangely enough it's tried every so often, but that's a story for another day. Instead, I wanted to take Brook's law one step further. I quite often "joke" about how late projects should move half of the developers to other projects so that the late project can deliver; and sometimes going down by 50% isn't a big enough percentage. Let a very small, but extremely skilled, team work in peace and collaboration. Get the best developers you can find. Quality over quantity. Even if they cost you twice as much as the average developer, that's cheap if they are three times more efficient. Simple and obvious, isn't it?

To sum up my attempt at an "opposite" opinion, perhaps it's even "correct" that only a few are studying to become system developers. At least if those who are are the most interested and suitable. Admit it, you weren't expecting me to say that!

Some highlights from Devsummit 2007

2007-06-04T00:00:00Z

Well that's Devsummit over for another year, and I think it was very nice, as always. I'd like to write a few words about what I thought some of the highlights were.

Andreas Brink spoke about how maintenance of legacy code is potentially actually more interesting, challenging and fun than developing new code. He also pointed out that to get use out of TDD, you must first be at a certain level for wanting to create nice, clean code (or at least it helps a lot if you are).

One of my colleagues at factor10, Niclas Nilsson, gave the keynote with the title "Dynamic Languages for Statically Typed Minds". There was one thing in his talk (OK, probably a lot of things, but this is the one I recall) that I hadn't before thought about at all. In Ruby it's easy to redefine the visibility of a method from private to public for testing purposes. This was just one small detail in his talk of course, but I started to think about how much pain I quite often go through regarding this in legacy code.

The unplanned, but common, theme of the architecture track day one was collaboration between different groups and that was definitely the theme of my talk as well. I hear about "us and them" in different projects all the time, but in my opinion a move to "all of us" is what we should be striving for. (No, I'm not saying that there should just be one huge über-project for dealing with every need or anything... but within a project, getting everyone to really collaborate, that's what I'm talking about.) But enough of open-door-kicking-in.

Chief Innovation Officer

2007-06-04T00:00:00Z

It's probably old news now, but I recently heard that CIOs are changing from Chief Information Officer to Chief Innovation Officer. I really like that. I have the feeling that quite a lot of CIOs are stuck with infrastructure problems and the like, and don't get much of a chance to focus on innovation. But there might be a new trend in sight.

I'm not alone in having "trouble" with ASP.NET

2007-05-30T00:00:00Z

Ah, sometimes it feels good not being alone in having a certain opinion. All in all, I just don't like ASP.NET! I struggle with it when I have to, I solve the tasks when I have to, but I don't really, really like it. It doesn't work in the way I want it to. I thought it was just me and my incompetence, but perhaps that's not the whole story...

My suspicions were aroused when I checked out Ruby on Rails last year and I liked it straight away. For example, Rails is made for testing from the ground up! Ah!

Recently others have also expressed their uncertainty towards ASP.NET. Perhaps it's not just my stupidity. Might there in fact be a problem?

Creating good example code is hard

2007-05-14T00:00:00Z

It's hard to come up with good example code in documentation, something I plead guilty to in my own writing. Another example, which I guess lots can identify with, is the documentation by Microsoft. When I search the documentation, it's usually the code examples I look at first, and, for some reason, the code examples most often miss the point...

The other day, a colleague sent me a code snippet from a piece of documentation he had written and it was just great! He didn't invent the example, but took it from real life code. Perhaps harvesting code samples is the thing to do, just like harvesting frameworks has proven to be a good idea rather than inventing them.

DevSummit 2007

2007-05-10T00:00:00Z

The conference landscape of Sweden was like a desert just a few years ago. Now, it's the opposite! All of a sudden, people are coming from all over the world to attend the Swedish conferences, instead of (or as a complement to) the other way around. One of the key players is DevSummit. So, one of the year's highlights for me is just around the corner, the DevSummit conference in Stockholm. See you there!

Catalysts for agility

2007-05-10T00:00:00Z

A wise friend recently pointed out a difference in perfectionism levels before and after kids. When you have kids, you're just happy if everything sort of works out at all. Getting close to perfection isn't a realistic goal any longer. So, perhaps kids are a good catalyst for becoming agile? To be able to focus on being good enough?

Clipper story

2007-04-18T00:00:00Z

Not that long ago I was driving to a meeting in a hurry, when the cell phone rang. The voice on the other end met the “stressed-Jimmy-who-isn't-very-fond-of-salesmen” asking if he was selling stuff, such as clippers. It didn't take long before I realized that this was one of the most embarrassing moments I'd had in a long time, since he wasn't selling, he wanted to buy. Not clippers, but mentoring.
:-)

Guess what I got from this patient customer at the first meeting? Mmm...
:-)

Linq is love?

2007-04-17T00:00:00Z

Is it time to focus on Linq? I was planning to do so, but I kind of stumbled a bit, especially when I hit the Entity Framework... Is it just me, or doesn't it seem as if the whole area is a bit messy at the moment?

Charles in space

2007-04-17T00:00:00Z

Here in Sweden, Christer Fuglesang recently gained lots of publicity for being the first Swedish guy in space. Right now Charles Simonyi is getting almost as much publicity over here for becoming the fifth space tourist.

I love it that young people have some other people to hear about instead of just the participants in Big Brother and other such reality soaps. People to look up to who say that science is fun and important, people who say that learning is fun and important. (That's not exactly the message coming from the average reality soap, right?)

Perhaps I find this important because I have kids myself who I'd like to get into the idea of eternal learning. Or perhaps I simply believe that learning is a VERY important part of our jobs as software developers. Anyway, thanks Christer and Charles for emphasising the fact! Who's going to be next?

Level of abstraction

2007-04-16T00:00:00Z

Quite often I hear/read/learn something that I didn't come up with myself, but is so painfully obvious the moment I get it. One such moment occurred last summer when a friend said that it's not about increasing the abstraction level, it's about getting the right abstraction level.

And I think that to a large extent that points us to the DSL movement, right?

SNUG

2007-04-10T00:00:00Z

On April 12th, I'm going to be speaking at SNUG (Skansk .NET User Group) in Malmö. It's not going to be .NETish at all, so if you mostly work with Ruby or Java or any other platform, please also stop by. I will also be hosting an Open Space session or two. More information here.

InfoQ interview

2007-02-25T00:00:00Z

The interview I did with Floyd Marinescu at JAOO is now up at the infoQ site.

Expo-C at Ullevi

2007-02-25T00:00:00Z

Anki and Magnus are at it again, running a new instance of the Expo-C conference, this time at Ullevi in Gothenburg. Here's the text from the front page of the web site:

Software Legends at Ullevi!

Many legends have performed at Ullevi in Gothenburg - Bono, Madonna, Mick Jagger and Bruce Springsteen, to name a few.

Now it's time for two more legends to enter the scene...

Their music may not sound as good, but their lyrics are the better!

Ralph Johnson and James O. Coplien will perform at Ullevi Conference Centre April 23-25! Yep! Can you possibly miss that?

And their companions are as brilliant: Dan North, Niclas Nilsson, Rickard Öberg and Jimmy Nilsson.

See you at Ullevi!

For more information, visit the Expo-C Gothenburg web site.

Reviewing WWW'2007 Papers

2007-02-20T00:00:00Z

First published here: http://www.iw3c2.org/blog/2007/02/20/reviewing-www2007-papers/

Even though I have a background from academia, I haven't read too many research papers and especially not recently. That's one reason why it was especially fun to be on the program committee for papers to WWW'2007. I read eight papers and learned a lot about new and interesting ideas. Afterwards I heard that only one of the papers I read was accepted. I was positive to most of my eight, but the level was obviously very high and only my very favorite made it. It's called "Introduction and Evaluation of Martlet, a Scientific Workflow Language for Abstracted Parallelisation" by Daniel Goodman.

Properties vs. fields - refreshing take from Microsofties

2007-02-20T00:00:00Z

My preference for public fields instead of public properties with no behavior (depending upon the context of course), has quite often led to my being "flamed" (well, a bit). I saw that Eric Gunnerson and Jay Bazuzi blogged about it so now it's not even a valid argument to say "because Microsoft says so!!!".
;-)

How to increase the temperature at a business village?

2007-02-20T00:00:00Z

The local business village is called Soft Center. I've been around here for the last 20 years, in fact, ever since it started. In the beginning, only IT companies were allowed, but nowadays it's totally different; only a few of the companies are in IT. Sure, some of them are very interesting from an IT perspective (such as UiQ), but there are still not that many. What's more, in two years' time the university is moving to another town, for reasons of consolidation. Is this the death of the business village? Well, I think not.

You can't just sit there and wait for someone to do something. You have to try something on your own, of course... as tiny as it may be, it's a start at least. And if everybody does the same thing, i.e. try something out, the problem is more or less solved.
:-)

We (I and two friends) started to host informal lunch events, which was an extremely simple thing to do, and at the first meeting we not only had a good time, we also started collaborating on a few projects! This was mind blowing, in my opinion.

Now we have an rss feed where we announce small get-togethers, such as the next pub visit (which is tomorrow by the way). And our next step? We'll see. Ideas are very welcome of course!

Reclaiming BDD

2007-02-18T00:00:00Z

One year ago I learned about Behaviour-Driven Development (BDD) from Dan North. I really liked the concept and tried it out on a real world project, with what I thought were very pleasing results. I thought I had a decent understanding of the concept.

So far, so good. Then something happened. I started hearing about BDD in another context, and that other context seemed to be the only one... all of a sudden, I wasn't sure I had understood it at all.

Let's take a step back. What are these different types of BDD that I'm talking about? One is about creating a tiny, formal, executable language for describing requirements and acceptance tests at a high level. A language to unite business people, testers and developers. A language for describing a situation, describing what's happening and describing the result. Let's call this high level BDD.

The other type of BDD is to do with changing the wording of ordinary TDD. Instead of tests, we should talk about specifications of behavior. Tests should be named with "Should" as a prefix. Let's call this low level BDD.

I think I have been doing the low level BDD for years and still calling it TDD (OK, my prefix has been "Can", but...), so not much new to me there. And if there is something new, I think it's easy to grasp in a few minutes. On the other hand, the high level BDD is different. It's not something I've done before, at least not as formalized, and not as a tool for bringing business people, testers and developers together. To me, it's high level BDD that should be pushed (and pushed hard), not low level BDD, which seems to be the pushers' current choice.

Can I hope for the return of BDD? The high level one?

I've been tagged

2007-01-10T00:00:00Z

Ah, Frans Bouma forced me to get back to blogging after the holidays by tagging me. So I'm now supposed to say five things about me that people probably don't know and then tag five other people.

I chose the program I chose at the high school pretty much because I expected to meet a lot of girls... Mature, eh? :-) I had a hard time understanding programming in the two hours that were spent on that subject during high school. The teacher wasn't much better either. In one lecture he wondered who had cut a hole in the cover of the floppy disk that was used in the multi-user storage system. Yep, you guessed it, that was the "hole" the read/write head used...
I'm not all that fond of traveling, unless I can take my family with me. Having said that, coming up is the highlight of the year work-wise with a trip to Arosa in Switzerland, where I'll be attending a workshop next week.
I like to cook. I'm not very good, but I like it. I have tried to eat stone age food for three years now. Not strictly at all, but just an ambition.
Even though we have both an Xbox and an Xbox 360, I more or less haven't played since Wolfenstein. I prefer outdoor activities in my spare time like jogging in the forest, skiing, skating, boating, and so on. Oh, and last week I went horse back riding for the first time in 30 years.
I'm currently working on a startup that for the moment is in stealth mode. More soon...

I tag Niclas Nilsson, Eric Evans, Dan Byström, Gregor Hohpe and Rickard Öberg.

Domain-Driven Design Quickly

2006-12-18T00:00:00Z

A new DDD book has seen the light of day. It's a mini-book called Domain-Driven Design Quickly which can be found at InfoQ - a new site with daily news and other material (videos, articles) for architects and developers. This mini-book (which is free to download) is a great way of quickly finding out about this very important area.

Post-agile

2006-12-10T00:00:00Z

In one way, the agile movement hasn't even got off the ground in many organizations, but at the same time every vendor and consulting company are now sooo agile. I find that a bit shocking especially considering what they said and sold six months ago.

:-)

Well, it's probably more Agile with a capital A they are claiming to sell. Anyway...

I know, I'm overreacting, but perhaps it's time to look a bit further to after the worst of the hype has faded away and the hangover has come and gone? What has/will come after agile? What is post-agile to you? I was sketching a little bit about Lagom Process the other day, but today I'd like to give you a couple of more concrete examples of what I consider to be post-agile:

Domain-Driven Design (DDD)

Lots of people will claim that DDD is quite old and pre-agile. Others will say it fits well with agile. Others still will say that it's interesting whether it's pre or post, of course (and I totally agree). Anyway, I see it as being a bit like post-agile, for example with its focus on the language of the project. It is a crisp, ubiquitous language to gather the team around, and in my opinion extremely important in increasing understanding. And little-used in reality.

Ruby/Rails

Ruby represents an agile language and to me that definitely feels like something of a new era after the agile principles and practices that we are most used to today. And functional languages fit in here as well.

Rails is also something earth-shattering, I would say. What makes it post? The first thing that springs to mind is the strange thing about a RAD tool that "provides" a good chance of leaving a decent architecture as the result. And a RAD tool that is designed for testing and TDD from the beginning...

Behavior-Driven Development (BDD)

Again, focusing on the language is so important and BDD does exactly that. On top of setting a common language, I see the "promise" of an executable specification as being the best thing since sliced bread. (One of these days I'll find out what's so good about sliced bread...)

Domain-Specific Language (DSL)

A very wise guy recently told me that the historic improvements in our industry haven't been due to raising the abstraction level. The thing is to find the right abstraction level, not necessarily a high one. That's the improvement. DSLs are just about that. Again, Ruby comes in as an important player, but also...

...Intentional

The stuff that the intentional guys are doing is definitely for a new era. Again, the language is at the very center, but the language focus and the focus on the representations is now on steroids. The effect of the shift might be fundamental for many domains. We'll see.

So, what was the common theme here? Focus on the domain? Focus on the right abstractions? Focus on the languages for describing your chosen abstractions? Focus on communication and understanding? Something like that I guess.

So, what is post-agile to you?

TDD course, seats left

2006-12-03T00:00:00Z

Please excuse me for some marketing, but I just wanted to mention that there are still a few seats left at my TDD course at Soft Center in Ronneby, December 11-12. Interested?

My mouse is famous

2006-11-24T00:00:00Z

I forgot to pick up my mouse after a recent conference presentation. Someone told me later that he had recognized my mouse and handed it in at reception. Nope, there's nothing special about the mouse so I don't know how he could have recognized it. It's just ordinary, grey and boring. Anyway, when I went to reception and asked for the mouse, people asked me if I was Jimmy. If so, they had heard about the mouse... totally surreal, but at the same time also hilarious!

:-)

For the worried reader I can tell you that my mouse is safely back in my care.

What pattern are you?

2006-11-23T00:00:00Z

A few minutes before giving my pattern presentation at Øredev I think I came up with a good question for when it comes to hiring developers. "What design pattern do you see yourself as and why?" I told the audience that the day before I had felt like a Proxy since I was a stand-in for a speaker that couldn't come, but most of the time I normally feel like a Null Object. What about you?

A book about ducks?

2006-11-23T00:00:00Z

My friend Magnus took the photo for the cover of my last book. What people keep telling me about the book is that "at least it looks good".

:-)

Anyway, Magnus told me the other day that he had taken a new photo. It was a photo of a duck. He went on to tell me that I had to write a book to go with that photo as well...

What do you think it should be about? It's obvious, isn't it?

Oh, and just to make it very clear, of course I'm just joking. I am not working on a new book.

LINQ as a better NWorkspace

2006-11-12T00:00:00Z

I quite often receive enquiries about when I'm going to publish NWorkspace, but I'm still hesitant to do so as it's definitely not of publishable quality. Yet it occurred to me that to a great extent LINQ is largely what the vision of the querying part of NWorkspace was all about. Of course LINQ is way, way better and way more complete. But again, the vision and the basic idea...

:-)

Expo-C 2006, autumn edition

2006-11-12T00:00:00Z

Due to the popularity of the first two Expo-Cs in Karlskrona, Anki and Magnus are setting up another one for this autumn. By popular demand, the focus of this conference is testing. The autumn edition features more local presentations than the spring edition did, with most of the presentations in Swedish. You'll find more information here:

www.expo-c.se

Oh, and I've just seen that they have published some photos from the spring edition.

Øredev approaching

2006-11-03T00:00:00Z

I just heard from the organizers of Øredev that they already have more attendees than last year, yet the most hectic weeks for registration of attendees are still to come.

The reason they contacted me was to let me know that my DDD-workshop was fully booked (32 spots). Great! At the time, only my workshop and Martin Fowler's were fully booked. I can live with losing to Martin...

;-)

OOPSLA 2006, follow up

2006-11-03T00:00:00Z

I'm just back from Portland and OOPSLA 2006, where I had a very good time. Here are a few comments:

It was (as always) great fun to work with Niclas. We had a hands-on tutorial about TDD and the participants chose between Java and .NET.

This was the first conference where I used my Mac laptop and I'm starting to grow very fond of it. I was told I would become popular if I had a Mac so I basically had no other choice but to go out and buy one...

;-)

Maybe I have become anti-new stuff, I don't know, but the best presentations/tutorials/demonstrations I saw were given by old friends about somewhat familiar (although still VERY new) topics:

Charles Simonyi on their Intentional Programming.
Eric Evans' DDD-tutorial with the sub-heading "Putting the Model to Work". I especially liked the part about focusing more energy on the Value Objects as opposed to what is common.
Erik Meijer demonstrating LINQ with his extreme energy level.

Oh, and as always the best part was meeting old and new friends, but enough namedropping for today.

:-)

MS and dynamic languages

2006-11-03T00:00:00Z

At the risk of being like a gossip magazine, I'd like to share a few thoughts about Microsoft and dynamic languages.

Erik Meijer has been pushing VB9 as a great dynamic language for quite some time.
Microsoft released IronPython a few weeks ago. There's been hardly any commotion about it, not even from MS itself. I'm very surprised about this since I consider it to be one of the most interesting releases from them for quite some time. Or is it that I'm just not listening hard enough?
Microsoft has recently hired John Lam and is up to something in (or close to) the Ruby-arena, I guess. (I have other reasons to believe this as well, but let's not get into that right now.)
Oh, BTW, Sun recently hired the JRuby-guys...

Does all this imply that dynamic languages and/or Ruby will be mainstream "soon" or what? Time will tell.

OreDev 2006

2006-10-12T00:00:00Z

I think ØreDev 2006 in Malmö is going to be even more fun than it was last year! I'm going to be giving a presentation about solving common problems with patterns and a hands-on tutorial on how to apply domain-driven design. See you there!

One of the pains of learning new stuff

2006-10-12T00:00:00Z

An important part of our work is to learn new stuff all the time. That's why we are pretty much used to the pain, like waiting for the ketchup effect, before we really get it.

But in the last year or so I have been reminded of another pain, that of not wanting to go back. I have been playing with and learning about, for instance, Ruby, Rails and Haskell and when I then step back to C# 1.1 and 2.0, it's not as much fun as it used to be. There is so much stuff to write that I don't think I should have to... Sure, C# 3 will become pretty Haskell-ish, but that misses my point here.

I've seen the light! I only want to work with the "new" stuff, NOW!

Don't get me wrong, of course I'm not leaving my old customers and projects behind, but one may wish to be able to spend more time with "new" stuff. That must be allowed, surely?

:-)

The coolest thing this summer

2006-10-05T00:00:00Z

Even though the Swedish weather has been awesome this year, it's not the coolest thing I remember from the summer. The coolest (and nicest) thing was when Charles Simonyi passed by my corner of Sweden with his yacht SKAT and took the helicopter over to my place to visit. After talking geek for a few hours, my wife and I had the wonderful pleasure of flying back with Charles in the helicopter to SKAT and visit his amazing yacht!

I don't remember the last time I had such a hard time coming up with anything to say, anything at all! SKAT was so way beyond any boat/ship I've ever seen before! The same thing happened to my camera - hardly any photos at all. Here's one exception. The photo shows my wife and Charles on board SKAT:

Tools or experience?

2006-10-04T00:00:00Z

It's time for one of my favorite subjects, one that I have written about quite often in the past, for example in Tools and teeth and Tools and skills. I ended Tools and skills with this:

A vendor once told me that any beginner would beat any old fox if they used their tool... No way! As soon as there is the slightest problem... You get the picture.

:-)

I haven't changed my mind, on the contrary. HOWEVER, I think it's very important to add that if you can combine tools and experience, it's extremely efficient, productive and just plain good. By combining I mean having lots and lots of experience AND a great tool that isn't in the way, but that just supports and makes use of the experience very productively.

.NET Rocks!

2006-08-29T00:00:00Z

The other day I had the pleasure of talking to Carl Franklin and Richard Campbell on .NET Rocks. Among other things we talked about domain-driven design and test-driven development. The recording of the the show is posted here: www.dotnetrocks.com/default.aspx?showID=194

OOPSLA 2006 and Slideware

2006-08-24T00:00:00Z

Phew, the documentation is all done and sent off now... This weekend has been tough. I'm going to OOPSLA in Portland in October where I will be giving a tutorial with Niclas Nilsson on TDD. The audience will find it very code intensive and they will choose Java or C# for the labs.

BTW, this is the first time I have written the slides in the tool Niclas and Jon-Erling Dahl call Slideware (which is a new version of an old tool by Niclas). The slides are created with a DSL and then the different pieces (bullets, code, pictures, etc) are put together with code generation. This is great, especially as far as code is concerned. The chosen pieces of code are picked up from the different projects, unit tested and in good shape. No more copy and paste, and maintaining in place... (Their plan is to release the tool this autumn. I'll mention it when that happens.)

Chinese webcast

2006-08-23T00:00:00Z

A Chinese translation of my latest book ADDDP will soon be published and I have been asked to take part in a webcast the 30th of August. I expect this to be very interesting for me! Here's the announcement (in Chinese):

www.umlchina.com/Chat/jimmynews.htm

A softy?

2006-08-23T00:00:00Z

I don't know what it is, age perhaps? Anyway, when it comes to software development I can see that I'm slowly moving towards thinking more about people-related things than tech things. I've seen it happen for so many more before, but for some reason I didn't expect it to happen for me too. Of course it's not that I'm not interested in tech, it's just that people things seem to be getting even more important and interesting...

Too sociable?

2006-08-09T00:00:00Z

The other day I talked to an old friend of mine who I haven't talked to for 16 years. After chatting for five minutes, I learned something about myself.

I like working alone in my office from time to time. I know, it's not in line with the Agile dogma (which I think very highly of, by the way), but that's just the way it is. I have put this down to the tendency I have of behaving like a hermit or else that I have the normal social skills of a typical developer. But I now understand that I like working alone from time to time because I am too sociable. When I'm around people, my productivity drops since I just talk to everyone all the time (not that this isn't productive in itself, especially in the long run, but you know what I mean...).

Of course, that must be it, it all makes sense. Everything's coming together. I am too sociable.

;-)

More about Lagom Process

2006-06-25T00:00:00Z

I have just seen that Magnus Christerson and Charles Simonyi of Intentional Software seem to like Lagom Process. At least they mention it in their recent blog post called "A Process With the Right Degrees of Freedom - the Lagom Process?".

Wow!

Collaborating with Eric Evans

2006-06-25T00:00:00Z

Ah, what a dream project! Eric Evans has invited me to collaborate on the DDD-site (domaindrivendesign.org), trying to create an even stronger DDD-community. That will be extremely interesting, of course, not just because I'm very interested in the topic, but what is even better is I know I will learn so much from Eric!

I'll get back with more information about the project soon.

Lagom Process

2006-05-21T00:00:00Z

It is sometimes heard that Extreme Programming (XP) is too extreme or, rather, too rigid... Some people have understood the message as being: "If you aren't doing it all, you're stupid."

What might be another problem with the perception of the name of XP is that I think that the extreme is often extremely expensive. It often happens that there is a pretty low return on investment on the last few percent (ouch, now when I talk about ROI people will think I'm heading for a career in management - not!).

I do like XP, but I actually don't see it as anything very extreme... it's pretty much common sense. Anyway, I thought that perhaps a better name might be in order. After all, names are extremely, hmm, important. At the workshop in Cortina earlier this year I tried out a new name. What do you think about 'Lagom Programming'? Lagom is a Swedish word for balance, not too much and not too little, just right, harmony. It's often said that this word only exists in Swedish, but I don't know that for sure.

In fact, lagom is also considered pretty boring by a lot of people in Sweden. Saying that, it was catchy enough for Charles Simonyi to remember the term and repeat it a few hours later at the workshop.

:-)

As I write, I'm at Expo-C and I'm hearing interesting stuff from interesting guys, some of it closely related to 'lagom'. Here are a few examples:

Dan North: "I play my 'enough' card." And "Somewhere in between is probably very good..."
Erik Meijer: "The answer is often somewhere in the middle."
Michael Stal: "Simple, but not too simple."

I guess the start of this post was a bit too focused on XP. What I should probably talk about is something like the Lagom Process (tm). It's probably influenced by Agile, but it's built up of the pieces that together form a mix that is lagom for the team and project at hand. That's it.

Infrastructure and EDM (updated)

2006-05-12T00:00:00Z

Several years ago I was criticized for being too wary of exposing certain data access libs/versions from MS. I haven't changed my mind, quite the opposite. (I wouldn't be surprised if you can spontaneously mention seven different libs without thinking about different versions - assuming you work with MS tech...) The core of my applications/services of the last few years is oblivious to the data access libs. The infrastructure shouldn't affect or be found in the core at all!

Today I came across this blog post by Andres Aguiar:

The news are out - ADO.NET 3.0 Entity Framework

If anything it just makes me even more certain about how to deal with infrastructure. For the next framework version it seems as if we will have (at least?) the following to choose from when accessing data in a relational database:

Dlinq
EDM
And I guess the old DataSet stuff also

I can't say I'm against having several choices, but do we really need all those choices from a single vendor? Are they that different?

Though I'm not sure if we will see both Dlinq and EDM because Dlinq isn't mentioned at all here:

ADO.NET Tech Preview: Overview

On the other hand, EDM was totally new for me (whatever that means).

Is it just me or has this whole area been a bit messy within MS? I'm thinking about, for example, ObjectSpaces (a few incarnations), MBF, WinFS, the above... What will happen next? Stay tuned!

:-)

Update

OK, only two hours after my blog post went live, the second link above stopped working. The same goes for the picture and the links in Andres' blog post to the blog posts of the ADO.NET team. And the movie at Channel 9 about EDM is also gone. I'm sure we will soon know why.

Finally...

2006-05-11T00:00:00Z

Yesterday the Swedish Customs called me since I had some boxes coming in. It reminded me of the time when the shipment of my last book arrived, just a few days before Christmas 2001. Customs also called me then and said they had some strange packages for me that they had opened. The packages contained 20 books, each and every one being the same! Even stranger, each book had my name on them... very suspicious. I'm still puzzled about what they found suspicious with that, but it was strange enough for them to hold on to the books for a few days.

Anyway, today three boxes arrived which had not been opened. The boxes contained...

...my new book! Applying Domain-Driven Design and Patterns [ADDDP]. At last!!!

To tell you the truth, one box was missing so I guess the fourth box is being carefully investigated right now. Or perhaps there was just a bunch of geeky customs guys who wanted to take a peek, who knows. No, I don't have anything against customs officials. Especially not on a day like this.

Expo-C update

2006-05-11T00:00:00Z

There is a lot of buzz about LINQ right now, but I have to admit I haven't been following it as closely as I would normally have done, it being such key technology for the future. And what is the reason for this? Well, I will be hanging out with Erik Meijer in person next week and what could be better than hearing about something from the horse's mouth? To quote one of the attendees: "How the hell did you get Erik to come? And he's staying for more than a day? A whole week? How the..." Well, you get the picture...

As for the speakers for Expo-C, they aren't just smart, they are nice too! I mean, just take a look at what Dan North wrote about me (erm, huge blush) at the Expo-C blog, without being threatened that much at all!

Dan North:

Whenever I'm around acclaimed author and software practitioner Jimmy Nilsson, I find myself exposed to new ideas. Software ideas, architecture ideas, design ideas, process ideas. And not just from Jimmy. To paraphrase Terry Pratchett, he seems to be a cause of ideas in other people.

Jimmy has earned himself the nickname "the Aggregator". He manages to bring people together and provoke interesting discussions. I spent a few days with Jimmy at the Software Architecture Workshop in Cortina recently. The SAW started life as a gathering of like-minded individuals in Crested Butte in the US. Jimmy decided to import the idea into Europe and he set up the first two European SAWs before handing on the baton this year.

I am very much looking forward to seeing Jimmy again in Sweden in a few weeks. No doubt he will be busy aggregating - as well as contributing to - some interesting discussions.

How nice can a guy be?

However, I have to admit that I'm a bit worried about the number of pubs in Karlskrona for this geek fest. Hey, it's a tiny town! On the other hand, as long as there is at least one (and of course there are several), I'm sure we will have a great time after the conference days as well!

If you have only just realized that you simply can't miss this event, I think there are still some seats available... Check with Anki and Magnus. C U next week!

:-)

SOA-Q: Where are the semantics?

2006-04-27T00:00:00Z

When I started my little series of posts called "SOA-Q" I wrote up a whole bunch of them, but so far I have only posted five (see below)... I kind of lost interest when I didn't get very many comments on the last one called SOA-Q: SOA the opposite to DDD?. Everyone who did comment asked if I had got any comments and said that they thought it was a strange question and that of course SOA and DDD are not opposites. As you can probably guess, I also think it's a strange question, which is the reason I posted it in the first place.

:-)

Not directly related, but a fun thing about anti-DDDers is that I've been talking to two such guys quite recently. Both discussions ended in them saying that they hadn't read the book and actually didn't know much about it... OK. I'm not saying that DDD is the silver bullet either, of course not, but is it interesting? I definitely think so. Even for SOA-guys!

Anyway, this morning I got a renewed spurt of energy thanks to Udi Dahan's good blog post Wither Service Discoverability so I dusted off the series and one of the old posts waiting to be aired. Here is the SOA-Q post for today:

SOA-Q: Where are the semantics?

Is it just me or has the focus by many SOA-evangelists so far not been on semantics, but rather more on technicalities? And, for example, the contracts that are possible to be expressed are pretty - hmmm - thin, aren't they? What haven't I read that I should?

Comments?

Previously posted in the same series:

Scott has had enough

2006-04-25T00:00:00Z

Scott Bellware is upset. Why? You might ask. Read about it here:

Mort or Elvis? A Question for a Bygone Era

No matter what your opinion on the subject is, the post is a must read!

Niclas and CSAML

2006-04-25T00:00:00Z

I talked about executable XML in this blog post called More language focus a few weeks ago. Niclas Nilsson pointed me in the direction of this great blog post by Charles Petzold yesterday:

C# Application Markup Language (CSAML): An Evolutionary Leap

Oh, and while you're at it, you should definitely subscribe to Niclas' blog of course!

Update

Sorry, I should have made it clear that I was aware of that Charles joked. Sometimes blog posts don't have high enough bandwidth, especially not for irony.

:-)

Jimmy 2.0 (or rather 0.2)

2006-04-20T00:00:00Z

OK, I'm sure you are as tired as I am of all the 2.0 stuff. But now that my new book (ADDDP) is done and after I've paid some extra attention to my customers for a while, I expect to find some time for pet projects again. One of these will be catching up on different general languages (I have other plans as well of course, but I'll return to these later).

I have started to play a bit with Ruby (as does pretty much everyone nowadays, I guess). I'm very keen on it so far.

I have also started to read up a little on Haskell. I'll be attending Erik Meijer's tutorial about Haskell and LINQ in Karlskrona in a few weeks and I have to prepare myself a bit, of course. I guess Haskell will become far more widely known now that LINQ is getting mainstream.

I also hope to get started on Lisp...

Will this turn me into 2.0? Nah... I haven't left the alpha stage yet so that would be too big a leap to hope for. Perhaps I can get to Jimmy 0.2 some time in the future...?

To increase the chances of that happening, here's a plea to the universities in Sweden. Do any of you have distance courses in Haskell, Ruby and Lisp? Oh, and perhaps Python also? I bet I'm not the only one wanting to improve my language knowledge these days. (I understand that these might not be the most interesting courses for the universities to run, but I'm sure a lot of good would come out of them.)

What about April?

2006-04-19T00:00:00Z

Ah, Gregor Hohpe wrote yet another great blog post the other day, called "March is Not a Number". As a service to my readers, I feel that I just have to point you in that direction if anyone of you happen to not have seen it yet. Happy reading!

:-)

Guest authors [ADDDP]

2006-04-18T00:00:00Z

Ah, I just sent the last piece of work to the publishers after having finished the final review of the book... Phew... Finally!

:-)

I told you before that I am very proud of the forewords written by Martin Fowler and Eric Evans. I'm also extremely proud of all the great pieces that my friends have written as guest authors for the book. They deserve sooo much gratitude for their contributions, and I know it's not much, but I'd like to start by giving them some link love. Here goes, in alphabetical order and with the names of their pieces:

Frans Bouma: The Database Model Is the Domain Model
Dan Byström: A Prepilogue (focus on the UI)
Udi Dahan: An Introduction to SOA
Erik Dörnenburg: Inversion of Control and Dependency Injection
Mats Helander: Mapping and Wrapping and Object-Oriented Data Model, Smart Service Layer, and Documents
Ingemar Lundberg: Test-Driving a Web Form and Pragmatism and the Nontraditional Approach
Philip Nelson: Database Testing
Claudio Perrone: Continuous Integration and Mocks and Stubs
Aleksandar Seovic: Aspect-Oriented Programming (AOP)
Christoffer Skjoldborg: The Model-View-Controller Pattern

Thanks guys!

SOA-Q: SOA the opposite to DDD?

2006-04-13T00:00:00Z

From time to time I have heard that Domain-Driven Design (DDD) is seen as the opposite to SOA by SOA-ers. For example I wonder if those SOA-ers have read the whole DDD book, including the part called "Strategic Design"? As I see it, there is lot of useful ideas there for SOA as well, or what am I missing?

Comments?

Dual schema

2006-04-07T00:00:00Z

Harry Pierson blogged about The Dual Schema Problem the other day as being a big problem when developing apps. Dual as in one "schema" for the domain model (at least that's how I read his post) and one schema for the database.

I agree, it's troublesome, and is a problem that I think is worth trying to do something about. Here are some reflections.

Nowadays I most often try to focus on the domain model (schema) when I'm developing. I regenerate the database schema for the relational database automatically from what the domain model looks like. This is nothing fancy and is probably the norm for lots of projects. Then I optimize what has to be optimized, but I don't start the other way around. Again, this won't be suitable for every project...
Harry talks about letting go of the relational database, and seeing the domain model as the database with an open source project called Consus. Another such project that I think has been talked about quite a lot is Prevayler. However, according to Harry, a big difference is that for Consus, tables are built in runtime. With Prevayler, what is stored in the log is the commands.
Oh, and my pet project NWorkspace is pretty much about avoiding that dual schema problem, at least during early development. You can start building the whole thing without a relational database, persisting an image of your domain model instantiation so that the user can try out your app without a database. No need to synch with a database schema at all. Later on in the project, you instantiate another NWorkspace-implementation, letting it talk with the database instead. Again, nothing fancy, but an attempt to reduce the problem Harry is talking about.

Before the flames start, let me just point out that I don't see the above as a way of abstracting away the database. I think it's extremely important to know about databases and be prepared to deal with them more on the low level when really needed.

Refactoring Databases

2006-04-05T00:00:00Z

The book Refactoring Databases by Scott W. Ambler and Pramod J. Sadalage arrived on my desk the other day.

Names of refactorings have proved to be an important part of our language as developers, in the same way as patterns have, for example. Our language has now grown!

I haven't read the book yet, but I expect it's going to be a must read!

Lending a hand with Expo-C 2006

2006-04-02T00:00:00Z

My friends Anki Nilsson and Magnus von Schenck will be running Expo-C in Karlskrona (Sweden) again this year since it exceeded all their expectations last year. They have asked me to help out as well with the content, some moderating and starting up the OpenSpace activity on one of the evenings. (Read: I will just hang out and have a good time. It's a dirty job, but someone's gotta do it.)

Since it's a small conference, maxing out at 120 attendees (by choice and design, so don't wait if you'd like to register!) and a single track where everyone will "see all", they have decided to change all the speakers (even though last year's all did a great job).

The speakers this year are:

Erik Meijer, Microsoft, USA (Haskell, C-Omega, C# 3, VB9...)
Niclas Nilsson, Activa, Sweden (Ruby on Rails...)
Dan North, Thoughtworks, England (Agile, BDD...)
Lennart Ohlsson, Lund University, Sweden (dynamic languages...)
Michael Stal, Siemens, Germany (one of the POSA authors...)
Juha-Pekka Tolvanen, MetaCase, Finland (Domain-Specific Modeling, Model-Driven Development...)

You find the new site here: www.expo-c.se

I'll be posting some thoughts about the speakers over the coming few weeks on the Expo-C blog, here: www.expo-c.com/RSS/rss.xml

BTW, isn't this a beautiful picture of Karlskrona?

On top of that, it's sooo nice that something international and really fun will take place here!

Kitchen floor

2006-04-02T00:00:00Z

Our kitchen has been transformed into an empty floor. Actually, it's not even a floor, only the foundation for the floor... It's pretty big and airy compared to what it was, but it's not easy to cook a decent meal.

I could probably connect this to some thoughts about architecture, but we are all so tired of the use of building architecture as a metaphor in our industry - aren't we? - so I'll pass on that. Instead, I just wanted to ramble on a bit about how good I think it is to do something else for a couple of evenings, working hard with the body for example. It actually stimulates my creativity, and gives rise to thoughts about design, for example.

So, if you'd like to share in this creative stimulus, just come on over with a screwdriver and give me a hand with the new kitchen.

;-)

Just don't expect any decent meals for the next couple of weeks...

SOA-Q: WSDL rules or sucks?

2006-03-31T00:00:00Z

Ah, in my opinion this experiment works really well. I have already learned a lot from only three question posts. The old posts (and replies) are here:

OK, over to the question for today:

SOA-Q: WSDL rules or sucks?

Sometimes I get the feeling that many SOA-ers think that WSDL sucks, while at the same time others talk a lot about it as the holy grail. What's the current state?

Comments?

Update (some answers):

Arjen Poutsma wrote Re: SOA-Q: WSDL rules or sucks?
Mårten Gustafson wrote WSDL
Erik Johnson wrote:

In the WS gold rush era (3 years back), WSDL was a toolkit sales rep's best friend. One utility generated all you need to hook up your code and the web. The (now) obvious problems have little to do with the WSDL spec itself. One thing that I think WSDL 1.0 did poorly was help separate the endpoint bindings - the URL - from the actual interface definition. If you're an ISV who delivers WSDLs to your customers you obviously don't want your internal dev machine names littering your product. The W3C explains how to separate the abstract interface from the physical bindings, but few people actually do it and some toolkits don't understand it when they see it. On the other hand, I have trouble blaming WSDL for problems with type systems (mapping XML Schema constructs to programming languages) and design choices (REST, MEST, RPC, whatever).
Jim Webber wrote:

You probably already know about SSDL (http://ssdl.org). It's like WSDL should have been - SOAP centric and able to deal with arbitrary workflows and document exchanges.

I definitely come down in the camp that sees WSDL as a disappointment more than something that sucks. It doesn't suck, it's just a very mediocre and complex toolkit for describing RPC in a protocol agnostic manner.

Foreword by Eric Evans

2006-03-27T00:00:00Z

Last week I showed you the first of the two forewords to my book. You find it here. Today I'd like to show you the second one. It's written by Eric Evans! Here goes:

The best way to learn how to do Domain-Driven Design (DDD) is to sit down next to a friendly, patient, experienced practitioner and work through problems together, step-by-step. That is what reading this book is like.

This book does not push a new grand scheme. It unaffectedly reports on one expert practitioner's use of and combination of the current practices he has been drawn to.

Jimmy Nilsson reiterates what many of us have been saying: that several currently trendy topics - specifically, DDD, Patterns of Enterprise Application Architecture (PoEAA), and Test-Driven Development (TDD) - are not alternatives to each other, but are mutually reinforcing elements of successful development.

Furthermore, all three of these are harder than they look at first. They require extensive knowledge over a wide range. This book does spend some time advocating these approaches, but mostly it focuses on the details of how to make them work.

Effective design is not just a bunch of techniques to be learned by rote; it is a way of thinking. As Jimmy dives into an example he gives us a little window into his mind. He not only shows his solution and explains it; he lets us see how he got there.

When I am designing something, dozens of considerations flit through my mind. If they are factors I've dealt with often, they pass so quickly I am barely conscious of them. If they are in areas where I have less confidence, I dwell on them more. I presume this is typical of designers, but it is difficult to communicate to another person. As Jimmy walks through his examples, it is as if he were slowing this process down to an observable pace. At every little juncture, three or four alternatives present themselves and get weighed and rejected in favor of the one he eventually chooses.

For example, we want model objects that are implemented free of entanglement with the persistence technology. So what are eight ways (eight!) that a persistence framework can force you to contaminate the implementation of a domain object? What considerations would lead you to compromise on some of these points? What do the currently popular frameworks, including the .NET platform, impose?

Jimmy thinks pragmatically. He draws on his experience to make a design choice that will likely take him toward the goal, adhering to the deeper design principle, rather than the choice that looks the most like a textbook example. And all of his decisions are provisional.

The first design principle Jimmy holds in front of himself is the fundamental goal of DDD: a design that reflects deep understanding of the business problem at hand in a form that allows adaptation to new wrinkles. So why so much discussion of technical framework and architecture?

It is a common misperception, perhaps a natural one, that such a priority on the domain demands less technical talent and skill. Would that this were true. It would not be quite so difficult to become a competent domain designer. Ironically, to render clear and useful domain concepts in software, to keep them from being suffocated under technical clutter, requires particularly deft use of technology. My observation is that those with the greatest mastery of technology and architectural principals often know how to keep technology in its place and are among the most effective domain modelers.

I do not refer to the knowledge of every quirk of complex tools, but to the mastery of the sort of knowledge laid out in Martin Fowler's PoEAA, because naïve application of technology paradoxically makes that technology more intrusive into the application.

For many people this book will fill in gaps of how to implement expressive object models in practice. I picked up a number of useful ways of thinking through the application of technical frameworks, and I especially firmed up my understanding of some particulars of doing DDD in a .NET setting.

In addition to technical architecture, Jimmy spends a great deal of time on how to write tests. TDD complements DDD in a different way. In the absence of a focus on refining an ever more useful model, TDD is prone to fragmented applications, where a single-minded attack on one feature at a time leads to an unextendable system. A comprehensive test suite actually allows such a team to continue making progress longer than would be possible without it, but this is just the basest value of TDD.

At its best, the test suite is the laboratory for the domain model and a technical expression of the ubiquitous language. Tests of a particular style drive the modeling process forward and keep it focused. This book steps us through examples of developing such tests.

Jimmy Nilsson has a rare combination of self-confidence and humility, which I have observed to be characteristic of the best designers. We get a glimpse of how he got to his current understanding as he tells us what he used to believe and why that opinion changed, which helps to take the reader past the specifics of the techniques to the underlying principles. This humility makes him open to a wide range of influences, which gives us this fusion of ideas from different sources. He has tried a lot of things and has let his results and experience be his guide. His conclusions are not presented as revealed truth, but as his best understanding so far with an implicit recognition that we never have complete knowledge. All this makes the advice more useful to the reader. And this attitude, in itself, illustrates an important element of successful software development leadership.

Eric Evans

SOA-Q: Good interfaces on day one?

2006-03-26T00:00:00Z

How can the SOA guys succeed in coming up with good interface definitions on day one? Hasn't the whole developer community come to realize that it's very expensive, and close to impossible to work that way?

Comments?

Update (some answers):

Mårten Gustafson wrote Good service interfaces on take one?
David Ing said:

Well it all depends on what you mean by 'interface definition'. Services have (at least) three inflection points:

(1) The Service end-point. i.e. AcmeInsuranceService::

(2) The understanding of the URI that defines the message (is it an RPC call, is it a document...), i.e. AcmeInsuranceService::DoWork(msg M).

(3) The Message format and its interpretation by the recipient. i.e. Schema for 'M'

You can play with all three of those things to get your preferred level of specificity vs flexibility. One downside to this is, of course, everyone has their own level of comfort. Technical standards and toolkits tend to pick people's choices for them too, which still leaves a fair sized 'semantic gap' between what you meant and what they want.

In an object design if we said that the interface definition was immutable from day 1 then it would clearly be over-optimistic; life is never that kind. The only kind of versioning strategies you can use in SOA are the ones we have we with other IDL based approaches (say, COM), just a form of containment and interface inheritance.

So what you do in practice is apply behavioural and structural design patterns to your service design, just as your would your OO domain model. Patterns like Visitor, Strategy, Bridge and Adapter are just as relevant to SOA than to any other complex facade on an object model. You just play with the three 'bits' of the interface you have.

While a lot of stress has been placed on distinguishing SOA away from OO (Law of Distributed Objects and all that), a lot of the same design techniques are just as relevant.

The personal 'sweet spot' for me is to follow a 'MEST' style approach, but even then the ends really (really) need to justify the means, and you really need to think that you can justify that paradigm before setting off: The 'impedance mismatch' of the message and the object is not trivial and, despite what the press say, the amount of plumbing you will end up doing will be more than you expect. Confusion often clouds your reasons for a message-exchange pattern when you bring in other architecture factors like scale, intermediaries and throughput.

The WS standard don't help you with your system design, they just help with the trouble of putting bits on the wire in the least non-standard way you can. There is no silver bullet, designing distributed systems that evolve over time is very hard.
Magnus Mårtensson wrote Is SOA Agile - or can it be? and Part II

SOA-Q: REST, MEST, but what about TEST?

2006-03-23T00:00:00Z

I'm very fond of writing tests as a design catalyst these days! But when it comes to SOA, I can't say I've seen too many (or even any) discussions about it. How come? What am I missing?

Comments?

Update (some answers):

Jason Hunt wrote Unit testing SOA - Testing your connection to a service

SOA-Qs

2006-03-22T00:00:00Z

Here Q stands for Question, not Quality.

SOA hasn't been my thing in the past, but in an egoistic effort to understand more about it, here's the header post to a series of constructive questions.

Sure, this will more or less just point out things I personally haven't grasped and for the knowledgeable, the questions are easy (as always). But I thought that there might be someone other than me who hasn't grasped these things and will therefore be glad that someone asked and that someone (else) answered.

:-)

Here's the first:

SOA-Q: SOA == WS?

I've heard so many times that SOA isn't the same as WS. But at the same time, I often get the feeling that it is actually implied no matter what is said. How is it today?

Comments?

Update (some answers):

johnbr wrote SOA Questions
Arnon said:

Well, it is actually depends on who you are asking

Vendors (whose ultimate goal is to sell more products = new technology) usually imply you need WS to do proper SOA (or the more elegant WS is a natural candidate for SOA) In real life, what matters most is the SOA concepts First and foremost - business alignment and then additional things like the so called 4 tenets (autonomy, share scheme etc.), service bus (for thing like service location transparency)

Another thing is that Architecture is (should be) technology agnostic - you can (and I have) create Service oriented architecture and implementations that do not utilize WS at all.
Mårten Gustafson wrote SOA.doesNotNecessarilyEquals(WS);
Niclas Nilsson said:

In my humble opinion - absolutely not.

I've been working with OSGi (www.osgi.org) and it's predecessor since 1998, which to me and many others is a Service Oriented Architecture. I also believe that most people would agree that CORBA is a SOA. And there are plenty more.

Unfortunately, since a lot of people learns about SOA for the first time when they hear about WS, they seem to use these acronyms interchangeably.

Software architects may code

2006-03-21T00:00:00Z

Ah, this blog post by Michael Stal here was sooo refreshing. I haven't read much about the architect role lately that I agreed with as much as this!

IASA-workshop in Gothenburg

2006-03-21T00:00:00Z

Last year's workshop in Gothenburg organized by SweNug was just great! The workshop will be repeated in a few weeks, but this time it's going to be organized by IASA. I hope to see you there. You find more information here.

Foreword by Martin Fowler

2006-03-21T00:00:00Z

In my ongoing campaign to promote my book, I'd now like to show the two pieces I'm most proud of, namely the forewords written by Martin Fowler and Eric Evans. Your expectations may be too great after having read them, because my writing doesn't come anywhere close to Martin and Eric's. Nevertheless, I'm still extremely proud of them. Here's the first one, by Martin Fowler:

Building enterprise software is rarely easy. Although we have a plethora of tools and frameworks to make it easier, we still have to figure out how to use these tools well. There are lots of approaches you can take, but the trick is knowing which one to use in specific situations - hardly ever does one approach work in all cases. Over the last few years there's grown up a community of people looking to capture approaches to design enterprise applications and document them in the form of patterns (I keep an overview with links at http://martinfowler.com/articles/enterprisePatterns.html). People involved in this effort, such as me, try to find common approaches and describe how to do them well and when they are applicable. The resulting work is pretty wide ranging, and that can lead to too much choice for the reader.

When I started writing Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), I looked for this kind of design advice in the Microsoft world. I struggled to find much of anything, but one rare book that tackled the territory was Jimmy's earlier book. I liked his informal writing style and eagerness to dig into concepts that many others skimmed over. So it's fitting that Jimmy decided to take many of the ideas from me and the others in the enterprise patterns community and show how you can apply them in writing .NET applications.

The focus of this enterprise patterns community is documenting good designs, but another thread runs through us. We are also big fans of agile methods, embracing techniques such as Test Driven Development (TDD) and refactoring. So Jimmy also brought these ideas into this book. Many people think that pattern-people's focus on design and TDD's focus on evolution are at odds. The huge overlap between pattern-people and TDDers shows this isn't true, and Jimmy has weaved both of these threads into this book.

The result is a book about design in the .NET world, driven in an agile manner and infused with the products of the enterprise patterns community. It's a book that shows you how to begin applying such things as TDD, object-relational mapping, and domain-driven design to .NET projects. If you haven't yet come across these concepts, you'll find that this book is an introduction to techniques that many developers think are the key for future software development. If you are familiar with these ideas, the book will help you pass those ideas on to your colleagues.

Many people feel the Microsoft community has not been as good as others in propagating good design advice for enterprise applications. As the technology becomes more capable and sophisticated, it becomes more important to understand how to use it well. This book is a valuable step in advancing that understanding.

Martin Fowler http://martinfowler.com

Developer Summit 2006

2006-03-21T00:00:00Z

Cornerstone and Patrik Löwendahl have arranged a follow up to last year's NorDev conference, called Developer Summit 2006. It was pretty big last year, but judging from the list of speakers and the agenda you can see that they are increasing their efforts quite a lot this year.

On day one I'm going to be giving two presentations on the Methods & Patterns track. In the first presentation I will discuss and apply different patterns on common design problems.

For the second presentation I will be pair-programming and pair-presenting with Erik Dörnenburg from Thoughtworks as we did last year, which was great fun. This was probably because our TDD-session was very practical and we started from zero expectations so to speak. And since the organizer explicitly asked us to do something together again this year, I guess that to some extent we succeeded in showing that there is some substance in TDD etc.

:-)

We will kind of be continuing from where we ended last year, although it will be a standalone session. It is called "TDD, take two", with a lot of focus on Interaction-based TDD and Dependency Injection from a development perspective.

Picture quest - answer

2006-03-10T00:00:00Z

Ah, my readers are too good. Several of you gave me the answer I was looking for.

Of course, the picture shown in Picture quest was meant to show "smelly code". The presentation it was used in was on refactoring. With refactoring we can go from smelly code to something like this:

I received a very good guess that I hadn't been expecting, namely that the picture was about stale data. So I guess I can use it to demonstrate problems with certain caching solutions as well...

Thanks to Kjell Warnquist for letting me publish the pictures here.

Clemens and sirens

2006-03-10T00:00:00Z

Clemens Vasters has written a post about how O/R Mapping can't be such a good thing since it hasn't taken over the world. His post is called The sirens are singing: O/R Mapping.

As usual, no one tool is ever the silver bullet. Saying that, I definitely think that there are situations where O/R Mapping is good solution. Clemens was sent a number of fun comments and I can't wait to hear his answers to some of them.

:-)

Book status [ADDDP]

2006-03-10T00:00:00Z

Phew... I have just finished reviewing the manuscript of my upcoming book Applying Domain-Driven Design and Patterns [ADDDP]. I have now read the manuscript... I don't know how many times actually, I've lost count.

:-)

I will probably read it just one more time before it goes to print which will be when the pages have been laid out.

I think the manuscript has improved a great deal after all the copy editing and author reviews, so - strange as it might sound - I'm actually looking forward to reading it again now that it's so close to completion.

BTW, here's the front cover:

The photo was taken by my friend Magnus von Schenck when he was sailing by the Oresund's bridge (between Sweden and Denmark).

More language focus

2006-03-08T00:00:00Z

Lately I have been pretty obsessed with just how much the importance of languages is growing. Here are a few more thoughts on the subject.

A few years ago I was wishing for some executable extension to XML, but later I decided that that was a good example of "being careful about what you wish for".

:-)

With every passing day I become more and more anti XML as a "programming language". Everyone is pretty much in agreement that XML isn't for humans. Still, it's being used more and more in exactly that way... Two of my friends recently expressed much more interesting ideas regarding the problem I was looking to solve back then, namely sending around executable pieces between tiers.

First out is Ingemar Lundberg (who has just moved his blog BTW). He expressed a thought the other day that when we are working very hard to create as simple Domain Models as possible, does it really make sense to use a complicated language like C#? Wouldn't it be nice with a cleaner, simpler language especially suited for Domain Models? A simple language where subsets of the Domain Model could safely be transferred to the client for execution. It will be interesting to see the alternative that fills this hole. Will it be an existing or a new one?

A few weeks ago Kim Harding Christensen said something similar, but kind of opposite too. He was thinking about writing more generic services that could consume executable blocks from clients and thereby take away the focus of trying to create the "right" and static API for the services, which is often very hard in reality. The language he had in mind was Lisp since it would be pretty simple to validate the chunk of code so it would only do permitted actions. The capabilities of the service will be exposed as functions in the Lisp interpreter resulting in a DSL that is easy to use for the service requester while still having the full expressive power of a real programming language.

First installment of new TDD course

2006-03-07T00:00:00Z

Two weeks ago I gave my brand new TDD course (Applying TDD, text in Swedish only) for the first time. It was a private course for a company and I think it went pretty well. It's always hard to know what those taking part really think and what they will think in a few months when they have really tried to use what was discussed. However they did give me a bottle of very nice wine when we finished which I take as an indication that they thought it was OK.

:-)

I'll be offering the course to the public in a few weeks' time and the only thing I plan to add before that is a section about creating an executable language for the requirements, so that automatic acceptance tests are defined at the same time as the requirements are developed. We will focus on using Framework for Integrated Tests (Fit) for that, but in the future I hope to add some of Dan North's ideas about Behavior Driven Development and JBehave/NBehave as well.

Picture quest

2006-03-06T00:00:00Z

A few years ago local artist Kjell Warnquist drew me this picture for a presentation. Can you guess what it's meant to illustrate?

The answer will be posted within a few days.

Evolution and Hugo

2006-02-28T00:00:00Z

You might have heard about the Mort, Elvis and Einstein personas that Microsoft have been using when describing target audiences for their development tools. Scott Bellware has added another one which he calls Hugo, the Agilist and describes him as the next evolution of developers.

Your take?

What is consulting?

2006-02-15T00:00:00Z

I know, I'm late to the game, but I'd like to say a few words about Bruce Eckel's "What is consulting?".

I agree with Bruce that there are pretty big differences between different types of activities that are often called "consulting". The differences are so big that it is not a good idea to use the same word for describing them.

Having said that, what I wanted to focus on here is how I think it can be a good thing to do lots of what perhaps isn't "real consulting" in order to be able to do some real consulting from time to time. For example, doing lots of development is one way of being able to give some reasonable advice about it.

It's not just one or the other. It's a combination. (As always?)

First technicalities, then semantics?

2006-02-13T00:00:00Z

Which came first, the chicken or the egg?

I have noticed that there seems to be a focus first on the technicalities and then on the semantics. Take Indigo (or WCF) for example. There has been sooo much talk about its technical aspects, but very little talk about how to design for it. I'm pretty sure that when the technicalities have been sorted, it's time for the semantic side. I'm not thinking about technical semantics, but rather business semantics.

Another example is annotations (or attributes as it's called in .NET). Up until now it's been mostly considered a technical tool for describing technical aspects. Erik Doernenburg will be giving a talk at SPA about how the "tool" can be used for domain modeling.

Perhaps it all starts with a customer need, then it goes into tech mode, and then back again (a few years later) to the customer need?

Joel's blog post about Java as a teaching language

2006-02-12T00:00:00Z

In this blogpost called The Perils of JavaSchools Joel Spolsky wrote that Java as a beginner language doesn't foster good developers as well as C (for example) does. It just occurred to me that I'm not without guilt. I was one of those responsible for the decision to move from C++ to Java as the main language for the software engineers at the university I taught at 1994. I think we were pioneers and I still stand by the decision. It lessens the effect of not seeing the forest for the trees I think, which I still believe is valuable for beginners.

Something similar is happening now with Ruby which many think is a great way of teaching concepts with less distractions.

And with lots of concepts in place, the students are ready for taking courses learning other concepts and other languages, such as functional languages and pointed-focused languages for example.

So, is it best starting out with tough language or a simple one? Pros and cons I guess?

Software Factories 1992

2006-02-06T00:00:00Z

I've been lucky enough to hang out with Lennart Ohlsson for a few days. It was very interesting and I learned a lot!

One example of something I didn't know at all was that Lennart wrote a paper about Software Factories in 1992 called "Software Factory Principles, Architecture and Experiments".

Programming the New Web

2006-02-06T00:00:00Z

Bruce Eckel is setting up an OpenSpace Conference called "Programming the New Web". The location is Crested Butte in Colorado which is just amazing. And I think the conference itself will be just as good!

:-)

Back from Cortina

2006-02-06T00:00:00Z

When I left for the software architecture workshop in Cortina I was kind of tired, empty of ideas and badly in need of inspiration. Now I'm back and everything has changed. What a great workshop!

I'm going to post more later, but for now I'd like to mention a few of the highlights:

Martin Fowler presented his latest piece on Event patterns and there was also a very interesting discussion. I think my next project will use some of these explicitly.
Charles Simonyi from Intentional Software presented and showed a demo of what could very well be the next big thing, namely their system. Again, loads of discussion. This was probably the first time they have shown anything without requiring a heavy NDA.
Dan North discussed Behavior-Driven Development (BDD) a lot which is definitely something I'll be trying out soon. To describe it in a single sentence, it seems to be a good way of tying the requirements to the development, in a simple, yet efficient way.

That said, as always the best part is the people and I had such a great time hanging out with everyone who came!

More later...

:-)

FluentInterface for NWorkspace

2006-01-30T00:00:00Z

Since I find it very interesting to play with FluentInterface and since I got lots of feedback to FluentInterface for one order line at a time, I'd like to share some ideas on how to make the currently very raw query API of NWorkspace a bit more fluent.

At present, the code for expressing a simple query that will return all people aged 42 goes like this:

IQuery q = new Query(typeof(Person));
q.AddCriterion(new CriterionInt("Age", NumericOperator.Equal, 42);
return _ws.GetByQuery(q);

I'm sure you'll agree that this is not the most fluent API ever, so let's see what we can do to improve it. First allow AddCriterion() to have several overloads and instantiate Criterion instances itself. Also assume that the Equal-operator is so common that we make it default if no operator has been provided. That simplifies things a bit.

IQuery q = new Query(typeof(Person));
q.AddCriterion("Age", 42);
return _ws.GetByQuery(q);

Let's change AddCriterion() into the intuitive method name of Where() instead (and let Where return IQuery).

IQuery q = new Query(typeof(Person))
  .Where("Age", 42);
return _ws.GetByQuery(q);

An alternative could be to let the IQuery hide the IWorkspace (and only inject it into the IQuery). And since Where() returns IQuery, we can call GetList() at last (or perhaps rather Select() to mimic SQL?).

return new Query(typeof(Person), _ws)
  .Where("Age", 42)
  .GetList();

Was I perhaps too influenced by LINQ syntax when I sketched the above? How would you improve the sketches? As usual, you can reach me here. For a start, I'm particularly interested to hear your ideas for such a simple case as this.

ADDDP on Amazon

2006-01-30T00:00:00Z

ADDDP is now listed on Amazon. So, it's time to pre-order a copy or two.

;-)

The current state of the process is that the manuscript is currently with the publisher and it's being copy edited. The TOC is still the same, except that there is a second Appendix with a brief catalog of the patterns discussed in the book.

Waterfall2006

2006-01-29T00:00:00Z

Fashions come and go and it seems that now Waterfall processes are obviously "in" again. As Brian Button and David Ing have pointed out, here's a conference for both old and new fans:

www.waterfall2006.com

Sooo refreshing!

:-)

And don't forget to click to register!

Public courses published

2006-01-29T00:00:00Z

Or at least the first one of them has been published; the rest will follow shortly.

You'll find the information here (only in Swedish):

kurser

If you're interested, make sure you hurry and reserve a spot because the early bird expires the 10th of February.

FluentInterface for one order line at a time

2006-01-26T00:00:00Z

Martin Fowler has written a very interesting blog post called "FluentInterface". I really must give this a real try in my own designs! All of a sudden my APIs feel very old-fashioned and stiff...

Just to keep the pot boiling, I'd like to check some variations on Martin's example with you.

Martin wrote the code for creating a new order like this:

private void makeFluent(Customer customer) {
    customer.newOrder()
        .with(6, "TAL")
        .with(5, "HPK").skippable()
        .with(3, "LGV")
        .priorityRush();
}

One thing about the snippet that I'm not sure I really like is how skippable() is dealt with. with() is returning the order so skippable() will be set not for the order line, but for the order. Of course the solution is simple; skippable() is affecting the last added order line. Nevertheless, I'm not 100% happy with this solution, although that's not important for the rest of the discussion. So, with that out of the way, let's continue.

OK, let's put this in a certain context. How would you write this if you want to build the order dynamically because of user actions? I mean, adding one order line at a time? Let's try out some proposals and see what you think. First the order itself is created, like this:

Order newOrder = customer.newOrder()
    .PriorityRush();

or maybe like this:

Order newOrder = new Order(customer)
    .PriorityRush();

Then the user picks a product so we add a line like this:

newOrder.AddLine(6, "TAL");

Well, I think AddProduct() feels better:

newOrder.AddProduct(6, "TAL");

Then another product is picked, and this one can be skippable:

newOrder.AddProduct(5, "HPK").Skippable();

If AddProduct() returns the orderLine instead of the order, then the Skippable() thing feels good again.

Instead of letting numberOfItems be a parameter to AddProduct (), it could be a property like this:

newOrder.AddProduct("TAL").NumberOfItems = 6;

But then we get a problem with Skippable()... NumberOfItems() also can be a function instead like this:

newOrder.AddProduct("HPK").NumberOfItems(5).Skippable();

Nah, I think numberOfItems was better as a parameter, but you get the idea for other purposes. No matter what, the whole thing is no longer as fluent I'm afraid...

Any better ideas? (You can contact me here.)

BTW, here's another thought. Do you think it's wise to add a fluent interface on top of the primitive one? For the consumer to use the one he prefers for a certain situation he would do something like this:

FluentOrder order;

PrimitiveOrder order;

Or should there only be a fluent interface exposed, if there is one at all?

Is Agile important?

2006-01-24T00:00:00Z

Could it be that Agile isn't just something for tiny organizations, doing tiny, unimportant projects after all? See this blog post by Jon Tirsen, called When to use Agile according to Tom Poppendieck.

I know, you might get the feeling that agile is considered to be the silver bullet... Still, Agile is worth a thought or two, isn't it?

Language evolution in both directions

2006-01-22T00:00:00Z

We live in the most interesting of times.

:-)

There is a lot of interest in language evolution regarding our programming languages such as C#. Ruby, for example, is getting lots of attention for its expressiveness and clarity. Let's call this increasing the abstraction level of the programming languages.

At the same time, "from the other side", there is a lot of interest about transforming the domain knowledge into tools or executable languages. Let's call this making the domains (something abstract) more concrete...

When will those two meet? What will happen then?

I guess this "phenomenon" has been going on forever, but has there been such a strong focus and interest in it before?

Virtual members and AOP

2006-01-20T00:00:00Z

There are several different techniques when using AOP in .NET, where runtime sub classing is probably the most commonly used.

I've always seen having to declare your members as virtual for being able to intercept (or advice)as a drawback, but Roger Johansson pointed out something to me the other day. Assume you want to make it impossible to override a member, and thereby avoid the extra work and responsibility of supporting sub classing. Then that decision should affect both ordinary sub classing and when sub classing is used for reasons of AOP. And if you make the member virtual, you are prepared for having it redefined, again both by ordinary sub classing and AOP-ish sub classing. It makes sense, doesn't it?

Today Roger posted a great writeup about different techniques for AOP, called Code mangling AOP vs. Runtime Proxy AOP.

Advice semantics

2006-01-04T00:00:00Z

It's now been a few years since I first tried to understand AOP, at least at the conceptual level and its terminology. The other day it occurred to me that the terminology still feels strange. Not that it matters all that much, but why is it called "advice"? It's not advice, is it? It's more like a forced thing, isn't it? Can anyone enlighten me?

:-)

Computing by Bricks

2006-01-02T00:00:00Z

As I said the other day, I'm currently in the process of going through my book manuscript [ADDDP] and one of the tasks is to delete sections that just don't fit for some reason. It's a bit painful of course, but "kill your darlings" is probably good advice here.

However, instead of just throwing these sections away I thought I might be able to use them for something else so here's a part that I wrote at the very beginning of the book, eighteen months ago. It's called "Computing by Bricks" and it's about a certain style of distribution that might be interesting for you if you need to cope with extreme load and therefore need extreme scalability. Here goes.

When considering a system with a huge load, you can normally see that different parts of the system have different characteristics. This knowledge about the system can be used very efficiently for designing and deploying the system.

Assume you are about to build a very large online shopping application. You will probably need some browsing functionality so that the users can browse the catalogue of products. That information is normally very close to read-only, which means that the cluster for taking care of the catalogue browsing need to share nothing. Each server lives a life of its own, having all the information it needs. Each server is not only a web server and an application server but also a database server and can and should also use extensive caching (see Figure 1). If one machine burns, it doesn't take long to add a new machine into the cluster, being an exact replica of the other machines. If the load is too high, just add more replicas.

The catalog browsing

The biggest problem with this part of the system is dealing with catalogue updates. Each user should be able go find the same information no matter which server he comes to at next refresh. Consequently, the updates must go to all servers at the same time. One solution to the problem is using generations of the catalogue so that all servers get the update, but the new generation isn't valid until a certain point in time.

The second part of the system is for dealing with the shopping carts. There is also a cluster of servers, but in this case the database for the shopping carts is a shared resource, once again so that the users can hit any of the servers without noticing any difference (see Figure 2). It might even be that for reasons of availability the database is split over a failover cluster, but it's not very likely.

The shopping carts

At certain time intervals, old shopping carts that were abandoned without creating an order are emptied. This is a pretty heavy operation, but it only affects the second part of the system, the shopping cart module that is.

The third part of the system is for dealing with persistent information such as customer data. Here the load is very low and we might even be able to run very large applications with a single web server/application server. On the other hand, it's quite likely that the database is living in a failover cluster (see Figure 3).

The basic data

Finally, the fourth part of the system is for the filling of the final orders. Compared to the first part of the system, the load here is typically very low. It's usually fine to use a message queue for dealing with the orders, pushed from the shopping carts. The orders are then popped, one by one, as soon as possible. That way, this part is stabilized and at the same time can execute on very moderate hardware (see Figure 4).

Processing orders

Thinking like this, you can grow your application to extreme load in a very flexible manner. Sure, the administrative burden is much higher than with a single box, but the scalability can also be extremely nice, especially from a price performance perspective. Do we need this for most systems? No. For some systems? Yes.