Temporary Solutions: Technical Debt in Pictures

Software developers are constantly told that they should avoid Technical Debt. But very frequently it is difficult to resist the temptation. Why not implement a good-enough temporary solution that satisfies all the functional requirements? The main problem is that very often this solution ignores completely the non-functional requirements. It is not efficient, nor robust, nor maintainable, nor scalable. I think this problem may be very nicely illustrated with the pictures below.

Car Dashboard1) Functional requirement:

The dashboard must have a knob to control the air-conditioning.




car window cleaner2) Functional requirement:

The back-window must have a wiper.




lock3) Functional requirement:

The door must have a lock.




mirror4) Functional requirement:

The car must have a side-mirror.





tire5) Functional requirement:

The car must have four tires.

Posted in Requirements Specification, Software Quality, Technical Debt | Tagged , , | 1 Comment

Sharing Some Bits of Wisdom

Sometimes I find some amazing content on the Web which I want to share with all the readers of my blog. The picture below was created by Anna Vital, and I think it presents in a very concise form some amazing bits of wisdom. It reminds us the importance of our attitude when dealing with challenges. Enjoy!


Posted in Efficacy | Tagged | Leave a comment

Hilarious: the Disasters Caused by Emergent Design in Practice

Several people in the Agile community believe in Emergent Design. But I think that it has caused many disasters in software development projects. See below some hilarious pictures of Emergent Design in practice, with fictional conversations illustrating the kind of thinking that generated them…

stairs1) Commenting-Out

PM: Look, the requirements were changed, we will have to modify these stairs.

Dev: It will be too difficult to modify them, I will simply write new ones.

PM: So will you delete the previous ones?

Dev: No need to delete, I will comment them out, they may be useful in the future.

up and down2) Connecting Modules

PM: You designed the stairs between floors, but you did not design the connection between stairs.

Dev: This should not be a problem, after having the stairs it is very easy to connect between them.



3) Adding New Features

PM: There is a very wide space here, I think we should add some benches.

Dev: No problem, benches are very modular, I can easily plug them here.



flow4) Emergent Design

PM: You have designed the floors, but you did not design the stairs connecting them.

Dev: Don’t worry, after we have the floors it is very easy to add the stairs.





angular5) Partial Requirements

PM: Sincerely, I am not sure that the system you implemented is what the customer expected…

Dev: You can check the requirements, our system satisfies perfectly all the customer requirements.





responsive6) Choosing a Platform

PM: Ideally this system should be built on top of a land-based platform.

Dev: Land is too expensive, I suggest we use old tires instead.

PM: Are you sure that old tires would be a good technology choice for this project?

Dev: No doubt, old tires are cheap, very modular and can be combined in multiple ways.

interface7) Cross-Cutting Concerns

PM: I see in your design that there is some coupling between the building columns and the passage.

Dev: This should not be a concern, both can perform their function despite this small coupling.

Posted in Agile, Software Architecture | Tagged , | 7 Comments

On Success and Failures

When you see a successful person, it is very easy to say that this person was “lucky”. But real success always comes after multiple failures. And the only real failure is to stop trying before you reach success. We must always keep trying!


After many years working for big corporations, I decided to create my own startup company. KashKlik is an Influencer Marketing platform with a unique pay-per-click model. Our marketplace is fully-functional, has initial revenue and already reaches millions of people globally.

Now it’s time for KashKlik to grow fast and we are looking for private investors. We just started a crowdfunding campaign in which you can participate and become a shareholder. You will find our business plan and lots of additional information here:

Looking forward to having you as a partner at KashKlik!


Posted in Efficacy, KashKlik | Tagged , | Leave a comment

Workshop on Software Architecture for Agile Development

Last month I gave a workshop about Software Architecture for Agile Development, organized by ILTAM. It was very interesting, I was really pleased that the audience was engaged and asked many good questions. These workshops are an opportunity for me to meet other professionals working on different industries and exchange experiences. They are the ones who paid to participate, but I also learned from them.

Summary: This workshop will be dedicated to the topic of Software Architecture in the context of Agile Development. We will answer the question: “How much Design Up Front should be done in an Agile project?” Hayim will present his approach of Adaptable Design Up Front (ADUF), describing its rationale, applications in practice and comparison to other approaches such as Emergent Design. He will explain why adaptability is essential for the development of complex software systems using Agile methods. The concepts will be illustrated through practical software architecture approaches such as micro-services and examples of real software systems that were developed in the past. The workshop will also include an exercise on the definition and evolution of the design of an interesting system.

These are the slides of my workshop:

Below are some pictures of the audience during their exercise:


Posted in Adaptable Design, Agile, Software Architecture, Software Evolution | Tagged , , , | 1 Comment

My first book, published 25 years ago

POOI wrote my first book when I was 20 years old. It was the first book in Portuguese about Object-Oriented Programming (OOP). At the time I was a student at the Federal University of Rio de Janeiro, also known as UFRJ (Universidade Federal do Rio de Janeiro).

You may ask: what makes a young student think that he should write a book? Actually it wasn’t my idea, I was convinced to write it by one of my teachers, professor Paulo Bianchi. At that time I was considered a “pioneer” using OOP on my graduation project, and had a good understanding of the application of object-oriented concepts. Then I had this conversation with my teacher:

My teacher: “I would like you to write a class-book about Object-Oriented-Programming.”

I answered: “I can do that, but this would be lots of work, the same as writing a book.”

My teacher: “You are right. Write a book.”

I still didn’t think that I was able to write a book. So we agreed that I would write the first chapter, then my teacher would review it, and if it was good enough I would write the rest of the book. As you can guess, my teacher really liked the first chapter, made several suggestions for improvements, and then I wrote the additional book chapters.

My book was published in 1992 by a publishing house that specialized in technical books: LTC – Livros Técnicos e Científicos. The book title was “Programação Orientada para Objetos com Turbo Pascal 6.0”. It was published in Brazil and sold also in Portugal. The first edition had 1200 copies, and all of them were sold. You can see the picture of the front-cover above. Note that it was authored under my Brazilian name (Ricardo Szmit), and now I use my Hebrew name.

The first edition had code examples in Turbo Pascal. The publishing house asked me to prepare a second edition using examples in C++. But at that time I was already in Israel, doing my M.Sc. studies at the Technion. I decided that my research was more important than working on a new edition of the book. Also, I already had the feeling that I would never go back to Brazil to enjoy my local reputation as a book author…

Of course I did not make much money from this book, but it was a great experience. I learned to think big, and to never underestimate my own capacity. I hope this serves as an inspiration for young readers of my blog.

Posted in OOP, Programming | Tagged , | 1 Comment

Good Code is Adaptable Code

Some people find the diagram below very funny: it basically says that there is no way to write good code. Of course I do not agree with this. The diagram implies that writing well is a slow process, and that the requirements will have changed before we finish writing our code. I claim that we should write Adaptable Code, so that when the requirements change we will not have to “throw it all out and start over”, as appears in the box in the bottom. In this sense, Good Code is synonymous with Adaptable Code. Now the question is: how do we write Adaptable Code? My answer is: Adaptable Design Up Front, an Agile approach to Software Design.

good code cartoon

Posted in Adaptable Design, Agile, Programming | Tagged , , | 1 Comment