Finding your purpose in life

How to find your purpose in life? The Venn diagram below has appeared several times on the social networks I use. In my opinion it is very interesting and makes me think, so I would like to share it with you and make some personal comments.

purpose

You Love It vs. You Are Great At It

Probably there are many things that we love but that we are not great at. But the opposite is not true: I don’t believe we may be great at something we don’t love. I think that nothing is more effective than enthusiasm. Thus in the Venn diagram above, all the things we are great at should fall in the intersection with the things we love. I talk more about that in my post about the 10,000 hours rule.

You Are Great At It vs. You Are Paid For It

On the short term we may be paid to do something even if we are not great at it. But on the long term we will only be able to hold a good job if we are great at it. So on the long term there is always an intersection between being great at and being paid for something. Moreover, being great at something is not simply a status we reach and then enjoy. Being really great requires continuous improvement.

You Are Paid For It vs. The World Needs It

I believe that if we are being paid for something it is because the world needs it. Thus all the things we are being paid for fall in the intersection with the things the world needs. Of course there are lots of people working as volunteers on things that the worlds needs. But I also believe that if there is something that the world needs, there will always be someone willing to pay for it.

Conclusion

  1. All the things we are great at fall in the intersection with the things we love.
  2. All the things we are paid for fall in the intersection with the things we are great at.
  3. All the things we are paid for fall in the intersection with the things the world needs.

Thus to find your purpose in life, you just need to find something you love and that the world needs, and then make sure you are great at it. That simple. :)

Posted in Efficacy | Tagged | Leave a comment

IASA IL Workshop: Philippe Kruchten on Managing Technical Debt

pkruchtenThe first activity of IASA Israel in the year of 2015 was a full-day workshop by Prof. Philippe Kruchten on “Managing Technical Debt”. The workshop was highly interactive with many questions from the audience. Prof. Kruchten covered the subject of Technical Debt with depth and details, bringing many relevant references and concrete examples from the industry. By the end of the day, the workshop participants, including me, had a much better understanding of the causes and consequences of Technical Debt, as well as some tools and techniques to manage it.

Title: Managing Technical Debt

Abstract

Technical debt is a metaphor to explain a common phenomenon in software development projects: A design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time).

While the metaphor has gain a lot of success, lately, it is still a rather vague or mysterious concept in many organizations, who are struggling to detect, measure assess, and remedy their technical debt. In this workshop we’ll explore the various facets of technical debt, discover how to characterize it, measure it where possible, and develop strategies for prevention and for remediation.

Presenter Bio

Philippe Kruchten is professor of software engineering at the University of British Columbia in Vancouver, where he retired in 2004 after 30+ years in industry, primarily with Alcatel and Rational Software (now IBM). He developed a software architecture method in the early 1990s, and led the development of the Rational Unified Process from 1996 to 2003. Over the last few years he has led a research effort to better characterize technical debt, in particular intentional, strategic technical debt, at the architectural level. He has organized a series of research workshops on technical debt in Pittsburgh (2010), Honolulu (2012), Zürich (2012) San Francisco (2013), and Victoria (2014), and he has written several papers on the topic, notably with his colleagues at the Software Engineering Institute. He is the co-founder and past chair of Agile Vancouver.

Slides

You can download the slides of a previous presentation.

Motivation

Technical Debt is a metaphor introduced by Ward Cunningham in 1992 to help us think about a problem that is crippling many software endeavours. In his metaphor, doing things the “quick and dirty” way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to dedicate in future development because of this quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor saw little use for many years, but suddenly around 2000 and curiously in parallel with the advent of agile methods (though this may be just coincidental), it met quite some success, especially in the blogosphere and in many software gurus’ sermons. And the phrase started to be used to label all kinds of software ills. Since 2010 it became the subject of more scrutiny and researchers have attempted to better understand the concept, define it, measure it, assess its impact, and propose tools and methods to manage it.

A more recent definition of technical debt which seems to aptly convey the current consensus is given by Steve McConnell: “A design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time).”

While the phrase ‘technical debt’ is used a lot now in industry, is it really a useful concept, that can lead to improvements, or at least a better understanding, of the way we develop software? It is probably a useful rhetorical concept, as pointed out by many to start a dialogue between business people and technical people about schedule pressure, architecture, poor internal quality, release planning. But it is hard to go beyond the rhetoric and get to the point where it leads to actionable, objective, concrete facts, data, techniques or even tools.

One of the issues is that the metaphor has been applied loosely to a vast range of issues or concept, and that the metaphor, like any good metaphor, has its limits and we should understand what these limits are: technical debt in software development is not literally a financial debt, like a mortgage. “…there is a plethora of attention-grabbing pronouncements in cyberspace that have not been evaluated before they were published, often reflecting the authors’ guesses and experience on the subject of Technical Debt.”

This being said, the metaphor proved to be useful, and large organizations have explicitly introduced it in some form of another in their software development process, as a something to identify, value, and take into consideration while planning iterations and releases; one such example is Cisco in Ireland.

This workshop was organized in cooperation with ILTAM. Please share your comments below.

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

Helping new immigrants to find a job in Israel

gvahimThis month I had the pleasure to give a talk to a group of young new immigrants. Immigration to Israel is called Aliyah, and the new immigrants are called Olim. I am a volunteer at the Gvahim organization which has the goal of helping new Olim. In particular, Gvahim helps highly-qualified young people with academic background and relevant professional experience. One of the main challenges for these new immigrants is to find an appropriate job in Israel, because most of them have only basic Hebrew skills.

