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, IASA Israel, Software Architecture | 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, Software Architecture, Refactoring, IASA Israel | 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

Conference Talk: Tomer Peretz on “Ensuring Software Alignment”

poster14Last week at the Twentieth International Conference of the Israel Society for Quality in Tel-Aviv, Tomer Peretz gave a talk about “Ensuring Software Alignment”.

Title: Ensuring Software Alignment

Abstract: 

Knowing where to allocate the project resources is the one of the key factors for a good product. One may spend a lot of resources on creating a quality product and an efficient development process, but if the end user don’t use your product in the way you expected him or don’t use the functionality you invested in, all your efforts are in vain. Software alignment to end user needs and to the organization business values is one of the software measurements that are significant to understand how to use the development resources more effectively. Collecting, prioritizing and managing quality attributes is just the first step for creating the “right” software, but sometimes those quality attributes are based on assumptions that turn out as false assumptions. Validating those assumptions in early stages of the project can be critical to the project success. However this is not an easy task. Lately, more and more companies understand that understanding customer needs and validating assumptions that the requirements are based on is not entirely a marketing task but also a development task. The ability to measure alignment with the customer needs and to do it with techniques similar to the ones used today to measure other performance factors, has introduce customer alignment as measurement that help reduce waste and to create more efficient development process.

Bio: In the last 14 years Tomer Peretz played different roles of developing, managing and mentoring at Orbotech. In his current role as a chief software architect he leads the company software architecture group. Tomer also serves as presidency member at ILTAM (The Israeli Users’ Association of Advanced Technologies in Hi-Tec Integrated Systems). Tomer has B.A and M.Sc (with honors) in Computer Science.

These are the original slides of Tomer’s presentation:

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

This session 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, Requirements Specification, Software Architecture, Software Quality | Tagged , , , | Leave a comment

Conference Talk: Dr. Amir Tomer on “Extracting Quality Scenarios from Functional Scenarios”

poster14This week at the Twentieth International Conference of the Israel Society for Quality in Tel-Aviv, Dr. Amir Tomer gave a talk about “Extracting Quality Scenarios from Functional Scenarios”.

Title: Extracting Quality Scenarios from Functional Scenarios

Abstract: 

Requirements specifications usually focus on the functional requirements of the system, whereas the non-functional requirements (aka Quality Attributes) are defined generally, vaguely or tacitly. This talk introduces an approach to reveal quality attributes within structured functional scenarios (in Use-Case specifications) and defining them as quality scenarios which then are added to the overall system functionality. The expansion of the scenarios also provides a basis for adapting the software architecture to the entire system requirements.

Bio: Dr. Amir Tomer obtained his B.Sc. and M.Sc. in Computer Science from the Technion, and his Ph.D. in Computing from Imperial College, London. Between 1982 and 2009 Amir was employed at RAFAEL as software developer, software manager, systems engineer and Corporate Director of Software and Systems Engineering Processes. Amir is currently affiliated as the head of the Software Engineering department at Kinneret Academic College and as a Senior Teaching Fellow for Software and Systems Engineering at the Technion, Haifa, Israel and other academic institutes. Amir has various professional certifications, including PMP, CSEP and CSQE.

These are the original slides of Amir’s presentation:

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

This session 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, Requirements Specification, Software Architecture, Software Quality | Tagged , , , | Leave a comment

Conference Talk – Hayim Makabee on Software Quality Attributes

poster14This week I participated in the Twentieth International Conference of the Israel Society for Quality in Tel-Aviv, giving a talk about “Software Quality Attributes”.

Title: Software Quality Attributes

Abstract: 

The quality of software systems may be expressed as a collection of Software Quality Attributes. When the system requirements are defined, it is essential also to define what is expected regarding these quality attributes, since these expectations will guide the planning of the system architecture and design.

Software quality attributes may be classified into two main categories: static and dynamic. Static quality attributes are the ones that reflect the system’s structure and organization. Examples of static attributes are coupling, cohesion, complexity, maintainability and extensibility. Dynamic attributes are the ones that reflect the behavior of the system during its execution. Examples of dynamic attributes are memory usage, latency, throughput, scalability, robustness and fault-tolerance.

Following the definitions of expectations regarding the quality attributes, it is essential to devise ways to measure them and verify that the implemented system satisfies the requirements. Some static attributes may be measured through static code analysis tools, while others require effective design and code reviews. The measuring and verification of dynamic attributes requires the usage of special non-functional testing tools such as profilers and simulators.

In this talk I will discuss the main Software Quality attributes, both static and dynamic, examples of requirements, and practical guidelines on how to measure and verify these attributes.

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 session 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, Programming, Requirements Specification, Software Architecture, Software Quality | Tagged , , , , | 1 Comment

The Minimum Viable Product and Incremental Software Development

the-lean-startup-bookThe concept of the Minimum Viable Product (MVP) was popularized by Eric Ries in his bestselling book “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”. According to Ries, the MVP is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The MVP should have the core features which allow it to be deployed to some real customers in order to get initial feedback, but not more.

build-measure-learnThe MVP is used in the context of the “build-measure-learn” feedback loop. From the Lean Startup site: “The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible. Once the MVP is established, a startup can work on tuning the engine. This will involve measurement and learning and must include actionable metrics that can demonstrate cause and effect question.”

Now the question is: What is the right way to build the MVP? Of course we should adopt some form of incremental development, in which the MVP should be concluded after a few initial iterations. Then, the next iterations should be used to add new features based on the conclusions of the “build-measure-learn” feedback loop. Thus it is very important to plan the incremental development process so that it will fit the progress of the feedback loop.

Incremental Software Development

Any approach that divides the software development process in small iterations can be called “incremental.” However, there are several possible ways to build a product incrementally. This was very well illustrated by John Mayo-Smith in his article “Two Ways to Build a Pyramid”.

In this metaphor, the traditional way to build a pyramid is to start with the base and then, with each increment, add a new level on top of the previous one. This is certainly an incremental process, but only after the last iteration we obtain a real pyramid. During all other steps of the process we may have at most an “under-construction” pyramid.

flat_pyramid

An alternative approach is to start with a small pyramid and then use each additional iteration to increase its size. In this case after each step we have a full pyramid, which keeps growing in size incrementally.

growing_pyramid

Of course, if we want to build a MVP as part of the “build-measure-learn” feedback loop, the second approach is the right one. The second approach allows us to have the MVP (small pyramid) very fast, and then have a deployable product with new features (bigger pyramid) after each iteration.

In summary

The Minimum Viable Product should have enough features to collect feedback that will drive the implementation of additional functionality through the “build-measure-learn” loop. The MVP should be built using an incremental approach, which should be planned to have a deployable version after each iteration.

What do you think? Have you used similar approaches at your company? Please share your experience using the comments below.

Posted in Agile, Lean Development, Software Evolution | Tagged , , | Leave a comment