How to name a method.

Class Names and Method names are more important like the most programmer expect. If your software is longer then 30 lines, you should invest some time to find a good name. If you don't know what I'm speaking about, please read this book Clean Code.

If you look more into the naming topic, you will see that the amount of method names or name patterns are very limited. But on service level you find a vary amount of strange names. To avoid mixups, following the SQL query pattern for method names, eg. 

List <Product> getProductsByCostumerIdSortedByDateAsc(final String customerId) 

is a rely good understandable method name, the concern is clear, and the meaning of the method parameter is clear and the side effect (sorted) is also clear. 

Free Book about Chaos Engineering from Verica

Get a free book about Chaos Engineering written by Chasey Rosenthal and Nora Jones. this is  Chasey's second book about Chaos Engineering. His name is associated with well known Chaos Monkey. Follow the link below to get this book for free.

 https://www.verica.io/book/

SCRUM doesn't support Innovation

Most of the leading Software Development Companies using SCRUM today. Many of these companies are also associated with innovations. Now, many people assume that SCRUM is the reason of innovations, but this assumption is wrong. SCRUM is neutral it does not support or inhibits innovations. To support the generation of innovation you need other methods like 3M's 80/20 Rule or others.

1. SCRUM is an ideal environment for code monkeys.
2. SCRUM does not support innovations. There are other ideas need for being an innovating company.
3. SCUM are a capable company environments to keep innovators.

Pro Tip: After 20 years, the book "The Knowledge-Creating Company" from Nonaka and Takeuchi is still my favorite book about innovation and knowledge.

Part 1: What is wrong with SCRUM?

Since I started with XP, I mean eXtrem programming not Windows XP, I'm a big fan of agile software development.

I see many different companies as freelancer. Currently in the most companies I worked for SCRUM is the weapon of choice. There is no discussion to use it or not. SCRUM is the up to date way of scalable software development. The software development is scalable not the software. But in reality most companies have open or hidden problems with SCRUM. But why? SCRUM is easy, many good books are written about it you can hire SCRUM coaches What should could go wrong?

To make a long story short, every thing in SCRUM process can go wrong and it goes wrong. Believe me. But why did this happens, SCRUM is not complex and easy to understand. The answer is the people doesn't match to the SCRUM process. What? I believe that many experienced developers can't understand what it means SCUM doesn't match the people. But in one of the next post of the coming series What is wrong with SCRUM?, I try to explain it.

But not only the humans are source of trouble also SCRUM itself has some disadvantages that could be slow down the software development.

1. Growing technical debt
2. To high feature development speed

For booth problem exists ideas to solve them. In the following posts I will describe the problems and ideas to solve them.

How to Start with Chaos Engineering

First, you should be clear of what is Chaos Engineering for.

Second, create the technical base for Chaos Engineering.

Third, run Chaos Engineering test and analyze the results.

Fourth, Go to one until you reached your goal.

Let's start with first point, what is Chaos Engineering for. Chaos Engineering a software test method that improve the reliability and resilience or robustness of software. If resilience and software reliability are part of product, ask your PO (Product Owner) then a point in the software lifecycle comes where you need to improve these two product features, then you need Chaos Engineering.

Chaos Engineering is the new top of software test pyramid. With Unit Test you guarantee that a method or function works at some points like expected. With component test you test that two modules work together at some points. With integration test you test your component or service in context of the whole software landscape, often the test system is called PRELIVE or NONPROD. But you also test some points. With all these test you try to guarantee the absent of functional errors. Most of these test are positive path test or edge case test. Regardless how hight your test coverage is, there a unknown problems in your software and with this kind of test you never find them or like Edsger Wybe Dijkstra wrote:

Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

And exactly this is the point where Chaos Engineering comes into play. Chaos Engineering are able to find unknown problems or better unknown unknown problem. 

Donald Rumsfeld: There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.

Chaos Engineering is a software testing method to address unknown unknown errors. And from a more practical point of view, Chaos Engineering is the way to improve reliability and  resilience (robustness). In the upcoming articles I will explain the other points of Chaos Engineering.

Rule: Never Deploy on Friday

 

Many developers know the unwritten rule: Never deploy on Friday. The reason for this rule is that nobody wants to repair a live system at the weekend.

If you live this rule, it's a very good indicator for three things they are wrong in your software development:

1. Your application is not well tested for resilience e.g. with Chaos Engineering tools.
2. Your deployment pipeline is not stable enough or you not trust them and your tests.
3. Your not familiar with roll-backs or you have no feature toggles.

One of the major goal is to trust your software and the test so that you feel comfortable to deploy on every Fridays.

One of my major project goes online on Friday afternoon, most developers was not in the office, with success. 

First Post: How does it begun.

It was 2013. I start as freelancer at OTTO group in Hamburg responsible for all non-functional requirements of the new online shop. First things first, what are the so called non-functional requirements, I start with following list:

1. Load
2. Performancence
3. Robustes or Resilience
4. Reliability
5. Security

Well, if read it, it's clear that these non-functional requirements are not independent.

Next we build an huge test environment for load and performance test. Based on it, I start developing a Chaos Monkey inspired Robustness Test Framework called BOM (Brigade of Monkeys). Then the fun starts.

...

The result, we finished the new software 6 month earlier. And at the end I reduced the "out of service" time to a single-digit minutes per year. This was awesome. I the next post I will describe how run Chaos Test and build a reliable, high available, high load and high performance software system.