If you work in software development like I do, you certainly know the struggle when it comes to explain your work to non-technical persons. Using the metaphor of a garden can be a helpful metaphor. But software gardening is not only that, it is also values and principles. I like what I read in this manifesto and this is why I am creating this blog post.

Deep dive into the manifesto

So, what is the definition of a software gardener when we take a look at the manifesto?

Software Gardeners are professionals who perceive software development in a different way. Our goal is to spread the word of our core values, be mentors for the new developers and create software that it is developed at the highest quality bar.

As someone who values the principles of the software craftsmanship movement, I share this definition since it looks similar as the definition of a software craftsman.

To find the analogy with a garden, let’s have a look at the “beliefs” present in the manifesto.

We treat software systems as gardens and code as flowers. Although we don’t disagree regarding software as a “craft”, we believe that software is a living and breathing “being”, not just an object, created using the best materials.

The fact that systems and code are considered as living entities implies that they need attention over time. Your code gets updated to add feature or to fix bugs, the system changes over time to be improved, refactoring phases occur. It is likely that the project you work on is updated everyday even if it is already in production, of course depending on the context, some features are removed to make room for new ones.

We constantly mentor young developers and we share our knowledge at every opportunity. Junior developers are like flowers that need to be irrigated to blossom. We are the water, the sun, the soil, the fertilizer for every (young) software professional.

Software gardening is not only about taking care of the code but also a community where the more experienced developers help the younger ones by sharing their knowledge and skills (water, sun, soil and fertilizer). It is about creating a community which is a value shared also by the software craftsmanship manifesto.

Software development is a lot more than slinging code. We know the practices and we apply them effectively. We make use of the most productive tools and our skill-set includes both soft and technical skills. We also understand that our overall attitude is what defines us as software gardeners.

Creating software and growing a garden both require tools and skills. And it is definitely better to have the right tools for the job and knowing how to use them effectively. Having values is also important in order to provide the best work as possible.

We care about our code and this care, we show it continuously, day by day, every moment in every single line of code we write.

Code is like a flower, it is delicate and needs proper attention in order to flourish. A mistake can have painful repercussions later, do not water your plants and they will die, do not refactor your code when needed and you will have to deal with technical debt.

We are not only able to respond to change but we are prepared about the endless – internal and external – environment reform.

I find this one very interesting because of the notion of “environment”. Growing a garden does not always require the same tools and techniques, it depends on the context. Is your garden in a forest, a plain, a jungle or maybe a desert? You definitely need to adapt to the constraints of the environment you work in. And it is the same for a software project, do you work for a small company or a big one? Is there a lot of processes or not at all? Is your team made of 4 developers or 20? Is the project new or an old legacy system from 10 years ago.

You need to adapt to all of these variables and they might change over time, nothing is finite, everything evolves, remember that: “The only constant in this world is change”.

We treat customers as the people who will walk in our garden and smell our fragrant flowers. Having said that we engage them from the first day, to make sure that all their needs, requirements and expectations will be met.

Collaboration is essential for a software gardener, working closely with the customers is mandatory in order to create the best possible result. Understanding them is important to be able to have a beautiful garden years after years, during all seasons.

Conclusion

Software gardening is about commitment, quality, pride and love for the code and systems we work on. In ways it is similar to the software craftsmanship with an emphasis on the “living” part of the code and the analogy of the garden environment with the software environment.

Remember also that it is just a manifesto so you have to read between the lines in order to fully understand the values and principles behind this approach.

To me it is refreshing to see a new metaphor for our profession/passion/craft/art that is not related to classical engineering work. Which is, in my opinion, not always a good comparison for software development. I recommend you to read Chris Aitchison‘s article on software gardener: You are NOT a Software Engineer!

This week I had the chance to attend the second edition of the NCrafts conference. This conference takes place in Paris and had a lot of awesome speakers from all over Europe.

If you don’t how what this conference is about, have a look at the manifesto below, it will give you an idea.

It’s about programming but also about experience and feedback

It’s not only about technologies but also about practices

It’s not only about software craftsmanship but also about learning and exchanges for everyone

