I've worked in a few scenarios where we had a BFF web API that talked to a back-end API on behalf of the UI.
I see some benefits to having a web API tailored to the needs of a UI, but there are few problems that seemed to repeat: 1/18 - A lot of what was in the BFF was just redundant. We had requests that mapped to similar or identical requests. Sometimes the BFF and the back-end API would share requests in a library so that the same requests could be used from end to end. That seemed pointless. 2/18

If documentation matters then we need to be better at figuring out
- What to document
- When to document We don't need documentation that illustrates the obvious. The greatest evil is a diagram showing that our web app talks to the database, and then listing details like database columns.

When I started writing code I knew I wasn't good at it. But I didn't know what good was. I asked around. I looked for it.
What I found was resistance to the very idea that we can be good at it. It surprised me then and I still can't get my head around it. Just about everyone I worked with learned coding on the job starting with VBA and FrontPage, just like me. We got by. We automated tasks for people and they thought we were amazing. To borrow from Amadeus, everyone liked us. We liked ourselves.

We must be comfortable with uncertainty. We can have some vague idea of how we'll implement something, but the way we find out exactly what it's going to look like is by doing it. Until then we have uncertainty. 1/ An anti-pattern I see is that we try too hard to get rid of that uncertainty.
We try to plan all of the tasks for all of our stories at the beginning of the sprint.
We make "stories" so small that they do nothing. 2/

Hexagonal architecture makes less sense if we see our entire application in terms of CRUD, where the application gets some entity, modifies it, and then says, "Here's my updated version of that entity." 1/ If that's what we're doing then the database *is* the application and the rest of the architecture will feel useless and redundant. We're doing the same thing we always did but trying to make it look like something else. 2/

I'm experimenting with some ways to put guardrails on a new .NET app to hold off entropy and chaos.

Step 1: Get the dependencies pointing the right way. There are projects for data and HTTP clients. The Services project (logic) depended on them both, so I'm reversing that. 1/ I can't prevent future people (or myself) from putting low-level details where they don't belong, but this will make it harder. That's what I mean by "guardrail." I can't force anything, but I can guide it in the right direction. 2/

When we think about code dependencies we need to separate compile-time dependencies from run-time dependencies. Confusing them makes it harder to reason and make good decisions. 1/ For example, our higher-level service code might depend on an abstraction, like IRepository<Foo>. Where should we define that interface - in the service project or in the data project alongside the database code? 2/

The concept of a data access "layer" means nothing to me. Should it? Layers are things that lie beneath or on top of other layers. I try to imagine an application's architecture in terms of layers and it makes no sense. In my mind there are abstractions and implementations, not layers. They look more like nested concentric circles. I'm trying to replace that with a hexagon. But not layers.

What do most car safety features have in common?
Rear cameras, automatic braking, ant-skid systems - all of them recognize the limitations and occasional failures of even the most careful drivers. 1/ Yes, we should all be careful. But we're human. We make mistakes. Adding safety features to cars protects us more than just saying, "Be more careful."

The same is true of software development. 2/

I see a repeated tendency in .NET to create base classes for API client classes, SQL repos, etc. The base class does all sorts of authentication, tokens, maybe retry logic, etc. They have several dependencies of their own, sometimes as many as 10. That means the inherited classes have large constructors, and in order to test those classes we have to create mocks or pass something for those constructor arguments.

It doesn't matter how many people are in the store. Walmart will always have enough self-checkout registers closed or out of order so that you have to wait in line. Every night Walmart moves the shelves a millimeter closer together so that the busiest aisles with poles supporting the ceiling get narrower and the least busy aisles get wider.

Here's a random, half-baked musing. It will go nowhere useful.
Suppose developers united and decided that if code didn't meet certain standards, we would refuse to work on it.
I'll use unit tests as an example of such a standard. If your code has been committed past some cutoff date, no member of the United Federation of Excellent Developers will work on it.

Don't try to account for race conditions. Eliminate them. Prevent them.

Ever see a delay added to code to account for a race condition? At least two bad things can happen, and it's not either/or. 1/ The first risk is that the delay might not be long enough. Or it might be long enough most of the time. Or for now, until something changes. Even after adding a delay, it's still a race condition. You've still got the same problem. 2/

Have you heard of the "curse of knowledge?" It sounds conceited, like "Poor me, cursed with all this knowledge."

It just means that sometimes we forget what other people don't know, or what it's like not to understand something. 1/ A great remedy for the curse of knowledge as it relates to writing code is answering questions on #stackoverflow. It forces you to figure out what concepts someone doesn't know and relate to them so you can explain them. 2/

Imagine an assembly line building cars. At what step do the doors get painted? Probably before they're attached to the car.

Suppose you follow it down the assembly line and find two, maybe three points where the car is inspected to see if the doors are painted. 1/? If the car arrives at that step and the doors aren't painted, they get painted then. Maybe that happens when the fuel cap is attached, or when the tires are put on, or both. Maybe once in a while the doors get an extra layer of paint. 2/?

In order to modify code we must understand it. Understanding code requires effort, whether a little or a lot. We should minimize it, but I wouldn't generally call it waste.

What if that effort reveals that the code does nothing? 1/? Sometimes it's as simple as identifying dead code. In other cases we follow parameters passed from one method to another or properties of objects and after digging through the code realize that we never use them. 2/?

Developers say "We don't have time to write unit tests because management rushes us." Regardless of whether they're rushed or not, no developer who understands how unit testing makes us go faster is going to say that. 1/n #softwaredevelopment But if the developers don't understand how unit tests make developing working software faster, not slower, are they going to tell their managers that they need to adopt a practice of writing tests? Of course not. 2/n