I'm a huge fan of #NoEstimates movement. After more than ten years as a software developer, I still suck at estimations, sometimes even for simple things. And I will probably ever be. The thing is that I'm not the only one:

On Average, Large IT Projects Run 45% over Budget and 7% over Time

I don't want to get into details how no estimates approach works neither when and how to estimate what needs to be estimated. I will not dig into reasons why we, developers, are so inaccurate in estimations.

Instead, I would like to sell you this methodology with arguments that already sold it to me.

Stress

Estimates that one cannot make are stressful to everyone.

Starting from a developer who either blames someone else who acts as a dependency or feel guilty as a lame programmer. That will feel anger on the manager or customer that made pressure to put lower estimations. Or some authority that during estimation round told everyone nah, that's easy.

Through manager who acts as a proxy and has to handle customer anger, ask hard questions to the team or response to the customer with bad news.

Finally customer. The one that pays our bills and starts wondering if someone tries to make him fool.

Quality

Have you ever tried to lace your shoes in a nervous hurry? Even the simplest things that you do every day with closed eyes, start being complex under pressure. Imagine that you have to, in such conditions, create something complicated or fix a bug that doesn't work for unknown reasons. Something that requires focus, time and deep thinking.

With the burden on your shoulders instead of well-crafted solutions, you start looking for shortcuts. You stop thinking about maintainability. Code reviewer will know that whole this crap should be buried in the 7th circle of hell but there is no time to make it proper, so just close your eyes and accept this spaghetti that even creator could not understand.

Useless meetings

Let's say that you have sprints 2 weeks long. Every other Monday your team spend some time to estimate. Multiply the number of meeting participants by hours spent by your wage and you can throw that money to the basket equally.

It's an open secret that developers are bored during such meetings. They rarely can fully concentrate. But even if they can there are a lot of unknowns on the sprint track.

There will be issues to be covered outside of the scope.

There will be unexpected interruptions.

There will be dependencies that we have to wait for.

There will be misunderstandings.

Finally developers - as probably all human beings - tend to overstate their skills and will be really sure that can accomplish this task in a proposed timeframe which, as we already know, rarely will be real.

What instead?

Should you instead allow a developer to tackle the task as long as they wish? Definitely not. There are a lot of articles, probably even thesis, about benefits of deadlines. The key here is to take advantages and hide shortcomings.

Instead of estimations we should demand defined deliverables every day.

When a task is too big to be delivered in a single day it should be split as soon as developer notice that fact.

As a side effect, this would require making proper plan before tackling the task… and that could give you a tool for more accurate estimations. Small portions of work in single tasks allow measuring real velocity of a team in tasks per day.

It would also require leaving project at the end of a day in a state without tasks open for weeks. If any developer won't come to work another day others in the worst case could start the work from scratch - not so much will be lost.

Yes, I know that good Agile practices require the same thing, and some still have estimations. But it doesn't reduce problems mentioned above and it's much easier to lay back discipline of small tasks when they're actually not crucial in your methodology.

This approach might not be intuitive for many, definitely, it makes tricky long-term assumptions, but I encourage you to give a try. It's one of this thing that once tried, you never want to go back.

Have you ever rotated a mobile screen while reading a post on LinkedIn and lost it? Have you ever closed a social media post because content wasn’t available to read without an account? Have you ever had a hard time following the Twitter/X post spread into a thread? Have you ever missed a post of someone who you follow, but it never showed up on your feed? Have you ever struggled to find a post that you didn’t have time to read when it showed up? Have you ever been trying to find a specific past post on any of the social platforms?

Why do we do this ourselves?

We are feeding the rich with our knowledge without any benefits in return. Instead, they make content hard to read, hard to search, hard to edit, and hard to follow. And hire algorithms to throw trash into our feeds.

The most powerful aspect of the internet is that everyone can participate in shaping it. You can plug in your machine and host whatever you like in any form. You can own your data, even a full platform. You can utilize open standards (like HTTP or RSS/Atom) and give the audience freedom how to consume what you produce.

Unfortunately, we used to give up on freedom.

Making a blog is trivial and can be easily hosted for free. You can use any language or pickup platform that makes sense. With minimal investment, you can host under your domain (and you should). You can notify your readers about new content in a standard way and allow them to consume it at their pace.

You can be googleable. Or duckduckgoable. You can own your data and make it look unique if you like. Or just use plain HTML.

Social media is useful to tease the content and bring attention. Maybe discuss. But please, stop ruining the internet, and if you value what you produce and your audience, let us read properly.

Recently I was giving a talk about the Decider pattern, and I was asked when Event Sourcing clicked for me. I’m too old to remember when, but I still remember what it was.

Let me quote myself:

My personal greatest benefit of events is the influence on the way I think about designing the system. The moment when you have to name the fact that actually happens opens a magic box in your head that unveils edge cases, impacts on other parts of the system, or unknowns that you have to ask the client. It really changes the way you think and communicates with others. It shapes your language.

I still remember this mind-blowing effect when I realized how powerful this simple concept is. That instead of overriding a row in the database, I have to name in business terms what just happened (so no to CRUD-sourcing).

If you think that naming is hard, you will quickly realize how painfully hard it is to name every operation in the system. And that often you simply don’t know why something happens. Or what consequences such actions should have. But thanks to this pain, you will quickly become a person who is not afraid to ask “dumb” questions or start thinking a few steps ahead. You will start noticing when duplication is a pattern to DRY or when it is just similarity that should stay duplicated. That leads to simpler solutions and maintainable systems that are more flexible and easier to change.

It’s a win for business and for you.

Of course, just the fact you use events does not mean you have to use event sourcing. However, event sourcing pushes you for real business naming, so it a has bigger impact.

Two thoughts from this week

1. Understanding of good code/architecture will now be evaluated by how well AI can pick it up.
2. AI is the new China. Cheap mass production and making it easy to throw away always displace tailored production. Security issues? Nothing new, just think about toys that are eventually banned from the EU market as dangerous for toddlers, materials that should never get in contact with food, things that are broken on first contact, etc.

Which reassures me that Event Modeling with Vertical Slices is a perfect choice for years to come:

• optimized to parallelize and automate the work
• optimized to throw away parts that are broken or don’t fit the needs
• quality of a part (slice) is less of a problem as they are easy to replace or recreate
• slices are limited to just two standardized types which makes them easy to roll for mass production
• it’s easier to stop chasing opus magnum quality in every single place
• at the same time, chasing for quality in one part will not slow down others as they are fully decoupled

Actually, that’s actually more than two thoughts, but AI can’t count and nobody cares.