Fearless Change: Book Review

The Book


Fearless Change by Mary Lynn Manns and Linda Rising.


The Review

Heard about the new book quite a long time ago (December last year) when I saw the excellent InfoQ interview Linda Rising on "Fearless Change" Patterns.

Eventually the book became the best birthday present I have received in years! Thanks ;)

What did I want to learn?

I was intrigued by the handful of patterns for introducing New Ideas that were presented in the interview and I wanted to find out more. More patterns and more about each pattern.

I knew from the first minutes of the interview that the book presents solid, good quality material in an area of interest to me: Improvement.

I also recognized a number of patterns I have applied without knowing that they do exist (They are only Patterns, theee!). I wanted to find out what I already know from Linda and Marry Lynn's pattern language.

What did I learn?

1. A set of words.

When I finished the book, the pattern names were the first thing I remembered. Words describing situations in which I have been before, and unexplored situations I might encounter.

I know that what I will carry with me from now on will be the words (names of the patterns).

Like with any other pattern language I'm sure I'll remember it's words on hard, stressful situations. I'm already creating sentences, and I hope in the near future, I'll be better understood by others.

2. More about people, their expectations , reasons, powers and reactions.

More about Innovators, Connectors, Early Majority, Gurus and Generals and about the important roles they may play when a new Idea is tried to be introduced.

3. More about change.

A very important aspect that changed my perspective about my current job role expectations: you don't have to be named manager in order to lead! It's true, I lead teams form the shadow for as long as I remember, hoping that a job role will provide greater authority it's partly a false expectation! (Changes cannot be dictated)

4. More about what I've done.

Maybe like you, I have applied a lot of patterns in a variety of contexts. As described in the book, the patterns are not new, they might be seen as common sense, the only problem is that the common sense is "so uncommon" nowadays!

Anyway, there is a difference between applying unconsciously and applying consciously: I feel now details I wasn't aware of, I explain a lot of reactions, I'm more confident in what I'm doing, ..

5. More about what I haven't done. I have the feeling that I could have done more if I were aware of patterns like Guru on your side, Whisper in the General’s Ear, Personal Space, Token, Sustained Momentum, .... I see now how the list get's growing!


In Summary

For me, the book is a foundation stone in a domain doomed to always be on actuality. It's a result of many years of work and ... it really helps!

The book itself it's a new Idea in which I strongly believe. An Ideea I'm already introducing in my working environment: my colleague is reading it right now, and a third one is on the waiting list!

In a future post I hope I will be able to demo the pattern language in a nice Hometown Story, meet you there!

Second-class Citizens

I hear a lot recently that Test Code should not be treated as Second-class Citizen, that it is important, that is more important than the production code itself since it grows our confidence that we can re-work any piece of functionality without disastrous result in validation, etc.

Everybody seems now to know about the topic, although not everybody, not always tries to put the idea into practice: refactor test suites, use patterns when building them, create them when appropriate, make them robust, easy to extend, make them most suited for testing the current application, etc.

In my working experience I see a lot of other, not commonly known, hidden, Second-class Citizens.

I see: huge build files , production code labeled as "GUI" or "View" or "DB" part that is left to slowly rotten, javascript files, css files, xsl files, xml files, html files, resource files, etc. I can tell you for sure that all this buddies have one thing in common: toghether will affect every quality aspect appliable to your product!

Grow the monsters and you'll find yourself in big trouble. Sometimes you'll say: no, we can't do that, the "delete" feature breaks all our architecture, sometimes you'll just notice that every screen in your app looks different, sometimes you'll notice that any fix you perform, generates 3 more bugs!

Agile Software Development with Scrum: Book Review

The Book


Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.


The Review

As part of the efforts to keep our projects on the right track, our teams are trying to apply Scrum. As a result, this book was bought by my manager as an alternative to a Scrum training that could not be taken in Timisoara.

After some research of his own on various books on the Scrum topic, he decided that this book practically is the foundation of Scrum and the first book that must be read on the topic.

It was a very wise decision. I'm also against 2-3 days trainings with no-name topic experts: they can only provide an initial image, for an in depth study of a topic, books and lots of research are needed. After reading it, I must say the book is a perfect starting point on Scrum methodology.

What did I want to learn?

• A confirmation that my view on the Scrum methodology formed from various blogs & articles that I read was right. (I have a lot of experience in XP, RUP, CMMI, PMI - I know a lot about agile and I read a lot of material stating that XP - Scrum - Lean are very much overlapping.)
• How various Scrum practices must be adopted? What do they mean?
• How can Scrum be adopted in our very large and chaotic project?
• Are there any more practices than Sprint Meetings, Daily Meetings, Backlog Burn-down charts and Sprint Retrospectives?