The participants in my talk were mostly from the IT and software development field. I tried to give them some concrete and practical advice on how to find a good job in Israel. I also discussed some possible approaches to making connections in the Israeli software industry. Finally, I emphasized the importance of having realistic expectations. You may see the slides of my presentation below.

If you are a young professional considering Aliyah, you should contact Gvahim. Please feel free to leave your comments below.

Posted in Israel | Tagged | Leave a comment

Conference Talk: Hayim Makabee on the Role of the Software Architect

sw-arch-2014-headerDuring the First Israeli Conference on Software Architecture, Hayim Makabee gave a talk about “The Role of the Software Architect”.

Title: The Role of the Software Architect

Abstract: In this talk Hayim will present the practical aspects of the role of the Software Architect, including the architect’s contribution at the diverse stages of the software development life cycle, and the cooperation with the diverse stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.

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 Research Engineer at Yahoo! Labs Haifa. He is also a co-founder of the International Association of Software Architects in Israel.

These are the original slides of Hayim’s presentation:

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

The conference was organized with the cooperation of ILTAM.

To participate in our future meetings, please join the IASA IL group on LinkedIn.

Feel free to share your comments below. Thanks!

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

Conference Talk: Dani Mannes on Agile Software Architecture

sw-arch-2014-headerDuring the First Israeli Conference on Software Architecture, Dani Mannes gave a talk about “Agile Software Architecture”.

Title: Agile Software Architecture

Abstract: It is still very common to use different techniques and processes at the system engineering and at the software engineering level. In this lecture I will present a unified Agile process and techniques that allow for a seamless transition from the system engineering level to the software engineering level in an iterative and evolutionary way. I will also show the benefits the unifying the processes of the two levels and of the resulting component based architecture. I will also talk on the architect’s role and this role evolves over time and will conclude with presenting a small but real life project example.

Bio: Dani Mannes is an active partner of ACTL Systems Ltd. For over 25 years he trains and coaches companies in adopting object oriented software and system engineering practices with a very strong focus on agile architecture engineering.

Over the years he has participated in well over 100 projects spanning domains of medical, aviation, biotechnology, computer vision, government, defense industry and more. Over the last 10 years he focuses on pattern driven and agile architecture model at the software as well as at the system and system of system level.

These are the original slides of Dani’s presentation:

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

The conference was organized with the cooperation of ILTAM.

To participate in our future meetings, please join the IASA IL group on LinkedIn.

Feel free to share your comments below. Thanks!

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

Conference Talk: Joseph Yoder on “Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work”

sw-arch-2014-headerDuring the First Israeli Conference on Software Architecture, our invited keynote speaker Joseph Yoder gave a talk about “Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work”.

Title: Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work

Abstract: This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. Additionally, I’ll talk about some practices and patterns that help keep the architecture/code clean or from getting muddier.

These are the original slides of Joe’s presentation:

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

Description: Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.

This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.

Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.

Bio: Joseph Yoder is a founder and principle of The Refactory, Inc. and Teams that Innovate, companies focused on software architecture, design, implementation, consulting and mentoring on all facets of software development.

Joseph is an international speaker and pattern author and longstanding member of The Hillside Group, a group dedicated to improving the quality of software development. He is coauthor of the Big Ball of Mud pattern, which illuminates many fallacies in the approach to software architecture.

Joseph has chaired the Pattern Languages of Programming Conference (PLoP), as well as presented tutorials and talks at various international conferences. Joe teaches Agile Methods, Architecture, Design Patterns, Object Design, Refactoring, and Testing in industrial settings and mentors many developers on these concepts.

Joe currently resides in Urbana, Illinois where he had led teams of developers who have constructed systems based on enterprise architecture; specifically adaptable architecture. Projects involve working in various environments such as Ruby, Java, and .NET deploying Domain-Specific Languages for clients.

Joe thinks software is still too hard to change. He wants do something about this and believes that putting the ability to change software into the hands of the people with the domain knowledge seems to be one promising avenue toward solving this problem.

The conference was organized with the cooperation of ILTAM.

To participate in our future meetings, please join the IASA IL group on LinkedIn.

Feel free to share your comments below. Thanks!

Posted in Agile, IASA Israel, Refactoring, Software Architecture | Tagged , , , | 1 Comment

Conference Talk: Lior Bar-On on “The Five Expertise Areas of an Architect”

sw-arch-2014-headerDuring the First Israeli Conference on Software Architecture, Lior Bar-On gave a talk about “The Five Expertise Areas of an Architect”.

Title: The Five Expertise Areas of an Architect

Abstract: Architect is an ambiguous role, for an ambiguous craftsmanship. Over the years I’ve participated a number of discussions, and even complete workshops, asking “What is an Architect?” or “What is the Architect’s Role?”. With time, I’ve built myself a simple “model” that explains what an Architect is – and in the session I will share the insights I have.

Bio: Lior is a Senior Development Architect at SAP, working with developers, product, UX, operations and all other relevant parties that are needed in order to create great software. Previously Lior was also a System Architect at Imperva, a Product Owner from time to time, and a developer in C# (rich client), C (Kernel), Java (Server) and JavaScript (Web/Mobile). Lior is also the author of a blog on Software Architecture, the “Software Archiblog” (in Hebrew).

These are the original slides of Lior’s presentation:

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

The conference was organized with the cooperation of ILTAM.

To participate in our future meetings, please join the IASA IL group on LinkedIn.

Feel free to share your comments below. Thanks!

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