Juval Lowy

Author
+ Follow
since Mar 18, 2020
Merit badge: grant badges
Biography
Juval Lowy is the founder of IDesign and a master software architect. Over the past 20 years, Juval has led the industry in architecture and project design with some of his ideas such as microservices serving as the foundation of software design and development. Juval has helped countless companies deliver quality software on schedule and on budget and has mentored hundreds of architects across the globe, sharing his insights, techniques, and breakthroughs, in architecture, project design, development process, and technology. Juval participated in the Microsoft internal strategic design reviews and is a frequent speaker at the major international software development conferences. Juval published several bestsellers, and his recent book is Righting Software (Addison-Wesley, 2019). Juval conducts Master Classes around the world, teaching thousands of professionals the skills required of modern software architects and how to take an active role in design, process, and technology. Microsoft recognized Juval as a Software Legend as one of the world's top experts and industry leaders.
For More
Bay Area, California
Cows and Likes
Cows
Total received
10
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Juval Lowy

OK, let's start small – what is the purpose of using properties? To encapsulate the potential change in the business logic or requirements of a piece of data.
Otherwise, when the logic would change, all those that touched the data would have to change.
So the lesson is that when something changes, you better encapsulate it, or you would create dangerous level of coupling. You want to be decoupled from the data.
Does it mean that there is no conditional logic in the rest of the software?

The same is true with architecture. You want to decouple from the possible changes in the requirements, and the only way to do that is to encapsulate the changes in the requirements.
I call that volatility. If you were to use functional decomposition, then when the required functionality changes, your design will have to change, which is exactly the opposite of what I propose.
You must not have a change in the requirements invalidate the architecture.
Does it mean that there is no conditional logic in the rest of the software? Of course not. You still must use if-else, switch, etc. to handle variability in the state or data, but that is not volatility in the requirements.

Juval.
3 years ago
While DRI and SRP are good ideas, they are secondary if not tertiary to the main idea of encapsulating change.
As you will see in Chapter 3, where the book offers structure and guidelines, a single component could even encapsulate multiple volatilities.
So the dominant idea, the main added value is the encapsulation, not the singularity of it.
What you are missing in the picture is the role of components, a governing taxonomy.
I hope that once you read Chapter 3 (and Chapter 4) it will become clear.
3 years ago
Yes, of course you can work correctly. But for the most part, the industry is not, hence Righting Software.
Most systems do not have good regression testing, or not at all, but still have unit testing, for the reasons I wrote in the book.

Juval.
3 years ago
Announce that you are doing a design contest.
Split them into two groups, in separate rooms.
Visit each, and give them their tasks. To the first you say produce the best, to the second, the worst.
You never even tell them they worked on different tasks till after you show them that they did the same.

Juval.
3 years ago
I was referring to breathing from the business perspective (business in this case is you as a human being).
There is no added value in breathing , even though it is essential and important.
Companies hire people not because they breath well but because they add value somewhere.
Relationships, success, has nothing to do with the essential task of breathing, but everything with some value you add by doing other things.

Same is true for unit testing. You are not hired because of your unit testing. Ever. You are hired to add value to customers. That means addressing their requirements in an impeccable manner.
Composable design founded on volatility-based decomposition and regression testing is where you add the value.

Juval.
3 years ago
Junilu,

>>how you can convince a group of architects (and their managers) to try the anti-design exercise you describe.
I propose you trick them into it. If you tell them that it is an anti-design effort you will defeat the purpose.
Everyone likes a good contest. That is how you stage it. They do not know that it is to prove a point.

>>it's counterintuitive for people, especially experienced engineers and architects
>>to purposefully and willfully come up with "the worst design possible."
Then why do they produce it all the time?
Try it.
BTW, it is a common practice in other domains, such as cyber security.

>> And what do you do when the designs that both groups come up with don't turn out to be very similar as you said they usually do?
I never had to deal with that case – both groups produced always functional decomposition.
If one group does produce a good design that encapsulates the volatilities – great! Go for it.

>>This seems like a risky proposition to make, especially if you're a third-party brought in to provide expert advice
Then don't do it. You are driving. I aim to give ideas and tools.
Do whatever you think is best to get them to stop creating more technical debt with functional decomposition.
One option is to just do it correctly yourself, and let the result speak for themselves.