What did I learn?

• Compared to XP, Scrum seems to be more focused on management, control and various forms of organization - If Extreme Programming Explained lists a lot of Engineering practices, this book focuses on process and project management practices.
  
• Understood what is expected in Scrum from the various roles and why.(Scrum Master - removes impediments, takes decisions "any decision is better than no decision", mentor)
• Liked a lot "the art of possible" idea: What can be done in the current (poor) circumstances to reach the sprint's goal. It's not only Scrum master's responsibility to remove impediments, but creativity and adaptability is encouraged to all scrum team members - they must be aware that by themselves can remove impediments.
• Backlogs and Sprints - learned and understood why when adopting Scrum, Scrum practices need to be adopted by the book. Backlog - should be visible to every stakeholder and should contain all identified pieces of work (not only pure programming tasks). Sprints - very important to have a defined goal. Sprints - shelter against the chaotic needs from an application.
• Understood the scientific justification of Scrum practices and learned a lot about defined and empirical processes.
  
• Understood how large(multiple team) projects can be managed efficiently in Scrum.
  
• Scrum values
  

In Summary

The first step of Scrum adoption in any form of organization should be the reading of this book.
The book helped me gain deep understanding on this software development approach as opposed to various blogs & articles I have read which only presented me semantic diffusion.

SmellyRoom

As a software developer I fight "Smells" as much as I can.

I love the term, it's very plastic, intuitive and easily adopted by most of the people. I use it with different meanings: design smells (code that screams for refactoring), software aging smells (deprecated, dead code), testability smells (untestable code, low code coverages), etc..

I first encountered the term in Refactoring - Improving the Design of Existing Code, and I adopted it instantly. When I use the word, I'm understood immediately!

One of these days, I had a discussion with a colleague of mine and we laughed together about a new meaning of the word, or if you wish a new metaphor, old software projects as Smelly Rooms:

As you stay longer in a smelly room, you adapt, you find the air there more breathable. You even start to think there's nothing smelly with the air you bread. Same can happen when living too long in a Smelly Project, you can get used to the design smells, software aging smells, etc. It's possible you'll even start to think you're working on a state of the art piece of software!

The cure for this disease in both cases, smelly rooms and smelly projects: the door. Use the door to see the hallway, to enter other rooms, you'll just know you need to open some windows. Enter doors towards external projects (read books and articles, discover tools, have a look on an open source project, attach sources to external libraries you use and explore them, etc), and you'll just know you need to perform some cleanup to your old project.

Group Reading Writing

During the past year I had the opportunity to experience Group Reading, to continually grow understanding on this agile practice and to contribute to practice’s adoption and refinement in a number of development teams.

Reaching the time of year that is most suited for personal retrospectives (or was, I started this post on December last year!), it is time for me to write down a number of ideas, teachings and best practices discovered by trying to set up and get most of value from this learning technique.

What is it?

Group Reading is an agile learning technique that can be applied by a group of participants by simultaneously reading the same piece of technical text and sharing the individual understandings obtained from that text. The participants should be work related, i.e. parts of a development team or development group and the text should be interesting enough for each team member.

What can I gain from it?

If they are set up correctly and if they are continually subject for improvement, the group reading sessions may provide many benefits for each individual participant and for the team as a whole.

Each person when reading a text has his/her own paths of interest, words that are more appealing, paragraphs that worth more concentration, different reading and learning techniques used voluntary or involuntary (SQ3R, literary reading), performs analogies with past experiences, etc. As a result, when many persons share their understandings obtained from the same text, each person may learn from the others. It is very likely that missed points for one person to be very interesting ideas for another. So, each participant may read more in group than by reading the same text alone.

Other individual benefit for each participant would be the effective learning of the read topics. By discussing ideas and associating them with concrete examples, by putting them into context) ideas may become well sedimented in memory.(Learning by teaching and more).

Appetite for self improvement can also be a result of this practice (Why wait such a long time to finish this reading in group? I can buy and finish the whole book in one or two weeks and I’ll also read more in group reading sessions!). By reading small chunks reading appetite can be awakened, the book used in the group reading may be a start, but other books may follow also.

For the whole group the main benefit of this activity is related to group’s cohesion: common vocabulary and interests for the team members, common goals regarding future development work, growing respect between team members are only some of the aspects.

