When we start a new software project, we are typically full of enthusiasm. The whole team thinks that this time we will be able to avoid the mistakes we made in our previous projects. We dream that this time everything will be perfect.
And then, we wake up.
When the first weeks (or months) are over, we start to notice all kinds of problems:
- Our project owner has gone AWOL, and we suspect that he is not as committed as we are.
- We cannot automate the deployment process because our build script sucks.
- We notice that our codebase isn’t perfect and it needs to be refactored.
If we fix these problems, do you think that our problems are over?
No. We will notice new problems, eventually. That is why we need to have a continuous problem solving “process”.
A continual improvement process, also often called a continuous improvement process (abbreviated as CIP or CI), is an ongoing effort to improve products, services, or processes.
Kaizen (改善), Japanese for “improvement” or “change for the best”, refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, and business management.
Wow. That sounds pretty fancy (bullshit). However, we should not let the fancy definitions fool us.
There are three reasons why continuous improvement is useful to us:
1. It Makes Sense
Continuous improvement is not just a fancy word. It is a natural process which aims to improve our current situation. In fact, we use a very similar process in our everyday life. Let’s think about the following question:
What will you do if a light bulb burns out?
Exactly. You will replace it with a new one.
What will you do if the new light bulb burns out when you turn the lights on?
Will you replace it with a new one or order an electrician to check out if something is wrong with the electric circuit?
That is a tough call.
Often when we solve our existing problems, we notice new ones. Of course this doesn’t happen all the time but when it does, we have to react (or face the consequences).
Sitting in a dark room is probably pretty uncomfortable but continuing a software project without solving its problems can lead to a catastrophe.
Does it really make any sense to take that risk?
2. It Helps Us to Work Smarter
I am a pretty lazy person. That is why I don’t want to work harder if I can achieve the same or better result by working smarter. In other words, I want to eliminate all work that isn’t absolutely necessary.
This is exactly what continuous improvement does for us.
It is essentially “a continuous process” which has three steps:
- Identify a problem.
- Fix it.
- Ensure that it doesn’t happen again.
Problems which we face during a software development project are basically obstacles which causes us extra work (either now or later). Thus, it makes sense to solve them as soon as possible so that we can minimize the amount of extra work.
When all members of our team are committed to solve problems as soon as they are identified, we can do just that.
3. It Helps Us to Eliminate Waste (and Add More Value)
What is the most important responsibility of a software developer?
The obvious answer to this question is:
Although programming is one of our responsibilities, it is not the correct answer. The most important responsibility of a software developer is to add value to the customer.
Everything not adding value to the customer is considered to be waste (muda)
This includes (amongst other things):
- Unclear requirements
- Slow communication
- Delays caused by the software development process
- Unnecessary code and functions
Does that list ring a bell?
The problems which we face during a software development project reduce our capability to add value to our customer. Thus, the sooner we solve those problems, the less waste we create.
Always Be Improving
Continuous improvement is not an easy method to follow. When everything seems to be in order, it is very easy accept the status quo, and stop looking for possible problems.
Ironically, this is the moment when we should press harder and harder. Obvious problems are easier to spot and fix than subtle ones, but those subtle problems cause us the most harm in the long run.
If we cannot identify the problem, we cannot “estimate” its impact or fix it. We are blindfolded!
I am painfully aware of the fact that many software projects are finished this way, and I claim that this is one reason why so many of those projects fails. If we cannot see where we are going, how can we expect that we succeed?
We should choose another path. We should maximize our productive by working smarter and smarter. We must be ruthless and continue eliminating waste even though we are not sure where we can find it.
If we are persistent, we will be rewarded.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.