Software Engineering Farley Note 1

Here are my notes on the excellent book, Modern Software Engineering: Doing What Works to Build Better Software Faster, written by Dave Farley.

Dave Farley describes software engineering as:

The application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.

It's a compact definition but it is a great way of defining what the software industry tries to do, or in the author's case how they should do it.

The aim is that software should be an engineering endeavor, which means applying the scientific method to solve real-world problems.

Let's break the keywords down, there is a lot of intermixing between the different categories:

Empirical Approach

This is to take a data-driven, experimental methodology to help us learn, advance understanding, and find solutions for problems. This is the backbone of science.

Experiments produce information, to inform our decisions

Without data or evidence, we cannot trust that it is true or show it is false. We base our decisions on these rational criteria. It is unbiased.

It is iterative. The experiments help us narrow down the truth by finding out information, so we can focus on future experiments to get to a better and more focused truth/solution.

We need to be more organized in how we assemble the signals we gather from reality and assemble them into theories that we can test through experimentation.

Empiricism helps us sense check the validity of our experiments. It takes in the practicality of the experiments and their outcomes.

We can be informal about experiments, as we can rely on experience to inform our decisions. Although, this can lead to wrong conclusions, much better than the haphazard and random approach. As our perception of reality might be wrong to what is there.

Scientific Approach

This is closely linked with empiricism.

The scientific method/approach is a way of ascertaining knowledge of the world, and can be set out as:

1. Characterize: Make an observation of the current state.
2. Hypothesize: Create a description, a theory that may explain your observation.
3. Predict: Make a prediction based on your hypothesis.
4. Experiment: Test your prediction.
5. Conclude: Did the experiment prove the prediction.

Being skeptical. How can we break it down, falsify them, disprove them?

Don't jump to inappropriate conclusions.

Applying this leads us in the direction of more deterministic systems and code.

An example of applying the scientific approach is TDD.

Efficient Solutions

The problem with science is that it can be too logical, not applicable to the constraints that the real world or your business or your existing systems present you with.

This does not mean, finding the most efficient time and space algorithm to solve the problem. Unless this is what is required. Instead, a brute force solution may be all you ever needed if you are using small amounts of inputs.

This is about perfection and the impossibility of such a system. Thus aiming to achieve this will slow you down, and probably never finish. Remember we need solutions, results, and something that is being used. If it is not being used, it does not exist, it cannot be improved upon.

Using the scientific approach and empiricism to discard bad ideas before they take root, and stop those ideas from slowing the software delivery process.

To deliver some value from software is the aim.

Economic Solutions

The world is real, it has many competing factors, and we cannot control them all. Our software lives and is used in this world, not in our heads, not in theory.

Constraints such as money, time, experience, etc, affect the creation of software. We need to get value for our resources, ie value for money.

The aim is to improve some resources via software, either increase revenue, reduce costs, help people, become famous, get investment, etc

There will be trade-offs, when money is tight, maybe one feature needs to be dropped. If time is tight, maybe making the code more maintainable can wait (known as tech debt). If a rival is creating the same product, then getting a product created in a naive way is better than missing out on customers.

There will always be a discussion on what should be prioritized. The scientific method helps with this, it gives us feedback to decide whether these priorities should change (being agile).

Practical Problems

We solve problems through our software. Software is a solution to a problem.

There are many problems to solve

• Not all problems can be solved.
• Not all problems need to be solved (not worth it, no users, or not enough users).
• Not all problems are economic to solve (is the money to pay for it, or time to do it in).
• Not all problems are known.

But there exists a set of problems that we can solve which have practical application, some usefulness, and can provide some economic benefit.

These problems can be vague, not fully formed, hard to capture accurately.

Knowing what these problems are and working on them is the challenge.

A bigger challenge is knowing when to give up or change it to solve a different problem if we find out the original problem is not economic (being agile). This is where the scientific method comes in, and another popular approach named LEAN is used.