On Software Development and the Book “Applying UML and Patterns”

DISCLAIMER: this is my typical review; it has more arguments on the subject of the book than the information on the book! So, do not pass by!

A standard learning process has an interesting feature. Once we decide to learn something new, we start reading textbooks, attending courses and obtaining new knowledge by all available means. After some time we say “Enough!”, give up education and move on to the practicing what we learned (in the early stages of the theory there are some simple practical problems to solve, but they have no significant value). After that we start using our new knowledge in practice, and after a while it almost completely vanishes from our heads and its place is taken by experience.

So, what do we have? We have the waterfall model of development where in the early stages there is learning, after which the practice begins. And what's the problem? The problem here is similar to the waterfall software development model. Without the proper experience we are simply not able to realize all the charm of sacred knowledge which they are trying to hammer into our heads during learning. We still do not have enough experience to appreciate these advices.

The process of cognition, as well as the process of creating software systems, must be iterative. We learn something new, we use it in practice, and then come back to the "basics" but we look at them quite differently.

The greatest danger that can lie in wait for an experienced professional is confidence in his knowledge, which may very well prove to be one-sided or archaic. In 5-10-15 years of practice we can easily forget the reasons why we do something this way or another. Our experience is often quite one-sided, which leads to serious consequences in, for example, the development of new systems. We are used to working with legacy code, blaming everyone and everything, but as soon as it is possible to do everything from scratch, we fail miserably and begin to repeat the same s#%t code that we ourselves criticized in previous projects. Why is that? Because this s#%t code is the most relevant experience for us and we just don’t know how to do it differently (or maybe we knew, but forgot).

From time to time you need to go back to the basics and try to re-think them according to your current experience. A good textbook can protect you from another typical trap – the love of extremes. People love them very much.

QUOTE
Adaptive planning vs. Predictive planning. High-level planning is still present in agile projects, but low-level planning is present only for one - one and a half iterations forward.

Synchronous code is bad, asynchronous code rules! And we begin to add asyncs and awaits everywhere we can. Patterns are cool, everything else is nonsense! And we start putting dozens of them per page of code. After we get some negative experience, we say: “Patterns are garbage, s#%t code rules”, and we start deleting all the patterns we find. Then we come to the processes and the love of extremes manifests in all its glory: waterfalls are ancient, Agile is great! Now it's official, we can skip planning and just take our keyboard and start coding!

It is evident that there is not enough sanity in each of the examples above.

Agile does not mean a complete lack of planning, it does not mean the absence of architecture, and it does not mean the lack of risk management! All of this is present there. Iterativeness allows you to quickly receive feedback and adjust your course based on it. Synchronous code may be helpful, and proper use of patterns proves useful very quickly. Everything needs a sensible approach.

QUOTE

Iterative methods are much older than many might think. In the late 50’s of the last century in Mercury space program an evolutionary, iterative and incremental development (IID, Iterative Incremental Development) was applied instead of the waterfall model. And in the early 60's in addition to many other projects, the same model was used in the design of the Trident project. The first work that promoted iterative development, as opposed to the waterfall development model, was published in 1968 in Thomas Watson IBM Research Center.

If you go a little deeper into agile development, it still implies several stages, such as Inception, Elaboration, Construction and Transition. But unlike the waterfall model, coding is present at each stage, and the analysis, design and coding go in spiral. The initial iterations are still different from the rest, as they focus more on the most risky issues in terms of understanding the requirements, architecture or implementation.

At the same time, each iteration must still consist of phases of analysis, development, testing and deployment. It is this same process which Bertrand Meyer describes in his book Object-Oriented Design of Software Systems: each iteration is a mini-project, which consists of the stages of analysis, design, implementation, testing and deployment. And now tell me: who in "agile" teams follows this rule? And this is described in a book on agile development!

NOTE

Meyer goes further and proposes to create a separate stage of generalization.

Design is another topic that requires constant mental effort and replenishing of knowledge. There are multiple three-letter abbreviations now: DDD, BDD, TDD, RDD. It feels like you can take any two letters of the Latin alphabet, add D at the end and you will come to one of the known design techniques. But, as in many other things, there is nothing more valuable than good basic knowledge.

QUOTE

Study of requirements and object-oriented analysis are focused on the understanding of what exactly has to be done (do the right thing), i.e. on understanding some of the key objectives and their associated rules and restrictions. And the subsequent design focuses on doing the thing right, i.e. cleverly design solutions that will meet the set requirements.

You can try to remember design patterns as long as you can, or you can understand what lies at their core. This will not only reduce the burden on memory, but will also allow learning new patterns, and, most importantly, applying patterns properly.

About the Book “Applying UML and Patterns”

Of all the fundamental books on design, I still have not seen anything more fundamental than Мeyer’s book. But I must admit that Craig Larman’s "Applying UML and Patterns" is also very good.

It perfectly illustrates the connection of modern development processes with analysis and design, the role of UML (and generally, visual modeling), considers the fundamental design principles; and all this is seasoned with patterns.

The Good

The most valuable thing in the book, IMHO, is a description of the role of more formal processes in an agile development model. Since "agile" is very often associated with "Just start making it, there is no time for thinking”, this book will take you back down to earth. Larman describes very well the timing and ways of making architectural decisions, ways of describing the architectural and design solutions, and many other issues, which are now, for some reason, associated with the old waterfall model.

QUOTE

We use the notion of Low Coupling to assess the existing designs, or to choose between different alternatives: if all other conditions are equal, we should prefer the solution, the coupling of which is minimal.

Another stunning feature of the book is the formalization of the design process. Most developers split the solution to components, and the solutions to sub-components based on intuition. GRASP principles described in the book with the help of a huge number of examples make clear what should be the basis of our solutions.

“Yeah, so in accordance with the Information Expert principle this method should be moved to another class! In this case, the method should be in this class, as it will better match the real world! But in this case, the class must be moved to another layer, since the current decision violates the Model-View Separation Principle”.

The Bad

Larman’s book is very good, but not perfect. The main drawback, from my perspective, is the excessive abundance of diagrams and use cases. It is odd enough to see a hundred UML diagrams in a book and a phrase such as "A good designer comes from his experience, not the tools”. If the tool is not so important, then why is there so much attention devoted to it?

It is also noticeable that the book is a new edition. It is evident that the author has moved from the more formal methods (such as RUP) to agile methods. There are dozens of references to RUP principles in the book that do not give me any good! As a result, some sections have to be read casually, because they are of little use.

So what is the result?

Definitely a MUST READ!

Sergey Teplyakov
Expert in .Net, С++ and Application Architecture