On Wisdom and Happiness

I spend considerable time thinking about the meaning of Wisdom and Happiness:

  • What are the characteristics of a wise person?
  • What are the characteristics of a happy person?
  • Can wisdom and happiness be measured?

Of course I also think about the relationship between the two:

  • Are wise people happier?
  • Can we increase our happiness by increasing our wisdom?

In the Venn diagram below I try to capture one possible aspect of wisdom: The relationship between the “things we want” and the “things that are good for us”. The set W is the intersection of these two kinds of things. I believe that the number of items in W may be a measure of wisdom, meaning that a wise person is able to understand what is good for him/her.

Wisdom

Consequently, happiness would be the capacity to obtain these “things that we want and that are good for us”. In the Venn diagram below, the set H is the intersection between W and the “things we have”. I believe that the number of items in H may be a measure of happiness, meaning that a happy person has many of these things that he/she wants and that are good for him/her.

Happiness

Of course I’m not talking only about material possessions. I believe that the “things you have” should consist mostly of the personal goals you achieved and the dreams you realized.

So what is the the path to happiness? First you increase the number of things in W, by understanding which things are good for you and “wanting them”. Then you increase the number of things in H, by obtaining the things that you want and that are good for you.

In other words, before realizing your dreams, make sure you are dreaming the right dreams.

What do you think? Do you agree? Please share your comments below.

Posted in Efficacy | Tagged | 2 Comments

Resource Adaptive Software Systems

The International Association of Software Architects (IASA) in Israel organized a special event about Adaptive Software Systems. We invited Tom Mueck to give a talk about “Resource Adaptive Software Systems”.

Title: Resource Adaptive Software Systems

Abstract: DARPA issued an announcement about building Resource Adaptive Software Systems this past April. More specifically “to build survivable, long-lived complex software systems that are robust to changes in the resources provided by their operational environment”. The motivation behind this project has to do with the short shelf life of modern day software systems:

  • Orders of magnitude less than other engineering artifacts.
  • Strongly inversely correlated with the rate and magnitude of change.
  • When changes do occur they lead to high software maintenance costs and premature obsolescence of otherwise functionally sound systems.

All of these factors greatly impact an enterprise architecture and every architect wishes there would be better technology around.

This talk will introduce a new general computing abstraction named Resource-Oriented Computing (ROC) and discuss these areas of particular interest to architects:

  • Coupled, loosely coupled and decoupled systems
  • Resource-Oriented Architectures
  • Messaging
  • Risk surface / Security

Bio: Tom Mueck is the Director of Business Development at 1060 Research – which was spun out of Hewlett Packard Labs in Bristol. Tom has an MA in Asian Studies and an MBA from the University of Chicago. Previously he was a Political Risk and Financial Analyst, and Sales Manager at Hotsip AB (spun out of Ericsson).

These are the original slides of Tom’s presentation:

Here is the video of the talk (in English):

Feel free to share your comments below.

Posted in IASA Israel, Software Architecture | Tagged , | Leave a comment

Introduction to Event Sourcing

The International Association of Software Architects (IASA) in Israel organized a special event about Adaptive Software Systems. We invited Vladik Khononov to give a talk about “Introduction to Event Sourcing”.

Title: Introduction to Event Sourcing

Abstract: Event sourcing is a pattern for modeling the application’s business logic. It states that all changes to application state should be defined and stored as a sequence of events. Its advantages are many:

  • Gives freedom to refactor the business logic, allowing better response to new requirements.
  • Suitable for building scalable, highly concurrent, distributed systems.
  • Stored events give the true history of a system, which is required by law in some industries.
  • The system’s state can be reversed to any point in the past for retroactive debugging.
  • The required infrastructure is simple – no monstrous databases are involved.

Vladik will also describe CQRS, an architecture that goes hand in hand with Event Sourcing.

Bio: Vladik Khononov is a software engineer with 15 years’ expertise in building web and enterprise applications for leading Israeli and global companies. Currently he serves as a solutions architect for Plexop, an Israeli-based startup company, where he specializes in Domain-Driven Design, CQRS/ES, and design of scalable, fault tolerant, distributed systems.

These are the original slides of Vladik’s presentation:

Here is the video of the talk (in Hebrew):

Feel free to share your comments below.

Posted in IASA Israel, Software Architecture | Tagged , | Leave a comment

Antifragile Software Design

The International Association of Software Architects (IASA) in Israel organized a special event about Adaptive Software Systems. I was glad to be invited to give a talk about “Antifragile Software Design”.

Title: Antifragile Software Design

Abstract: The concept of Antifragility was introduced by Nassim Taleb to describe systems that benefit from impacts and volatility.

In this talk we will discuss how this concept may be applied in the field of Software Design with the goal of developing Change-Resilient Systems.

In particular we will address two patterns which frequently appear in Antifragile systems:

1) The Barbell Strategy and the importance of the separation between high-level abstract elements and concrete implementation details.

2) The Componentization Strategy and its applications in SOA, Microservices and Software Product Lines.