Good teams are formed over time, partly because team members have individual educational backgrounds and vocabularies, partly because teams need social background and good interactions.

Group reading sessions may help shorten the time needed to create good teams: by constantly adding common words in a team’s vocabulary, shared ideas as new words, the team may gain good communication skills and common concerns; by taking the team members out from their regular work environment, they may forget their working roles and socialize, feel equal, discover that some questions may be answered by someone near, respect each other’s ideas, etc. Yes, group reading is also a form of team building!

Finally but not at the last group reading session may be a small artifact in building a good working environment, where people put passion on what their doing, where auto improvement is constantly demanded.

What is it not?

Group Reading is not following a presentation, is not a discussion on known topic is not watching a technical podcast in a group. Is a simple reading act followed by a discussion and nothing more than that. Keeping it’s sessions simple, finding good subjects, can lead to the benefits listed above. Less is more, twisting and tailoring practice’s scope may not lead to optimal results for the participants.

Group Reading vs. Peer Programming

Peer programming is another agile practice that can lead to rapid teaching and learning and may help forming good teams quicker. My guess is that in many agile teams peer programming is the only training practice in use in the development phase.

This is normal until a certain point. The most appropriate teaching material intended to improve our work as programmers is the code itself, it’s abstractions, external libraries, documentation, design, etc. Having an experienced team member nearby is the best place to look for experience and good practices. During peer programming sessions, knowledge and skills owned by experienced team members may be rapidly shared with the whole team. The only problem here is the degree of knowledge and experience of the experienced team members: maybe different, better knowledge artifacts are recorded in an existing famous book or article or other form of documentation.

So if Martin or Kent or Robert or "you name it" is not yet your peer, maybe his/her recorded ideas could be your partners in group reading sessions!

Organizing Group Reading Sessions

As with any agile practice, the key in organizing effective group reading session is practice adaptation to real context: Just see if it’s appropriate for the team you’re in, try it, see what can be done to get the most value from it!

Over time, for groups I was part of, we discovered a number of points that lead to better group reading results.

In terms of duration we discovered that 30 minutes sessions are enough. 30 minutes sliced in 15 minutes reading, 15 minutes open discussions seemed the optimal amount of time we could stay concentrated on a new topic. We also discovered that almost any reading material can be sliced in cohesive parts that can be read in 15 minutes: 2-3 pages parts.

In terms of planning we discovered that is better to plan a number of subject related group reading sessions. This way the sessions became parts of a larger goal. A goal that can be tracked and addressed iterativelly (see progress monitoring, bellow :) ). Planning also implies priority. By planning 1 session per week we ensured that the whole group recognizes the session as being high priority. We obtained this way a group acknowledged priority.

In terms of participants we discovered that most of the group reading benefits can be obtained in teams of 3-4 persons. Having more than 5 persons in a group reading session tends to increase the open discussion time: every person tries to say it’s view on the read topic, etc. We also discovered that the degree of experience of the participants doesn’t matter too much: experienced developers can learn from beginners, beginners from beginners, etc. In one team I worked for we even played a lottery game to extract group reading session’s participants!

In terms of progress monitoring we discovered that having the planned group readings and their dates on a flip chart, a marker and the possibility to mark them as done, is good for the morale!

Expert Programmer

An expert programmer deletes more lines of code than he writes! :)

Distributed Agile Practices

Finished reading Distributed Agile Development at Microsoft patterns & practices

Excellent paper! Focused on agile development, lists proven practices that led to better development results in various distributed development teams:

• Focus on Communication
• Plan to Travel
  
• Team Distribution
• Focus on Coaching the Team
• Distribution of Work
• Build the Team over Time
• Provide the Right Tools
  

All practices are great (more or less intuitive) Ideas and Ideals , the interesting part are the hints to their efficient set up in practice.

Writing down some of them possibly for future use:

Focus on Communication: plan communication, pair buddy, parking lot system for issues raised during meetings, etc.

Distribution of Work: special attention for asymmetric teams

Focus on coaching: an experienced coach in each of the distributed teams

Iterative Posts

I tried for my first Post to make it as complete as possible before publishing: spell checking, ensuring that the important words have external links, structure, etc.

It may seem natural, a post may virtually have a large number of readers, readers that may know or not the author. The post may become quoted or may be used in a form or another, isn't it?!

For me, trying to reach perfection before publishing something has become very frustrating!

Why? Because I have an agile background. I am an adept of the XP Driving Metaphor, where adapting to real feedback is everything. My designs are stirred by my customers, why not my post to be driven in the same way?!

