Monday, October 10, 2016

A Lesson Learned form Publishing New Book

A week ago InfoQ publisher released my new book: Conversation Patterns for Software Professionals.

For those of you who asked me about an english versions of my writing - this is it. Whole book was designed for the English-speaking reader.

Once I tried to publish outside Poland my 'How to Talk to the Clients Who Don't Know What They Want' book. But concept of the book was refused by publishers I contacted with.

Then I decided to release small pieces of the book wrapped in articles at InfoQ. I hoped someday I would be able to publish them in the form of a book.

It took 2 years and 4 months - quite quickly, I think. Lesson learned: I over value my one-year capabilities, I under value my 10-years capabilities.

eBook version is exclusively available for free at InfoQ. Printed (paid) version will be available soon at amazon.com and lulu.com.

Monday, September 26, 2016

Rethinking Software Architecture

From time to time everybody feels that the architecture of the software one develop is quite closer to a big bull of mud that the screaming architecture.

I give you plan of a workshop you may lead with your team. This is a part of my ArchitecturalKata for an Agile Team workshop.

What is the Goal

We want to achieve agreed and clear vision of the architecture. I am really pragmatic person. So I am not going to push you to introduce some sexy solutions as: DDD, Clean Architecture, CQRS, Event Sourcing and stuff. It may happen it may not.

There are many criteria to meet to achieve these architectures. Here, our goal is to move your architecture into a better place, even it mean a step forward. We want the architecture to be more testable, maintainable and more decoupled. That's all.

What We Need?

  • a team who work on the system (recommend no more than 10 people)
  • 1-2 days
  • silent classroom
  • space on the walls or on the floor
  • quite big table or space on the floor
  • couple blocks of sticky notes in many colors
  • colored markers
  • pair of scissor
  • printer paper
  • big flip-chart sheets
  • paper tape
  • a computer with a code baseline
  • beamer (useful but not necessary)

See Responsibilities

Because flow of that workshop varies in some details depends on the software size and granulation, I give you an example for the quite big legacy system (developed from more than a decade, where primary building blocks are components containing many classes).
  1. First, capture all your components. Write each on a sticky note. It may be hundred of them or more but not so much :)
  2. Then look into the source code and try to name responsibilities. Responsibility is a role of the component and the way how it serve to others. So, you will find them looking at the public methods, events published, signals sent. Sometimes one strange method is one responsibility, other time group of related method define a responsibility.
  3. That's important: name only those responsiblities you see in the code, not those you think they are
  4. Don't be too detailed with the granulation of the responsibilities. Be ready to regroup and rename them any time you want
  5. Probably you know that in a legacy code components have many responsibilities, so name them explicitly and write them on small stickies. Next put small stickies on components they come from
  6. You will see than you have two to four components which looks like stars with its satellites :) These are components where single responsibility principle was really abused. There is much code inside

Redefine Responsibilities

Now its time to redefine responsibilities of the components. Organize your components obeying following rules:
  • A component has exactly one coherent responsibility
  • You are allowed to add new components
  • You are allowed to remove components
  • You are allowed to rename components
So now:
  1. Add/Remove/Rename components and reorganize responsibilities stickies
  2. Repeat until every single component have sort of small stickies and all of them describe one coherent responsibility

Redefine Communication Between Components

  1. Now draw directed lines representing communication between components and note purposes of a communication just right above the lines. A line starts from a component which initiate communication.
  2. There is one rule during this exercise: a line cannot cross an other line. I will explain why at moment.
  1. Sometimes you will discover a cyclic dependency between components, so remove it, if needed.

Cluster Components

  1. The rule "don't cross the line" caused that components which work closely are stuck closely.
  2. Try to circle clusters of closely related components. But there is important rule: look for the clusters related to the functionality of the system. You may ask yourself: What is the core cluster where we have minimal deliverable functionality? How to cluster components to extract potentially optional functionalities?
  3. Name these clusters

Define Clusters API