It’s not only about business and applications but mainly about people

In other words, it’s a software conference for developers by developers. We love crafting software with art, passion and technology and share it with everyone.

This manifesto reflects my philosophy and what I try to show in my blog posts. And this exactly what happened during the conference, the speakers and the attendees where very open-minded and we were able to discover new practices.

The Workshops

The day before the conference some workshops were organized by several speakers and I chose to go to the “Event Storming” workshop hosted by Alberto Brandolini and Mathias Verraes.

I will not get into the details of this workshop since I intend to write a full blog post about this experience.

To summarize, the “Event Storming” is an interactive practice that aims to bring the domain experts and the developers closer to each others. You need space on a wall, a lot of space, sticky notes and markers to use this practice.

The goal of this workout is to model the process based on domain events. At the end the developers should have a good idea of how the system should behave and what are the business rules to implement.

DDD, TDD & Functional programming

The conference lasted two days with two talks tracks for each day, there was a lot of awesome content in each talks, a lot of food for thoughts.

Domain Driven Design (DDD) was part of this conference and it makes sense since I believe that, as professional developers, we cannot produce valuable software for our clients without knowing their domain.

Functional programming had also an important place in the conference, it was almost possible to attend only functional programming talks. Most of these talks were made using the FSharp (F#) language.

I made a small introduction to this language a few months ago and being able to see F# developers from the community sharing their tips, tricks and technic was really enjoyable.

I think that functional programming will help us solve some problems we encounter in our everyday job faster than object-oriented programming. It is not better or worse, yet some paradigms of the functional approach are really attractive.

Testing had also a place in the conference for both functional programming and object-oriented programming. If you read my blog you should now know that I write quite a lot about tests, it is a topic I really care about.

During the conference I discovered new approaches for Test Driven Development (TDD) and explanation on the difficulty to practice it. The Type Driven Development (TDD again) practice for F# was really interesting in order to design software.

Waiting for NCrafts 2016

I did not attend last year edition of NCrafts but I will definitely try to go again next year. It was 3 amazing days with a lot of great and open-minded speakers. The NCrafts team did a really great job to make the experience as smooth as possible and as enjoyable as possible.

It gave me a lot of ideas to share with my team in order to improve our technical skills, practices and processes. I can only highly recommend you to watch the talks online when they will be available.

When working with an Object Oriented Programming (OOP) language, we design our classes based on their responsibility, following the Single Responsibility Principle (SRP) of course. We are able to use encapsulation to add behavior within these classes, unlike Procedural Programming (PP). The readability of the application components can be improved this way. Alec Sharp wrote about this topic:

Am I saying that OOP is better than PP? Absolutely not, these are two different paradigms and it is important to remember this. I personally started with the procedural aspects, in C and I moved to OOP with C++ and after that I switch to C#. When I started C++ and the Object Oriented programming it was not as easy as it is now, it was a whole new “world”.

This is where the Tell Don’t Ask principle becomes handy. This principle helps you remember that you should design your components by focusing on their behavior and by hiding their internal working using encapsulation technic.

I have created an example of a component as an example to this principle. We will first take a look at the “ask” version and then we will see the “tell” version. This example is about a payment system that debit a wallet for a giving amount.

In this version my “Wallet” class is only a “data holder” and does not have a single piece of logic. It is the PaymentService that do all the work and “ask” the wallet if it has enough money to continue the operation. And it is the same service that update the wallet balance, it is not necessary the kind of behavior we might want in our application.

Now imagine that some customers are allowed to have a negative balance. In this case I do not want to throw an exception and I need to add a new condition in the DebitCustomer method.

In this version, we can see that the payment service is much “cleaner” and it only focuses on its responsibility, nothing more. All the wallet logic has been moved to the Wallet class, where it belongs. And I used encapsulation to “protect” this class against unintentional uses, only the wallet instance can update its balance amount.

Tell Don’t Ask to save bandwidth

Now imagine that you have a class that act as a client for a service (like in WCF) and it calls a remote endpoint to perform a certain operation if it is available. I create the following piece of code as an example in the “ask” way.

Even it the code does not look that “dirty”, I highlighted the issue in the comments. The client has to make two calls to the service in order to perform the desired operation. This has an effect on the application performance. In this case the “ask” approach clearly needs to be avoided.

I just made a slighty change to the code, now the client always tell the service to perform the operation and the service checks itself if the operation is available or not. This way I was able to reduce the number of calls on the network for my application without removing any functionalities.

You might wonder why I put an example like this one, that looks obvious. Simply because I have seen a similar example in a real world application. This way I wanted to show you the importance of the Tell Don’t Ask principle in some cases.

The Tell Don’t Ask principle helps you focus on the behavior of your classes and the functionalities you want them to expose. Remember that you don’t have to ask your components about their state in order to do an operation, just tell them to do it.

I hope you liked this presentation of this principle, as always, do not hesitate to share/comment/give your opinion.

It is time to see the fifth and last principle of SOLID: the Dependency Inversion Principle, also known as DIP. If you missed the other principles, you can learn more about them by following these links:

When developing software you will have a lot of different modules having each their role and responsibility. You will have to connect these modules between them in order to create the desired functionalities for your system. They will have dependencies between them and it will increase the coupling between your components. So it is important to reduce the risk involved in these dependencies. This is where the DIP rules come in play:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend upon details. Details should depend upon abstractions.

When a high-level module (business service for instance) depends on low-level module (data validator, a repository, …) it is difficult to reuse this module because it is highly coupled.

I have created an example that violates the DIP and I will show a way to solve the issue.

In this piece of code my high-level module is the MessageSender, it allows me to send a given message to a given user (found by its username). For example this is a class that can be used from a user interface with a form. You can see that it has dependencies on a repository and a service, a modification of one of them can have impacts on my class. And what if I want to retrieve my user through a web service instead of the database? Or if I want to be able to send message to my friend via Twitter, Facebook or another social network? I will have to add complexity in this module even if its responsibility does not change from a “business” point of view.

My code is highly coupled and violates the Dependency Inversion Principle, I have to change it and I will by using abstraction (interfaces in my case).

In this new version I only use contracts/abstractions for my high-level component and this way I reduced the coupling with the implementations of the low-level modules. I decided to expose the dependencies via properties to access them and set them in order to clean the “SendMessage” method. When using this class I can now specify if I want to use an EmailNotificationService, a TwitterNotificationService, another social network related service or even a test double if I am in a test context.

Imagine creating automated tests with the first implementation! I would have to create an actual database for my UserRepository and a STMP service for my email based NotificationService. All of this only to test this little piece of logic, with abstraction and dependency inversion it is much easier now to test my components. A few months ago I introduced a DIP pattern known as Dependency Injection, you can learn more here.

This is the end of my presentation of the Dependency Inversion Principle and the end of the SOLID principles as well. I hope you like it and do not hesitate to leave a comment if you want to improve the concepts I have introduced in these blog posts.

In my latest posts I introduced the Single Responsibility Principle, the Open Closed Principle and the Liskov Substitution Principle of SOLID. Now it is time to see the Interface Segregation Principle (ISP). In Object Oriented Programming (OOP) abstraction is a valuable asset especially with interfaces that allow you to design your application by contracts. Even if the interfaces do not contain any actual code it is important to control their size. The following sentence defines the ISP rule:

Clients should not be forced to depend on methods they do not use.

In other words it means that you should have small dedicated interfaces instead of larger ones. This way the client code will only have access to the functionalities it needs. I have created an example to show how the ISP can be violated and how to fix it.

I have this interface that represents a repository to manipulate the entities stored in my database, it has the basic CRUD (Create Read Update Delete) operations. I will use this interface on my User entity:

Good, I have now a full control over my User objects lifetime in the database. Now I also want to be able to retrieve some event logs to be able to consult them, I will use my repository interface to do so.

The issue is that my logs are stored in the database by other applications and in the one I’m working on I don’t have any logging to do. This force me to leave 3 methods empty since they are not used but are defined in my interface… This is clearly a violation of the Interface Segregation Principle. In this example I have a repository that is “read & write” and another that is just “read”. My abstraction is not correct in my context.

I have to find a solution that allows me to keep the functionalities for both repositories without breaking the ISP. I will then create two separate interfaces:

With time my application is likely to grow and use more and more entities from the database that will need “read” and “write” operations. If it is the case I can create an IReadWriteRepository that will be defined like this:

In my example the UserRepository can implement this interface since it works as an alias over the two other ones. The ISP does not prevent you from regrouping interfaces under a common one. This will allow your code to be “cleaner” and explicit without losing functionalities.

This is the end of the Interface Segregation Principle presentation, remember to look for partial implementations of an interface if you want to spot where the ISP is violated.

I hope you liked this 4th principle of the SOLID series and as always do not hesitate to share, comment and give your opinion.

It is time for the third entry for the SOLID series, after the SRP and the OCP, I’ll introduce the Liskov Substitution Principle (LSP). This concept has been introduced by Barbara Liskov in 1984, with Jeannette Wing they define this principle as the following:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S, where S is a subtype of T.

Well, if you are like me you must be still trying to figure this one out to understand how it can be applied to Object Oriented Programming. Do not worry, a more accessible rule has been defined to specify the LSP.

Subtypes must be substitutable for their base types.

In other words it means that consuming any implementation of a base class should not change the correctness of the system. To give more depth to this principle I will use the famous Rectangle-Square example to show how this rule can be violated.

Let me resume the situation: I have a rectangle of 10 by 5 and its area is 25?! This does not make sense. Even if the inheritance seems legitimate, the way it is used in my application violates the Liskov Substitution Principle.

Using the NotSupportedException of the .NET framework is likely showing that the LSP is not respected in your source code. There is even a part of this same framework that transgress this principle.

The ReadOnlyCollection does not allow any modification to the collection, it is impossible to add or remove items in it. Yet its the ICollection interface that defines methods to manipulate the items: the LSP is clearly violated.

The LSP is closely related to the Design by Contract approach to create software. This way your thinking ahead of the pre-conditions, post-conditions and side effects for your application and every implementations of your subtypes are related to your contracts.

This is the end of the introduction to the Liskov Substitution Principle and especially how to detect when the rule is broken. I am still working on a relevant example to demonstrate how to start from a “bad” code sample, like the ones I gave you, to a sample that respect the LSP.

In the meantime do not hesitate to give your opinion regarding this topic.

In my last entry I introduced the S of the SOLID principles: Single Responsibility Principle. Today I will move to the next letter, the O which stands for Open Closed Principle. In an agile environment, teams and projects have to be responsive to change (4th value of the agile manifesto) in order to steadily add value (2nd value of the software craftsmanship manifesto). But respecting these values can be really hard if the code of your application is not easily extensible. This is where this second principle come in play.

Software entities (classes, modules, functions, etc…) should be open for extension but closed for modification.

This is the rule for the Open Closed Principle. There are 2 key attributes in this statement and in the name of the principle as well: open & close. Even if they are in opposition this does not imply that they block each other.

The module is open for extension, this means that it can be extended with new behaviors as the requirements for the application change. Yet the module is also closed for modification, in other words it implies that you should be able to extend the functionalities of this module without modifying its source code. I know it might sound confusing and this is why I’ll show an example to explain how this principle can be used.

In this piece of code I created a class that allows me to send notifications to a user by email or by text. Now imagine that I want my application to notify my users using social networks… I will have to modify the source code of this class to add new behaviors and it clearly violates the OCP. I will update my class in order to change this “mistake”:

My NotificationCenter now use a specific interface to do its work and I am able to add functionalities to it without changing the code. All I have to do is to implement the INotificationService to add a new behavior. By doing this I can even separate each implementation in a specific assembly and I avoid putting Facebook or Twitter dependencies in my class. For instance if the Twitter API changes and I have to change the code, I can only package and deliver the TwitterNotificationService, I don’t have to redeploy everything.

The key to the OCP is abstraction. Yet this does not mean that you have to use it everywhere, the context is important and premature abstraction may add complexity to your source code where it is not needed.