Following the wave of Lean ideas, I would like to create a new one here in this blog:
The Lean Code.
The Lean Code.
In a nutshell, Lean Code is a software project that is short, independent and extremely organized. The 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 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 a 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.
A 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 a 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) and The Lean Startup from Eric Ries.
The 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)
After much research on code visibility, I realized that to develop a Lean Code you need the following topics below:
- Ubiquitous Language,
- Isolated Minimum Viable Products (or Mini Apps),
- A tool to visualize the intent of your source code.
The advantages of using the ubiquitous language in the source code are numerous. This topic alone is extremely important, and that is why a whole post was previously written for this subject:
This post will describe in detail the important aspects of the Ubiquitous Language when developing a 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:
A 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.
LiveSource and The Lean Code
Development tools are very important to assist the process of building a software. No wonder a development team always uses a number of them. However, most current development tools used by programmers, called IDEs (eg Eclipse, VisualStudio, IntelliJ, etc.), unfortunately are very technical and aren't ideal to view the intent of the source code or to be used by the non-programmers who are also part of the development team (such as stakeholders, product owners, business specialists, project managers, testers and even customers and end users).
That is why LiveSource was developed: for the intention of the source code can be filtered, viewed and understood, and so that non-programmers can participate and contribute more actively in the software development process. Learn more about the advantages of LiveSource here.
This post will describe in detail the important aspects of the Ubiquitous Language when developing a 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:
A 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.
LiveSource and The Lean Code
Development tools are very important to assist the process of building a software. No wonder a development team always uses a number of them. However, most current development tools used by programmers, called IDEs (eg Eclipse, VisualStudio, IntelliJ, etc.), unfortunately are very technical and aren't ideal to view the intent of the source code or to be used by the non-programmers who are also part of the development team (such as stakeholders, product owners, business specialists, project managers, testers and even customers and end users).
That is why LiveSource was developed: for the intention of the source code can be filtered, viewed and understood, and so that non-programmers can participate and contribute more actively in the software development process. Learn more about the advantages of LiveSource here.
Live Source is a Web Toolkit that ensures the source code will no longer be hidden behind a complex technological lawyer, but instead, will be online translated and understood by the programmers and non-programmers of your development team. If the intent of the business is not clearly reflected in the source code, that is the way LiveSource will collaborate with the development team: openly exposing the problem.
"I see value in keeping my source code comments a bit more organized and easier to see than browsing through code.", comment from a LiveSource early adopter.
When a person (programmer or not) views the source code through the LiveSource tool, it is easily detectable if the source is sufficiently organized or not. You can see if the documentation of this code, if any, is relevant to the business domain or if it is only adding technical details (often useless) for the programmers by themselves.
Having the intentions of the business domain completely linked to the source code is a key feature of the Lean Code. The name of each file, each directory, each class, each package, each function and each variable must directly reflect the intention of its existence to the business domain. A non-programmer who reads the name of a file or a function for example, should easily understand its meaning. And then, the documentation of this code should add the business information that justifies and explains its need.
I'd like to repeat here the importance of reading the post about Ubiquitous Language inside the Source Code.
When all participants of the development process, including product owners, project managers, customers, users, etc. can actively participate in building the most important artifacts of a software, that is its source code, the dynamism of communication and accuracy of the results directly reflects on the quality of the final product generated and dramatically reduces the cost of its maintenance.
No comments:
Post a Comment