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

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

The Psychology of Agile Software Development

gear_team_420Why is Agile so successful? It is a fact that Agile methods have many enthusiastic practitioners, who are firm believers that the adoption of Agile processes has revolutionized the way they build software systems, making them much more productive and effective as software developers. But this is not only a question of being able to write more code in less time. Software developers are very often enthusiastic about Agile practices, reporting that they are having much more fun when doing their work.

This is a phenomenon that certainly deserves to be investigated: How come people are having so much fun from a set of work processes and techniques mostly related to project management?

The answer is that Agile processes and techniques have a direct influence on cognitive aspects and change the dynamics of teamwork. Thus, it is important to analyze and understand which psychological aspects are being affected. Below is a list of topics that illustrate the effects of Agile on the behavior of programmers in a software development team.

Social Nudges and Burndown Charts

Our behavior is greatly driven by Social Nudges, which are forces that result from our interactions with other people. Agile processes increase the frequency of social interactions among team members, for example through daily stand-up meetings and retrospectives. Agile methods also provide more visibility on the progress and effectiveness of each team member, for example through Burndown and Velocity charts. These Social Nudges together help avoid negative phenomena such as procrastination and enable real self-managed teamwork. Read more.

Illusory Superiority and Pair Programming

Illusory Superiority is a cognitive bias that causes people to overestimate their positive qualities and abilities and to underestimate their negative qualities, relative to others. What is the cure for this illusory feeling of superiority? How can we make the programmers in a team respect each other, and even admire their peers because of the recognition of their experience and skills? The key for respect and recognition is joint work, as close as possible. And in this case the Agile methods provide more opportunities for cooperation than traditional approaches, for example through Pair Programming and daily stand-up meetings. Read more.

The Planning Fallacy and Planning Poker

The Planning Fallacy is a tendency for people and organizations to underestimate how long they will need to complete a task, even when they have experience of similar tasks over-running. In the workplace there are some other reasons for the Planning Fallacy: If the manager is the one doing the estimates, he has an interest to make them hard to achieve. If the worker is the one doing the estimates, he will be ashamed to assign too much time to himself. The methodology of Agile software development has addressed the problem of poor estimates through the concept of the Planning Poker, in which all members of the team participate and contribute. Read more.

TDD, Flow theory and Gamification

According to the Flow theory, a person can only enjoy a task if there is a match between his abilities and the complexity of the task. In traditional testing methodologies there was a mismatch between the ability of software developers and the complexity of the testing task. The consequence is that programmers could not enjoy testing. But TDD changes this picture because it transforms testing in just another type of programming task. Gamification is the use of game design techniques and mechanics to solve problems and engage audiences. TDD uses several game mechanisms, including immediate feedback and measurable progress. Read more.

In summary, understanding the reasons of the success of Agile methods allow us to become a learning organization and adapt Agile processes and techniques to our own particular environment and culture.

Posted in Agile, Psychology of Programming | Tagged , | 5 Comments