Introduction

The nature of software engineering.

Since reading the book Modern Software Engineering, I've been reflecting more.

Software engineering is different from other fields. When I think of software engineering, many thoughts come to mind.

This is more or less me going on a rant.

Software engineering

Software engineering is solving problems.

Software engineering is delivering customer value.

Software engineering is hard.

Software engineering is frustrating.

Software engineering is beautiful.

Coding and software engineering aren't the same things.

Writing code is one of the ways to build software and solve problems.

Unknowns

When building software, there are many unknowns. As we've learned from history, the waterfall method doesn't work well. The reason agile works well is that we're correcting the course sooner.

We deliver early and often. We incrementally get feedback from the customers. It doesn't take long to realize if we're doing something wrong.

Estimation

Estimations are never right. Software is unpredictable and you will never be able to estimate the time or effort precisely.

Yes, you might get better at it over time. But the statement is still true.

I believe estimation should be done so the team is aligned on the complexity of a task. It also makes it easier for the product team to prioritize the work to be done.

Surprises

Surprises will happen.

Something you thought would take a couple of hours could take a week.

It's fine.

That's the nature of software engineering.

Social activity

Software engineering is a social activity.

I learned that from Extreme Programming. Software engineering is at its best when the team collaborates effectively and is greater than the sum of its parts.

Some teams are just a group of resources.

Other teams work as actual teams.

I don't like to compare software engineering to other things because the field is unique on its own. But if we look at soccer. Isn't it beautiful how the team is collaborating?

I'm not saying we should all work on the same thing all the time, but I believe we should shift our mindset to build good software consistently.

Customer value

If the software isn't delivering customer value, it's garbage.

Delivering customer value is the number one priority.

That's why being agile works well. We're making sure to steer away from the wrong direction quickly.

Customers care about the problems you solve for them.

What technologies or architecture you use doesn't concern them at all.

Code

Simplicity is underrated.

We should strive to write clean and consistent code.

One of my quotes:

The sooner you understand the code, the sooner you can begin working with it.

If you haven't understood the code in place, how will you be able to work with it?

When I think of good code:

• Readable

• Simple

• Sticking to the single-responsibility principle and YAGNI

• Adhering to domain language

• Decoupled with intentional coupling

Testing

We write tests to ship with confidence.

We want confidence that our software works as it should when the user interacts with it.

We should test the behavior, not the implementation details.

There are three ways to write automated tests:

• Unit

• Integration

• E2E

E2E gives the highest confidence. That's where the user is fully resembled and very little if no mocking is done.

If code doesn't have tests, we don't really know whether it's getting better or worse.

Tests serve as documentation.

With tests in place, we can refactor confidently and move quickly.

Test-driven development is arguably one of the best ways to deliver software. It would've prevented many bugs and debugging sessions people had to go through.

Conclusion

Software engineering is the coolest thing ever.