Following the wave of Lean thinking, I would like to create a new one here in this blog:
The eXtreme Lean Code.
In a nutshell, eXtreme Lean Code is a software project that is short, independent and extremely organized. The eXtreme Lean Code can be easily maintained and its intention promptly understood by any participant in the software development process, including non-programmers.
The idea is that even a large and complex application can be composed of several independent, small, organized and easy to maintain software projects. Starting with the SOA concepts, the eXtreme Lean Code goes much further adding the ability of a viable and an easy-to-read source code and the focus on the end user language inside the source code.
Maintenance is one of the highest costs of software development. Two thirds of the lifetime cost of a software involves maintenance. (See Software maintenance). It is much faster (and cheaper) to identify a problem or a feature that needs to be fixed in an eXtreme Lean Code, considerably reducing the cost of software maintenance.
How many features is your source code implementing at the moment? The answer to this question is a good indication if your software project is Lean or not.
An eXtreme Lean Code implements a minimal amount of features at a time. If your source has become a spaghetti, that means, it is too long and so complex that you are not able to identify the features it implements, then the case really needs a Lean refactoring.
It is also important that an eXtreme Lean Code is viable. A Viable and Lean code is the one that has proven itself that has users and customers satisfied. (See the definition of Product-Market Fit).
Good follow-up to this reading would be: The Clean Code (or Uncle Bob's blog).
eXtreme Lean Code in Practice
To develop an eXtreme Lean Code you need the following topics below:
The advantages of using the end users language inside the source code are numerous. This topic alone is extremely important, see User Language inside the Source Code, this post will describe in detail the important aspects of the Ubiquitous Language when developing an eXtreme Lean Code.
The next item is about the MVPs. If your application has a countless amount of functionality, simply implement them all in one given mass of source code will not help in understanding and maintaining this code. Therefore the following definition:
When the requirements of your software begin to multiply, turn yourself to the intent of the application. Focus on your MVP. After interviewing your clients and consulting your market, if new features prove themselves as actually useful to the users (see Defining Your Mininum Viable Product), then split these new features in different MVPs and create independent software projects for them, with isolated source code. If necessary, use APIs and communications interfaces between the MVPs, but not simply develop them into a single mass of the same source code.
In a nutshell, eXtreme Lean Code is a software project that is short, independent and extremely organized. The eXtreme Lean Code can be easily maintained and its intention promptly understood by any participant in the software development process, including non-programmers.
The idea is that even a large and complex application can be composed of several independent, small, organized and easy to maintain software projects. Starting with the SOA concepts, the eXtreme Lean Code goes much further adding the ability of a viable and an easy-to-read source code and the focus on the end user language inside the source code.
Maintenance is one of the highest costs of software development. Two thirds of the lifetime cost of a software involves maintenance. (See Software maintenance). It is much faster (and cheaper) to identify a problem or a feature that needs to be fixed in an eXtreme Lean Code, considerably reducing the cost of software maintenance.
How many features is your source code implementing at the moment? The answer to this question is a good indication if your software project is Lean or not.
An eXtreme Lean Code implements a minimal amount of features at a time. If your source has become a spaghetti, that means, it is too long and so complex that you are not able to identify the features it implements, then the case really needs a Lean refactoring.
It is also important that an eXtreme Lean Code is viable. A Viable and Lean code is the one that has proven itself that has users and customers satisfied. (See the definition of Product-Market Fit).
Good follow-up to this reading would be: The Clean Code (or Uncle Bob's blog).
eXtreme Lean Code in Practice
"To trim the size of a code base and keep it small, we have to eliminate unnecessary code, employ good coding practices, and justify any new code." (The Art of Lean Software Development)
To develop an eXtreme Lean Code you need the following topics below:
- User Language inside the source code,
- Isolated Minimum Viable Products (or Mini Apps),
- A tool to visualize the intent of your source code.
The advantages of using the end users language inside the source code are numerous. This topic alone is extremely important, see User Language inside the Source Code, this post will describe in detail the important aspects of the Ubiquitous Language when developing an eXtreme Lean Code.
The next item is about the MVPs. If your application has a countless amount of functionality, simply implement them all in one given mass of source code will not help in understanding and maintaining this code. Therefore the following definition:
An eXtreme Lean Code should contain only one Minimum Viable Product.
When the requirements of your software begin to multiply, turn yourself to the intent of the application. Focus on your MVP. After interviewing your clients and consulting your market, if new features prove themselves as actually useful to the users (see Defining Your Mininum Viable Product), then split these new features in different MVPs and create independent software projects for them, with isolated source code. If necessary, use APIs and communications interfaces between the MVPs, but not simply develop them into a single mass of the same source code.
No comments:
Post a Comment