IASA Israel Meeting – Dror Helper on TDD as an Approach for Software Design

The International Association of Software Architects (IASA) in Israel organized a special event with the participation of Dror Helper, who talked about the “TDD as an Approach for Software Design”.

Title: Designing with Tests

Abstract: Unit tests are great, they help a developer gain control over his code and catch bugs and regression issues. Test Driven Development is a methodology that uses unit tests but it’s not about writing unit tests – in fact the tests are only a design tool. TDD is a methodology that solves problems in an iterative way, it’s about emergent design that creates a maintainable solution. In this session I’ll talk about common mistakes and misconceptions, how to benefit from TDD and show how to design your code using unit tests.

Bio: Dror Helper is a senior consultant at CodeValue specializing in engineering practices. He has been writing software professionally for more than a decade, during which he has worked for industry giants such as Intel and SAP as well as small start-up companies. Dror has designed and developed software in various fields including video streaming, eCommerce, performance optimization and unit testing tools. His first encounter with agile happened a few years ago while working for Typemock Ltd, since then he has been evangelizing agile wherever he goes — at his work, speaking at conferences and today as a consultant. In his blog (http://blog.drorhelper.com) Dror writes about programming languages, software development tools, unit testing and anything else he finds interesting.

These are the original slides of Dror’s presentation:

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

This meeting was organized with the cooperation of ILTAM and sponsored by SAP Labs Israel. Special thanks to Dima Khalatov who helped with the organization.

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, TDD | Tagged , , | Leave a comment

Contextual Recommendations in Multi-User Devices

yahoo_labsMy last project at Yahoo! Labs was focused on Recommender Systems for TV shows. In the presentation below, Ronny Lempel (who was my manager at this project) discusses the challenges of producing personalized recommendations in multi-user devices. This is joint work with my colleagues Raz Nissim, Michal Aharon, Eshcar Hillel and Amit Kagian.

Abstract: Recommendation technology is often applied on experiences consumed through a personal device such as a smartphone or a laptop, or through personal accounts such as one’s social network account. However, in other cases, recommendation technology is applied in settings where multiple users share the application or device. Examples include game consoles or high end smart TVs in household livingrooms, family accounts in VOD subscription services, and shared desktops in homes. These multi-user cases represent a challenge to recommender systems, as recommendations exposed to one user may actually be more suitable for another user.

This talk tackles the shared device recommendation problem by applying context to implicitly disambiguate the user (or users) that are being recommended to. Specifically, we address the household smart-TV situation and introduce the WatchItNext problem, which — given a device — taps the currently watched show as well as the time of day as context for recommending what to watch next. Implicitly, the context serves to disambiguate the current viewers of the device and enables the algorithm to recommend significantly more relevant watching options than those output by state-of-the-art non-contextual recommenders. Our experiments, which processed 4-months long viewing histories of over 350,000 devices, validate the importance and effectiveness of contextual recommendation in shared device settings.

The presentation slides are available for download here.

Feel free to share your comments below. Thanks!

Posted in Data Mining, Recommender Systems, Research, Yahoo! | Tagged , , , | Leave a comment

IASA Israel Meeting – Lior Israel on TDD as an Approach for Software Design

The International Association of Software Architects (IASA) in Israel organized a special event with the participation of Lior Israel, who talked about the “TDD as an Approach for Software Design”.

Title: Providing Business Value Through TDD

Abstract: Our goal is to provide to our customers business value. In my daily work as an architect I show how to provide business value with quality in short feedback time. One of the best ways to provide business value is TDD, and this means adopting TDD for all the game player’s not only for developers! The presentation will be based on code examples. Outline:
– TDD overview as way of thinking – I am going to demo the simple truth: TDD is NOT unit testing.
– Let’s start coding code Kata – The best way to understand it is through a real example.
– Stop! Are we going to meet the DoD? We are going to see that TDD lead us to verify that we understand the business value not at the end of development but at the beginning.
– Architecture & TDD – demonstrate that TDD puts us on the right side of the sun (Architecture). We only need to do it as TDD way.

Bio: Lior Israel is an experienced software and hardware developer, designer and System Architect. Lior started his studies of Electronics in the early 1990’s and has a degree in Computer Sciences. He has a practical formal experience of over 19 years with software and hardware development and design. Currently working as a Software Architect on large scale IT applications with cutting edge technologies. Lior has a blog in which he writes about software development: http://blogs.microsoft.co.il/lior_israel/

These are the original slides of Lior’s presentation:

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

This meeting was organized with the cooperation of ILTAM and sponsored by SAP Labs Israel. Special thanks to Dima Khalatov who helped with the organization.

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, TDD | Tagged , , | Leave a comment

IASA Israel Meeting – Hayim Makabee on the Role of the Software Architect

The International Association of Software Architects (IASA) in Israel organized a special event with the participation of Hayim Makabee, who talked 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 four areas of expertise: Design, Domain, Technology and Methodology.
  • The cooperation with stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.

Understanding the expected areas of expertise is essential for the architect to develop his/her professional skills.
Understanding how to cooperate with the diverse stakeholders is essential to improve the architect’s impact and effectiveness.

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 (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. Hayim’s current research interests are Data Mining and Recommender Systems.

These are the original slides of Hayim’s presentation:

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

This meeting 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

Reducing Technical Debt

logo_white_towerLast week I traveled to Thessaloniki to participate in the Conference on Advanced Information Systems Engineering (CAISE’14). I presented a paper at the Workshop on Cognitive Aspects of Information Systems Engineering (COGNISE). This is joint work with Yulia Shmerlin and Prof. Doron Kliger from Haifa University.

Title: Reducing Technical Debt: Using Persuasive Technology for Encouraging Software Developers to Document Code

Abstract: Technical debt is a metaphor for the gap between the current state of a software system and its hypothesized ‘ideal’ state. One of the significant and under-investigated elements of technical debt is documentation debt, which may occur when code is created without supporting internal documentation, such as code comments. Studies have shown that outdated or lacking documentation is a considerable contributor to increased costs of software systems maintenance. The importance of comments is often overlooked by software developers, resulting in a notably slower growth rate of comments compared to the growth rate of code in software projects. This research aims to explore and better understand developers’ reluctance to document code, and accordingly to propose efficient ways of using persuasive technology to encourage programmers to document their code. The results may assist software practitioners and project managers to control and reduce documentation debt.

You can freely download the paper.

Below are the slides of my presentation at the workshop:

Posted in Psychology of Programming, Research, Technical Debt | Tagged , , | 9 Comments

Antifragile Software Design: Abstraction and the Barbell Strategy

AntifragileIn his book “Antifragile: Things That Gain From Disorder”, Nassim Taleb introduces the concept of Antifragility, which is the opposite of Fragility. The main question is how things react to volatility (such as randomness, errors, uncertainty, stressors and time). According to him, there is a Triad – Antifragility, Robustness, and Fragility:

  • Fragile things are exposed to volatility, meaning that volatility is prejudicial to them.
  • Robust things are immune to volatility, meaning that volatility does not affect them.
  • Antifragile things enjoy volatility, meaning that volatility is beneficial to them.

In Taleb’s words:

“Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.”

In order to reduce fragility, Taleb proposes the adoption of a Barbell Strategy:

“Barbell Strategy: A dual strategy, a combination of two extremes, one safe and one speculative, deemed more robust than a ‘monomodal’ strategy.”

In the case of software systems, volatility appears in the form of changes over time. These changes are unavoidable, as expressed in one of the Lehman laws of software evolution:

“Continuing Change — A software system must be continually adapted or it becomes progressively less satisfactory.”

There are two main types of changes that are required in a software system over time:

  • Functional changes: These are changes required to implement new requirements, or to implement modifications in the requirements. These changes have an impact on the system’s behavior and functionality.
  • Non-functional changes: These changes are required to improve the quality of the design. They are normally the result of Refactoring and focus on the reduction of Technical Debt. These changes should not affect the system’s behavior or functionality.

Now that we have identified the sources of volatility (changes) the question is: What is the software equivalent of a Barbell Strategy?

The answer is: Abstraction. Software systems should have a structure and organization based on different levels of abstraction. In this case the duality of the Barbell Strategy is expressed as the separation between high-level abstract elements and concrete implementation details.

  • Abstract elements: Are robust, and should not be easily affected by changes.
  • Concrete implementation details: Are fragile, directly affected by changes.

In other words, software systems should be built in such a way that the volatility (changes) does not affect its structure and organization, preserving the main, high-level abstractions and requiring modifications only on the low-level, concrete implementation details.

Below are several examples of this duality between abstractions and concrete details.

Information Hiding and Encapsulation

Information Hiding was defined by David Parnas as a criterion to decompose a system into modules. According to him: “Every module … is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.”

The mechanism of Encapsulation in Object Oriented Programming (OOP) is a direct application of this principle. When applying encapsulation, the interface of a class is separated from its implementation, and thus the implementation may be changed without affecting the clients of the class. In other words, thanks to encapsulation, the clients of a class become less fragile to changes in its implementation details.

Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) was defined by Bertrand Meyer as: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” In practice, the implementation of the OCP requires the definition of an abstraction that allows a module to be open to extensions, so that each possible extension is a specialization of this abstraction.

strategyFor example, in the Strategy design pattern, the Strategy itself should be defined as an abstract interface that may be implemented by several possible concrete subclasses. Each specific strategy is fragile and may need to be replaced, but the object using the strategy is not fragile, thanks to abstraction from implementation details.

Test-Driven Development (TDD)

In the case of Test-Driven Development (TDD) the fundamental idea is to write the tests before writing the code. This requires the definition of abstract interfaces for the classes being tested, with a well-defined behavior. Since TDD forces developers to thinks in terms of interfaces and behaviors before writing the code, it actually focuses on the early separation between abstractions and concrete implementation details. This allows the code to be easily refactored in the future, because the unit tests would catch any mistake resulting from changes in the implementation. In other words, the unit tests are less fragile to volatility (changes) because they are based on abstractions.

Inheritance Hierarchies and Frameworks

In OOP, an inheritance hierarchy organizes classes according to a generalization-specialization rationale: the classes near the root of the hierarchy should be more abstract than the classes on the leaves of the inheritance tree. Accordingly, the abstract classes should be less fragile than the concrete classes, meaning that they should be less subject to impact caused by volatility, such as changes in the requirements or changes in the implementation details.

In general, Frameworks use inheritance hierarchies to provide reusable code that is not application-specific. Frameworks define abstractions and the relationships among them. It is the responsibility of the software developer to extend the framework, deriving concrete subclasses, and writing the implementation details to satisfy the requirements of his specific application.  These implementation details are obviously fragile, but the framework is not fragile, and may be reused with no changes on many applications.

Conclusions

Software systems are subject to volatility in the form of changing requirements. Concrete implementation details are fragile and directly affected by these changes. In order to reduce the fragility of the system as a whole, it is important to adopt a Barbell Strategy and define these concrete details as the specialization of higher-level abstractions. Proper abstractions should be robust, surviving the impact of changes. Thus, while the details will change over time, the system structure and organization will be preserved because it is based on abstractions.

Please notice that the examples discussed in this post (encapsulation, OCP, TDD, frameworks) mostly increase the robustness of software systems. Thus, in the original Triad we moved away from Fragility towards Robustness, but we still cannot claim we reached true Antifragility. This would require a system that benefits from volatility, or, in our case, that benefits from changes. This will be the subject of a future post.

Posted in Antifragility, OOD, OOP, Software Architecture, TDD | Tagged , , , , | 11 Comments

IASA Israel meeting – Atzmon Hen-Tov on the Adaptive Object Model

The International Association of Software Architects (IASA) in Israel organized a special event with the participation of Atzmon Hen-Tov, who talked about the “Adaptive Object Model”.

Title: Adaptive-Object-Model – Empower your users to evolve the system

Abstract: In this talk Atzmon Hen-Tov will introduce the Adaptive-Object-Model (AOM) architecture style.

Architectures that can dynamically adapt to changing requirement are sometimes called reflective or meta-architectures. We call a particular kind of reflective architecture an Adaptive Object-Model (AOM). An Adaptive Object-Model is a system that represents classes, attributes, relationships, and behavior as metadata.

Users change the metadata (object model) to reflect changes to the domain model. AOM stores its Object-Model in XML files or in a database and interprets it on the fly. Consequently, the object model is adaptive; when the descriptive information for the object model is changed, the system immediately reflects those changes.

“If something is going to vary in a predictable way, store the description of the variation in a database so that it is easy to change” — Ralph Johnson

Bio: Atzmon Hen-Tov is the VP R&D at Pontis, where he leads the development of the company’s Marketing Platform, iCLM™ on top of the ModelTalk AOM engine. Atzmon has led the development of the ModelTalk AOM Engine since its inception and is co-founder of the Ink AOM open-source framework. Atzmon is interested in Model driven software development and other methods for software development industrialization. Contact him at atzmon@ieee.org.

These are the original slides of Atzmon’s presentation:

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

And here is an animated version of the slides at Prezi.

This meeting was organized with the cooperation of ILTAM and sponsored by LivePerson. Special thanks to Dima Khalatov who helped with the organization.

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

Feel free to share your comments below. Thanks!

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