Too short; didn't read

  • The A in Agile

    —

    Matias
    in

    The A in Agile is from automation. At least in the context of Agile development. Automate everything that you can. Start with that. It may be a bit slower to do the first time, but as Agile development is iterative, it will likely gain the lost time in no time. It enables scaling of organization…

  • Private blame over public shame

    —

    Matias
    in

    Mistakes happen. When one makes a mistake, it’s shameful and it’s better that no one else knows of our weakness, right? We prefer to narrow down the information of our mistakes to the minimum. And so we prefer private blaming over open communication, or public shaming. When working with more people than me, myself, and…

  • Give me a screwdriver

    —

    Matias
    in

    Said a developer, likely never. Even if screwdriver is not used, at least a lot, in software development, other tools are. Editors, compilers, libraries, spotify, browsers, consoles, gen-AI girlfriends, coffee machine, food delivery, and other tools enable the modern development of software. Some of the used tools are expensive, others irreplaceable, and some are tailored…

  • Old ways are dead. Long live the old ways

    —

    Matias
    in

    Let’s be honest. Agile transformations are painful. Changing the way an organization operates is hard. The transformations end up being unfruitful – everything works as before but now it’s called agile. Or worse, ending up to a chaos. Agile isn’t a silver bullet that would fix everything. And maybe it’s not always the way people…

  • The fast and the laborious

    —

    Matias
    in

    Development of multiple, similar, products raises a question. How to make them more efficient? Making each product from a scratch is very inefficient. Maintaining multiple products, without commonalities, is a struggle. What to do to make the most of synergies between the products? This is where software platforms appear. They are abstract product-like entities that…

  • The birth of a product team

    —

    Matias
    in

    Someone has a brilliant idea. A search for the right people that can make that idea real starts. The team is formed around the idea. At some point, the team has grown and it has to be split into two. But everyone is working around making the brilliant idea alive. This is the easy way…

  • Simple service, complex system

    —

    Matias
    in

    Microservice architecture is good in forcing the implementation to have clear interfaces and clear responsibilities. Extending the system is straightforward and interruption less. The system is easy to make scalable and highly available. Updating a service can be done independently and in ways that has no impact on the rest of the system. But microservice…

  • One test to rule them all

    —

    Matias
    in

    To test a unit thoroughly, one has to throw different sort of things at the unit to make sure it behaves well in different situations. Throw it with some – or all – normal things, with a bunch of abnormal things, and finally with a few why-on-earth-would-you-do-that things to see how it reacts. With all…

  • The constraints of everything

    —

    Matias
    in

    To build a pyramid, you need resources like employees, tools, and huge rocks. And then you need time. Even with unlimited resources it will take time to build the pyramid, although more resources might reduce the time. Then there’s the target – what sort of pyramid is to be built. The effort to build a…

  • The number of pieces in a software puzzle

    —

    Matias
    in

    One of the fundamental architectural decision when designing software is to decide how the software is delivered. Is it delivered in a single, complete, self-sufficient package or will it be delivered in multiple small packages that are independent but interacting with each other. This is the decision between monolithic and microservice architecture. Both of the…