Now we want to see high-level view. We want to extract fine grained and decoupled clusters enclosed in modules, processes or separate applications.
  1. First define an API for the clusters.Finally we want cluster-to-cluster communication instead of component-to-component. A component-to-component communication is fine inside the cluster, but not between them.
  2. API receives communication from other clusters and distributes it inside of the cluster. It also translates the inside-cluster communication into outside one.Technically that translation layer will be some combination of facades and adapters.
  3. Defining API remember that we have: exposed interfaces and required interfaces. Define both.
  4. Also explain how the inside-cluster components talk to each other.
  5. This is important: obey the encapsulation rules: nothing from inside of the cluster is seen to the outside world

Define Communication Between Clusters

  1. Draw communication between clusters. It will be API-to-API communication, it mean exposed interface to required interface.
This is it. Artifacts and discussions during that workshop bring quite clear understanding of the current state and well defined vision were want to be if about architecture of our software.

How long it takes to refactor the code?

Wel, it depends ;). I know the cases (software of that size) where it took a year or so total. Remember that visioning is a one thing, but bringing the vision into reality is completely different story.

What Next?

One of the next steps is a really tricky stuff. We need to prepare plan how to communicate our technical objectives to managers and all those people who have an authority to say YES or NO to our refactoring work. On the end we want them to support our new architecture.

Working strategies to convincing sponsors are the key part of my ArchitecturalKata for an Agile Team workshop. If you want me to lead this workshop for your team, please contact me at the contact form.

Thursday, September 22, 2016

Group Your Tasks by Context

I had really busy time last month, I did training and workshops week by week. Naturally I come up with an idea of optimizing my tasks and decided to arrange all that organisational stuff on the beginning of the month.
In my trello board the following card was created:

When working I checked task by task but realized that I wanted to update training materials before printing. Moreover I received a discount in the hotel but first I had pay it in cash. In consequence of that it was better to book hotel for third training in two weeks.

My task froze. In couple days I start feel myself frustrated because I couldn't move that stupid task to the 'DONE' column. Why? Because I did a mistake in grouping tasks by a type (organisational stuff) instead of context (a training).

Grouping them by a context is almost always better solution. It would generate more cards on the board, but at the same time they would move through the board faster. You improve the flow, boost your satisfaction and motivation - that's how it works.

So keep in mind: group your tasks by a context instead of a type.

Thursday, September 15, 2016

Meet us at JDD 2016

This year you will see a special talk at JDD Conference.
Me and Łukasz Korczyński (Nordea Bank AB) prepared a summary of six months long work with pushing refactoring initiative at Nodea Bank AB (former Nordea IT Polska) in Gdynia. We are waiting for your attending!

Moving the blog

So, most of my time was recently consumed by books writing. It's time to reactive the blog, so I decided to move it into gettingthingsprogrammed.pl as a part of some changes related to my personal branding.

So, how do you find the gettingthingsprogrammed.pl?

Friday, May 13, 2016

Getting Things Programmed comming soon

So, I've fished work on my new book (in Polish) 'Getting Things Programmed'.


The goal behind this book is to help you become more effective developer than you can imagine. Many thanks to Maciej Aniserowicz for a deep review of the author's version.

I my two books:
I cover set of issues with soft skills, communications and effectiveness you will face with working on software.

No matter you're a developer, ScrumMaster, ProductOwner, TechLead or PM. These books give you extremely useful techniques to find the solutions which are the best for you, you customer and your product.

More techniques, tools, cases and great training experience you will find during workshop I lead:


Thursday, March 24, 2016

Interviews

Some times ago I meet Marcin Muras at a Geek Girls Carrots event in Lodz. He offered to interview me. She here it is the result. That's the most personal talk I have given publicly - I like it :).

Maciek Aniserwicz arranged also a devtalk. We talked about communications and soft skills. Have fun!

Thanks to Marcin and Maciek for your effort.

Friday, January 8, 2016

How to convince your client to your ideas?

How to convince your client/supervisor/team to your ideas? – this is one of the most common questions that come up during my work with teams. In this article you will learn effective techniques that will help you propose solutions that you think are better than those suggested by your client. We will also decide if it is really about convincing. (You may find useful to look into previous parts of the series: Part1, Part2, Part3, Part4, Part5)...

Read more at InfoQ