Juval.
3 years ago
Junilu,

Of the various threads you posted today, this one is the most important.
In general, you don't want to just practice, because you may get it wrong and no know it.

To practice correctly, you should do these three things:

*Set specific goals
       Don’t go all over the place. Focus on what you practice now. Avoid going down into the weeds of detailed design and technology.
       Actively look for opportunities to concentrate, to improve, to further your learning.  

*Obtaining immediate feedback
        Is it working? Attack it. See how it handles change. View the guidelines from Chapter 3 on structure, and from Appendix C to see that you have not violated any of the directives and guidelines.
        Share your work with like-minded peers and have them critic it.

*Concentrate on technique as much as outcome
       Design all types of things, not just the current project, to become really good at volatility-based decomposition.
       Learn to do it both efficiently (quickly) and effectively (correctly).


Juval.  
3 years ago
Junilu,

The nature of the universe prevents functional decomposition from ever working (there is no free lunch).
As the book explains, domain decomposition is still functional decomposition, but in disguise.
Therefore, by the nature of the universe, domain decomposition is precluded from ever working, as is evident with the monstrous balls of mud it often leave in its wake.

The only case where common domain decomposition can work is if the business domains map to areas of volatility, but that is just not the way most businesses are structured.

Interestingly enough, if you were to do non-business domain decomposition, that often is a good start.
For example, a domain decomposition of myself would include author, speaker, architect, father, husband, etc.
That will create a ball of mud, with all the internals and the external interactions between the endless domains, and I suspect you have seen that.
But a non-business domain decomposition of me would include the nervous system, the cardio-vascular system, the skeleton, the urinary tack, the digestive track, etc.
But these are also my areas of volatilities, and I preform the required business activities by integrating it all (see Chapter 4 on Composable Design).  

Juval.  
3 years ago
Junilu,

I am not against unit testing. As you have stated, I consider them absolutely essential.
But essential does not mean it adds value. It could even be essential and important, but still not add much value. Brushing teeth in the morning is essential. But you do not take too much pride in doing that task?
Breathing is essential and important, but where is the added value?
Some activities you just take for granted that they are done, and done well, and you focus on activities that add value.

Even if all components passed unit testing 100% it means nothing to the quality and correctness of the system.
The book explains why unit testing cannot really test a system (the defects are in-between the components), and why developers focus on unit testing, because it is the only kind of testing that is possible in a functionally-decomposed system (searching under the street light).
If you have a giant ball of mud (the result of functional decomposition), then unit testing is the only practically possible testing, so developers focus on that, instead of what they should have tested but cannot.
This does not mean you should not test your units. There is no contradiction. Unit testing is essential, must be done, and also borderline useless (passing it means nothing).

Juval.
3 years ago
Márcio,

The core use cases are part of having composable design, where the decomposition (the making of the architecture) does not change, while the use cases change all the time (more in Chapter 4).
All businesses always have core use cases, and as the book explains, the core use cases represent the essence of the business. As such the core use cases do not change (unless the nature of the business changes which is both infrequent and unlikely).
Nowhere in the book did I say it is easy to find. Sometimes, people do not understand their own business.
To find the core use cases you must understand the business. Note, I am referring to the business, not to the domain-specific details. For example, life insurance companies likely have the same core use cases, but the details of how they go about it (like calculating the risk) could be very different. As such you do not have to be fully involved in every details. What you must have is a keen nose for business. That is the best way to make it easier.

The duration of the project is immaterial. All commercial software systems address some business need. As such there are always some core use cases to the business.

Juval.  
3 years ago
Sathya,

Most people are doing Agile, but are not agile (the word, not the process).
Merely going through the motions, the rituals, gives you nothing.
As you will read in Chapter 4, the essence of agility is the ability to respond quickly to changes in the business.
That is what I mean by being agile.
Most systems (with or without Agile) rely of some flavor of domain decomposing, as a result, the changes are by definition not in one place.
This means that when there is a change to the business, the changes are slow, painful, and expensive.
By encapsulating the volatile areas you contain the changes, which allows you to BE agile.
Whether or not you go through the Agile motions is irrelevant.

Juval.  
3 years ago
Hi All,

Great to be here, and ask away!

Thanks,

Juval.

http://informit.com/coderanch/lowy
3 years ago