Bio: Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Predictive Analytics Expert at Pontis. He is also a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems and Genetic Algorithms.

These are the original slides of Hayim’s presentation:

Here is the video of the talk (in Hebrew):

Please see here my previous posts on Antifragility and Software Design.

Feel free to share your comments below.

Posted in Adaptable Design, Antifragility, IASA Israel, Software Architecture, Software Evolution | Tagged , , , , | Leave a comment

Manifesto for Adaptable Software Development

We believe that the activities in the left are required to face the challenges of modern software development.

Experimentation instead of Specification
Evolution instead of Implementation
Adaptation instead of Modification
Extension instead of Growth

Perhaps the activities in the right were once good enough, but they are not adequate to the new reality of building complex software systems.

Experimentation instead of Specification

Traditional software development focuses on the detailed specification of system requirements, functional and non-functional. Modern software development should allow the discovery of requirements through experimentation. For example, a Lean approach allows us to build a Minimum Viable Product (MVP) while delaying decisions until the Last Responsible Moment. Sound engineering practices are necessary to build flexible software platforms to support cost-effective experimentation.

Evolution instead of Implementation

Traditional software development focuses on the prioritized implementation of features according to the specified requirements. Modern software development should allow the constant evolution of the system’s functionality to meet the dynamically varying customer needs. For example, Domain Modeling allows us to capture the essential aspects of an application while enabling future specializations. Domain knowledge is necessary to define the central entities and relationships that will remain stable during the system’s evolution.

Adaptation instead of Modification

In traditional software development, code must be modified in order to meet changing requirements. Modern software development should allow the existing code base to be easily adapted to satisfy any change in requirements. For example, Frameworks allow us to have several alternative components that may be chosen according to current needs. The design of a good Framework should be such to eliminate completely the dependency on concrete components.

Extension instead of Growth

In traditional software development, the system must grow in order to accommodate additional requirements. Modern software development should allow the easy extension of the system’s functionality through modular features. For example, Plug-ins allow us to add new features to an existing application without increasing its size and complexity. The design of a good Plug-in should be such that does not expose details about the system being extended nor the Plug-in extending it.

Do you agree? Please share your comments below.

Posted in Adaptable Design, Agile, Lean Development, Software Architecture, Software Evolution | Tagged , , , , | 3 Comments

To document or not to document? An exploratory study on developers’ motivation to document code

caise_2015Last week at Stockholm, Sweden, at the Conference on Advanced Information Systems Engineering (CAISE’15), my colleague Yulia Shmerlin presented our paper at the Workshop on Cognitive Aspects of Information Systems Engineering (COGNISE). This is joint work with Prof. Irit Hadar and Prof. Doron Kliger from the University of Haifa, and is a sequel to our previous paper on Documentation Debt that was published last year.

Title: To document or not to document? An exploratory study on developers’ motivation to document code

Abstract: Technical debt represents the situation in a project where developers accept compromises in one dimension of a system in order to meet urgent demands in other dimensions. These compromises incur a “debt”, on which “interest” has to be paid to maintain the long-term health of the project. One of the elements of technical debt is documentation debt due to under-documentation of the evolving system. In this exploratory study, our goal is to examine the different aspects of developers’ motivation to document code. Specifically, we aim to identify the motivating and hindering aspects of documentation as perceived by the developers. The motivating aspects of code documenting we find include improving code comprehensibility, order, and quality. The hindering aspects include developers’ perception of documenting as a tedious, difficult, and time consuming task that interrupts the coding process. These findings may serve as a basis for developing guidelines toward improving documentation practices and encouraging developers to document their code thus reducing documentation debt.

You can freely download the paper.

Below are the slides of our presentation at the workshop:

Please share your comments below.

Posted in Psychology of Programming, Research, Technical Debt | Tagged , , | Leave a comment

The SOLID Principles Illustrated by Design Patterns

The Clean Code Alliance in Israel organized a special event about the SOLID Principles of Object-Oriented Design. I was glad to be invited to give a talk about “The SOLID Principles Illustrated by Design Patterns”. My friend Eyal Golan also gave a very nice talk about the Single Responsibility Principle.

Title: The SOLID Principles Illustrated by Design Patterns

Abstract: The goal of the SOLID design principles is to improve the Separation of Concerns, through weaker Coupling and stronger Cohesion. The main consequence should be software systems that are easier to maintain and to extend. However the definition of the SOLID principles is quite abstract, and some developers find it difficult to apply them in practice. In my talk I will show how well-known Design Patterns illustrate the application of the SOLID principles, and also show examples of how to follow these principles to Refactor and improve existing designs.

Bio:  Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Predictive Analytics Expert at Pontis. He is also a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems and Genetic Algorithms.

These are the original slides of Hayim’s presentation:

Here is the video of the talk (in Hebrew):

I would like to thank Boris Modylevsky and Itzik Saban for the organization of this event.

Feel free to share your comments below. Thanks!

Posted in Design Patterns, OOD, Software Architecture | Tagged , , | 5 Comments