I decided to go agile even with ideas published in posts, it may work! Even if the real customer will be also me :)

So, this post is a nice first draft to be published! Agree?! :)

A Unit Testing Presentation

I had a couple of days ago a unit testing presentation (see bellow) to my development group. The topic & the short description (Vocabulary, Styles & Toys) lead to a vast audience, almost every developer attended, also managers!

The Goals were simple and some of them classical:

• Share common vocabulary in all extended team (Unit Test, Stub, Mock, Test Double, FIRST)
  
• Grow appetite for Mocks
  
• Grow appetite for further reading
• Show the problems Integration Tests may induce.
  

The goals were reached partially: - at least now, everybody knows what a mock is, everybody knows what stubbing is, everybody knows frameworks "easier" than jMock are available.

Some interesting questions were raised during this presentation:

Are acceptance tests philosophical? How do they integrate in an hypothetical automated tests classification?

If Unit Testing is strictly related to source code, how do we name functional tests written to test in isolation a single GUI element (let's say a table)? Don't we need more words in the testing language puzzle?!

Good OOD Axioms

Every application written in an object oriented programming language has a design.

No design is design, procedural code in one God Class and a myriad of Data Classes is design, the list can grow and grow.

The above mentioned application contains a number of objects (enforced by the language) that collaborate to produce the application's outcome(s). Reverse engineer any application and you will be able to visualize a form of design.

Object Oriented Design from methodology to exact science

OOD has evolved in the last decade from simple methodology and heuristics towards exact science: the science of building good object oriented designs!

Vague expressions like "thinking in terms of objects", "responsibilities & collaborations",
were gradually replaced by more structured approaches:

• Good and Poor designs in terms of implementation and maintenance costs
• well structured books & trainings
• principles and laws
  
• patterns
• tools that can aid a design process
  

I'm not only discussing waterfallish design, but also agile design.

Axioms

Time & practice lead to well structured information about Good Designs.
Similar to an exact science, OOD should now define it's axiomatic roots!

Sets of statements like:

1. My design goal is to minimize my future work.

vs.

1. I must minimize coupling.
2. I must grow cohesion.

vs.
I must respect:
1. Open Closed
2. Interface Segregation
3. Liskov Substitution
4. Low of Demeter

may share the same goal, may become in OOD what parallel axiomatic systems represent in modern mathematics and physics.

Different opinions? ;)

TDD is vague

I was asked recently about TDD:

What is it exactly? What's the difference between it and Test First Programming?

The questions were raised by one of my colleagues in a Test related activity we had. (Simple curiosity about a handy acronym heard somewhere some time ago and if applicable to what we were doing)

My quick answer: "Test Driven Development is not only about writing your test first! It implies you also see the system as a tester/user. In TDD you ask yourself questions like: What can go wrong? What other scenarios must be considered? Guidance from a preventive QA team would be welcomed in this process... "

Context : we were developing(peering) a new feature - new GUI and related functionality in a TDD manner, writing quickly the functional test (called by us "GUI test") before, and trying to keep the green bar afterward.

After some reflection I realized that TDD is a vague acronym. Why? Because "Development" is also vague.

Development examples :

• explore a simple idea: It might be possible to create this new method that will save us from this amount of code duplication.
• explore a new technology, use it in the application: Can we use hibernate? Yes. We need to use these annotations. Data is persisted.
• design a number of classes with complex behavior: We have performance related problems - we need to cache previously computed results. We must be able to invalidate the cache.
  
• design a number of classes with complex structure: For the given primary inputs, we must be able to compute and save intermediate results.
• build business structure: Make this "Foo" editable, you did the same for "Bar"
  
• build business behavior: We have to create these Business rules.

So TDD could mean:

• Test Driven Exploring (driven by learning oriented tests)
  
• Test Driven Design (driven by design oriented tests)
  
• Test Driven Structure Implementation (driven by GUI oriented tests)
• Test Driven Behavior Implementation (driven by acceptance criteria oriented tests) - thank god we already have a name for this : BDD
• ...

So, answering TDD is not easy, it implies Test First, it implies small steps, various external preoccupations on a case by case basis: what may break my design, what other GUI interactions may work wrong, when can we say acceptance criteria passed, ..

It's been a while since I wrote this post. Reached a very nice post about another TDD meaning:

• Test Driven Refactoring (driven by refactoring oriented tests)

Reached another nice post regarding TDD & Test First: TDD does not mean Test First. "TDD does lead to better code - test first does not." Really enjoyed the formulation!