0% found this document useful (0 votes)
37 views

Effective Software Development For The Enterprise Beyond Domain Driven Design Software Architecture And Extreme Programming 1st Edition Tengiz Tutisani pdf download

Ebook access

Uploaded by

reachrhoo28
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views

Effective Software Development For The Enterprise Beyond Domain Driven Design Software Architecture And Extreme Programming 1st Edition Tengiz Tutisani pdf download

Ebook access

Uploaded by

reachrhoo28
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 90

Effective Software Development For The

Enterprise Beyond Domain Driven Design Software


Architecture And Extreme Programming 1st Edition
Tengiz Tutisani download
https://ebookbell.com/product/effective-software-development-for-
the-enterprise-beyond-domain-driven-design-software-architecture-
and-extreme-programming-1st-edition-tengiz-tutisani-50271520

Explore and download more ebooks at ebookbell.com


Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Generative Ai For Effective Software Development 2024th Edition Anh


Nguyenduc

https://ebookbell.com/product/generative-ai-for-effective-software-
development-2024th-edition-anh-nguyenduc-57577960

Building Software Teams Ten Best Practices For Effective Software


Development 1st Edition Joost Visser

https://ebookbell.com/product/building-software-teams-ten-best-
practices-for-effective-software-development-1st-edition-joost-
visser-5702850

Effective Debugging 66 Specific Ways To Debug Software And Systems


Effective Software Development Series 1st Edition Spinellis

https://ebookbell.com/product/effective-debugging-66-specific-ways-to-
debug-software-and-systems-effective-software-development-series-1st-
edition-spinellis-55138048

Effective Python 90 Specific Ways To Write Better Python Effective


Software Development Series 2nd Edition Brett Slatkin

https://ebookbell.com/product/effective-python-90-specific-ways-to-
write-better-python-effective-software-development-series-2nd-edition-
brett-slatkin-34020854
Effective Objectivec 20 52 Specific Ways To Improve Your Ios And Os X
Programs Effective Software Development Series Matt Galloway

https://ebookbell.com/product/effective-objectivec-20-52-specific-
ways-to-improve-your-ios-and-os-x-programs-effective-software-
development-series-matt-galloway-55385096

Effective Perl Programming Ways To Write Better More Idiomatic Perl


Effective Software Development 2nd Edition Hall Mcadams Foy

https://ebookbell.com/product/effective-perl-programming-ways-to-
write-better-more-idiomatic-perl-effective-software-development-2nd-
edition-hall-mcadams-foy-55423166

The Cognitive Dynamics Of Computer Science Costeffective Large Scale


Software Development Szabolcs Michael De Gyurky

https://ebookbell.com/product/the-cognitive-dynamics-of-computer-
science-costeffective-large-scale-software-development-szabolcs-
michael-de-gyurky-920400

Become An Effective Software Engineering Manager How To Be The Leader


Your Development Team Needs James Stanier

https://ebookbell.com/product/become-an-effective-software-
engineering-manager-how-to-be-the-leader-your-development-team-needs-
james-stanier-23573156

Metricsdriven Enterprise Software Development Effectively Meeting


Evolving Business Needs Datta

https://ebookbell.com/product/metricsdriven-enterprise-software-
development-effectively-meeting-evolving-business-needs-datta-5430852
Ef fective Sof tware
Development for
the Enterprise
Beyond Domain Driven Design,
Software Architecture, and
Extreme Programming

Tengiz Tutisani
Effective Software
Development for the
Enterprise
Beyond Domain Driven Design,
Software Architecture,
and Extreme Programming

Tengiz Tutisani
Effective Software Development for the Enterprise: Beyond Domain Driven
Design, Software Architecture, and Extreme Programming

Tengiz Tutisani
Charlotte, NC, USA

ISBN-13 (pbk): 978-1-4842-9387-4 ISBN-13 (electronic): 978-1-4842-9385-0


https://doi.org/10.1007/978-1-4842-9385-0
Copyright © 2023 by Tengiz Tutisani
This work is subject to copyright. All rights are reserved by the publisher, whether the whole or
part of the material is concerned, specifically the rights of translation, reprinting, reuse of
illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way,
and transmission or information storage and retrieval, electronic adaptation, computer software,
or by similar or dissimilar methodology now known or hereafter developed.
Trademarked names, logos, and images may appear in this book. Rather than use a trademark
symbol with every occurrence of a trademarked name, logo, or image we use the names, logos,
and images only in an editorial fashion and to the benefit of the trademark owner, with no
intention of infringement of the trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if
they are not identified as such, is not to be taken as an expression of opinion as to whether or not
they are subject to proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal
responsibility for any errors or omissions that may be made. The publisher makes no warranty,
express or implied, with respect to the material contained herein.
Managing Director, Apress Media LLC: Welmoed Spahr
Acquisitions Editor: Aditee Mirashi
Development Editor: James Markham
Coordinating Editor: Mark Powers
Copy Editor: April Rondeau
Cover designed by eStudioCalamar
Cover image by Luemen Rutkowski on Unsplash (www.unsplash.com)
Distributed to the book trade worldwide by Apress Media, LLC, 1 New York Plaza, New York, NY
10004, U.S.A. Phone 1-800-SPRINGER, fax (201) 348-4505, email [email protected],
or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member
(owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance
Inc is a Delaware corporation.
For information on translations, please e-mail [email protected]; for
reprint, paperback, or audio rights, please e-mail [email protected].
Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook
versions and licenses are also available for most titles. For more information, reference our Print
and eBook Bulk Sales web page at http://www.apress.com/bulk-sales.
Any source code or other supplementary material referenced by the author in this book is
available to readers on GitHub (https://github.com/Apress). For more detailed information,
please visit http://www.apress.com/source-code.
Printed on acid-free paper
I dedicate this book to my life’s two most precious women:
my mother, Eteri Tetrauli, and my wife, Romana Stasiv.
Table of Contents
About the Author�������������������������������������������������������������������������������xiii

About the Technical Reviewer������������������������������������������������������������xv

Acknowledgments����������������������������������������������������������������������������xvii

Preface����������������������������������������������������������������������������������������������xix

Chapter 1: Introduction������������������������������������������������������������������������1
History of Inefficient Monoliths�����������������������������������������������������������������������������1
Why People Avoid Building Effective Software�����������������������������������������������������2
Learning Curve������������������������������������������������������������������������������������������������3
Quality over Quantity���������������������������������������������������������������������������������������3
Highly Paid Experts������������������������������������������������������������������������������������������5
Naive Hopes to Survive�����������������������������������������������������������������������������������5
Software Development Perfectionism as a State of Mind������������������������������������6
Is It Crazy?�������������������������������������������������������������������������������������������������������6
Desire Behind Perfectionism���������������������������������������������������������������������������7
Is It Worth It?���������������������������������������������������������������������������������������������������7
Six Pillars of Effective Software����������������������������������������������������������������������������8
#1. Meet Users’ Expectations��������������������������������������������������������������������������8
#2. Allow No Defects���������������������������������������������������������������������������������������9
#3. Scale Out Horizontally�����������������������������������������������������������������������������10
#4. Have No Dedicated Production Support Team�����������������������������������������11

v
Table of Contents

#5. Accelerate Development Pace�����������������������������������������������������������������11


#6. Double the ROI per Developer, Team, and Software��������������������������������11
Summary������������������������������������������������������������������������������������������������������������12

Chapter 2: Cross-cutting Concerns�����������������������������������������������������13


Execution, Leadership, Management������������������������������������������������������������������14
Importance of Software Development Transformation����������������������������������14
How to Achieve Software Development Transformation��������������������������������15
Transformation Is for Everybody��������������������������������������������������������������������15
Ad-Hoc Tasks vs. Process������������������������������������������������������������������������������17
Hands-on Leaders�����������������������������������������������������������������������������������������18
Overall Support from Management���������������������������������������������������������������19
Organizational Structure�������������������������������������������������������������������������������������19
A Couple of Important Definitions Upfront�����������������������������������������������������19
Forming Organizations����������������������������������������������������������������������������������20
Forming Subsystems�������������������������������������������������������������������������������������22
Forming Microservices����������������������������������������������������������������������������������24
Forming Teams����������������������������������������������������������������������������������������������25
Forming Programs, Projects, Requirements, and Deliveries�������������������������29
Organizational Silos���������������������������������������������������������������������������������������30
Autonomy vs. Reuse��������������������������������������������������������������������������������������33
Processes, Ongoing Efforts, Teams���������������������������������������������������������������������34
Agile or Waterfall�������������������������������������������������������������������������������������������34
Transparent Teams����������������������������������������������������������������������������������������36
Managing Work in Progress���������������������������������������������������������������������������37
One for All, All for One������������������������������������������������������������������������������������38
Transformation from Inside���������������������������������������������������������������������������39
Culture����������������������������������������������������������������������������������������������������������������40

vi
Table of Contents

Professionalism in Software Development����������������������������������������������������40


Trust���������������������������������������������������������������������������������������������������������������42
Delegation of Responsibilities�����������������������������������������������������������������������43
Identifying Talent�������������������������������������������������������������������������������������������44
Relaxed Team Atmosphere����������������������������������������������������������������������������45
Work–Life Balance����������������������������������������������������������������������������������������46
Candid Feedback�������������������������������������������������������������������������������������������46
Change of Mind���������������������������������������������������������������������������������������������47
Social Aspect of Engineering�������������������������������������������������������������������������48
Complexity as Job Safety������������������������������������������������������������������������������50
Team Spirit����������������������������������������������������������������������������������������������������51
Keep It Fun����������������������������������������������������������������������������������������������������53
Recruitment��������������������������������������������������������������������������������������������������������54
Supporting Role of Recruitment��������������������������������������������������������������������54
Hire Best��������������������������������������������������������������������������������������������������������55
Quickly, Fancy, Right��������������������������������������������������������������������������������������55
Corrective vs. Preventive�������������������������������������������������������������������������������57
Summary������������������������������������������������������������������������������������������������������������58

Chapter 3: From Customer Insights to Internal Requirements�����������59


Understanding Customers’ Needs����������������������������������������������������������������������60
Partnership and Customer Focus������������������������������������������������������������������61
Interview Customers�������������������������������������������������������������������������������������63
Knowledge Exploration Exercises������������������������������������������������������������������64
Organization’s Response to Customers’ Needs��������������������������������������������������68
From Customer Interview to Organizational Transformation�������������������������68
Navigating the Context Map to Find Fit���������������������������������������������������������69
Why Form a New Subdomain?����������������������������������������������������������������������72
Cost of Introducing a Subdomain������������������������������������������������������������������74

vii
Table of Contents

Requirements and Story Writing�������������������������������������������������������������������������75


Ubiquitous Language: What Is It? Why Is It Important?���������������������������������76
Who Writes Stories?��������������������������������������������������������������������������������������78
Ubiquitous Language in Requirements����������������������������������������������������������79
Writing Executable Specifications�����������������������������������������������������������������81
Halfway into Gherkin�������������������������������������������������������������������������������������82
All the Way into Gherkin��������������������������������������������������������������������������������84
Planning Work�����������������������������������������������������������������������������������������������������85
Prioritized Backlog����������������������������������������������������������������������������������������85
Feasibility������������������������������������������������������������������������������������������������������86
Managing Dependencies�������������������������������������������������������������������������������87
Valuable Stories (Verticals)����������������������������������������������������������������������������94
Technical Stories�������������������������������������������������������������������������������������������96
Carrying Out Work�����������������������������������������������������������������������������������������������98
Definition of Done������������������������������������������������������������������������������������������98
Estimates vs. Velocity����������������������������������������������������������������������������������100
Your Estimate Is Your Deadline��������������������������������������������������������������������101
Achieving Predictability�������������������������������������������������������������������������������101
Summary����������������������������������������������������������������������������������������������������������104

Chapter 4: Design and Architecture��������������������������������������������������105


Architecture as a Cross-cutting Concern����������������������������������������������������������106
Definitions and Purpose������������������������������������������������������������������������������106
Is Architecture Dead?����������������������������������������������������������������������������������108
Architecture as a Service����������������������������������������������������������������������������111
Partnership with Domain Experts����������������������������������������������������������������113
Teams and Microservices����������������������������������������������������������������������������114
Architecture Supports Organizational Growth���������������������������������������������115

viii
Table of Contents

Architecture in Analysis and Requirements Gathering��������������������������������������116


Upfront Design Supports Gap Analysis��������������������������������������������������������116
Knowledge Exploration and Architecture�����������������������������������������������������118
Caveat of a Technical Solution���������������������������������������������������������������������118
Architecture Body of Knowledge�����������������������������������������������������������������������121
Architecture Landscape�������������������������������������������������������������������������������122
Buy vs. Build������������������������������������������������������������������������������������������������123
Good Architectures��������������������������������������������������������������������������������������124
Architecture and Technology�����������������������������������������������������������������������128
Using Technology�����������������������������������������������������������������������������������������132
Domain Model Kinds������������������������������������������������������������������������������������136
Life with Anemic Domains���������������������������������������������������������������������������138
Layered Software Architecture��������������������������������������������������������������������140
Microservices����������������������������������������������������������������������������������������������142
Evolving an Ecosystem of Microservices����������������������������������������������������148
Command Query Responsibility Segregation (CQRS)����������������������������������151
Path to Event-Driven Architecture (EDA)������������������������������������������������������153
Building Cloud-Ready Applications��������������������������������������������������������������155
Performance������������������������������������������������������������������������������������������������158
Front-End Application Architecture��������������������������������������������������������������159
Built-In Security�������������������������������������������������������������������������������������������160
Databases����������������������������������������������������������������������������������������������������161
Architecture and Implementation���������������������������������������������������������������������164
Tactical DDD������������������������������������������������������������������������������������������������165
Evolving Design�������������������������������������������������������������������������������������������165
Writing Domain Layer’s Code����������������������������������������������������������������������166
Consolidate Development Tools and Languages�����������������������������������������167

ix
Table of Contents

Architecture for Testable Systems��������������������������������������������������������������������168


Testable Code����������������������������������������������������������������������������������������������168
Testable Application������������������������������������������������������������������������������������168
Architecture for Deployable Systems����������������������������������������������������������������169
Versioning����������������������������������������������������������������������������������������������������169
Containerization������������������������������������������������������������������������������������������171
Architecture for Maintainable Systems�������������������������������������������������������������171
Mindset Shift—No Tech Debt����������������������������������������������������������������������172
Working Systems�����������������������������������������������������������������������������������������172
Fixing It Twice����������������������������������������������������������������������������������������������174
Simple vs. Complex Systems����������������������������������������������������������������������175
Summary����������������������������������������������������������������������������������������������������������175

Chapter 5: Implementation and Coding��������������������������������������������177


Cross-cutting Concerns Related to Coding�������������������������������������������������������178
Professionalism of a Coder��������������������������������������������������������������������������178
Put Talent into Important Tasks�������������������������������������������������������������������179
Continuous Improvement����������������������������������������������������������������������������180
Quality vs. Quantity��������������������������������������������������������������������������������������184
Code Reviews����������������������������������������������������������������������������������������������185
Designing Code�������������������������������������������������������������������������������������������������187
Implementation of Architecture�������������������������������������������������������������������187
Code Design Techniques������������������������������������������������������������������������������189
Essence of Object-Oriented Programming��������������������������������������������������189
Purpose of Design Patterns�������������������������������������������������������������������������193
Implementing Code�������������������������������������������������������������������������������������������195
Tactical DDD Patterns����������������������������������������������������������������������������������195
Declarative Design in Code��������������������������������������������������������������������������211

x
Table of Contents

Front-End Development�������������������������������������������������������������������������������215
Exception Handling��������������������������������������������������������������������������������������222
Testing Code�����������������������������������������������������������������������������������������������������226
Unit Testing��������������������������������������������������������������������������������������������������227
TDD, ATDD, and BDD������������������������������������������������������������������������������������230
Code Deployment and Maintenance�����������������������������������������������������������������232
CI/CD Before Development��������������������������������������������������������������������������232
Planning Deployment When Developing������������������������������������������������������233
Planning Maintenance When Developing����������������������������������������������������234
Summary����������������������������������������������������������������������������������������������������������234

Chapter 6: Testing and Quality Assurance����������������������������������������235


Testing Processes and Principles���������������������������������������������������������������������235
Who Is For and Who Is Against?������������������������������������������������������������������236
Quality Is Team’s Responsibility������������������������������������������������������������������236
Test Everything, Automate Everything���������������������������������������������������������237
Importance of Test Automation��������������������������������������������������������������������240
Test Design and Architecture����������������������������������������������������������������������������244
Test Types����������������������������������������������������������������������������������������������������244
Test Case per Requirement�������������������������������������������������������������������������246
Test Automation Design Patterns����������������������������������������������������������������248
Test Data Management��������������������������������������������������������������������������������259
Implementing Automated Tests�������������������������������������������������������������������������265
Delayed Automation������������������������������������������������������������������������������������265
Early Automation�����������������������������������������������������������������������������������������266
Enhancing Deployments with Test Automation�������������������������������������������������269
Fast Feedback and Compensating Actions��������������������������������������������������269
Continuous Deployment������������������������������������������������������������������������������272
Summary����������������������������������������������������������������������������������������������������������273

xi
Table of Contents

Chapter 7: Deployment���������������������������������������������������������������������275
Culture of Releases�������������������������������������������������������������������������������������������276
Why Release Software?�������������������������������������������������������������������������������276
Unimportance of Releases���������������������������������������������������������������������������277
CI/CD—Deployment Foundation�����������������������������������������������������������������������280
Continuous Integration��������������������������������������������������������������������������������280
Continuous Deployment������������������������������������������������������������������������������282
Building Deployment-Ready Applications���������������������������������������������������������283
Developing Deployable Units�����������������������������������������������������������������������283
Ensuring Smooth Deployments via CI/CD����������������������������������������������������284
Dev–Prod Parity�������������������������������������������������������������������������������������������285
Effects of Containerization on Deployments������������������������������������������������286
Summary����������������������������������������������������������������������������������������������������������287

Chapter 8: Maintenance and Support�����������������������������������������������289


Maintenance-Free Mindset�������������������������������������������������������������������������������289
Organization’s Approach to Maintenance����������������������������������������������������290
Support-Oriented Organizations������������������������������������������������������������������291
Award-Winning Support Teams�������������������������������������������������������������������292
Who Prevents Problems?����������������������������������������������������������������������������292
Maintenance-Aware Mindset����������������������������������������������������������������������������293
Maintaining Applications in Practice�����������������������������������������������������������293
Fix Root Cause, Not Surface������������������������������������������������������������������������296
Building Blocks of Maintainable Systems���������������������������������������������������296
Summary����������������������������������������������������������������������������������������������������������298

Afterword: Wrap-up��������������������������������������������������������������������������299

References����������������������������������������������������������������������������������������301

Index�������������������������������������������������������������������������������������������������315
xii
About the Author
Tengiz Tutisani has been in the software
development industry for over 20 years. His
experience ranges from startups to Fortune
500 corporations. He has held a variety of roles
in technology leadership (software engineer,
technical lead, development manager,
application architect, solutions architect,
enterprise architect, and chief architect).
Tengiz’s broad experience and frequent
recognition for outstanding quality and performance have convinced
him to teach others unique engineering and architecture techniques.
He authored this book to describe advanced techniques for professional
software development and architecture disciplines.

xiii
About the Technical Reviewer
Tom Graves has been an independent
consultant for more than four decades
in business transformation, enterprise
architecture, and knowledge management.
His clients in Europe, Australasia, and the
Americas cover a broad range of industries,
including banking, utilities, manufacturing,
logistics, engineering, media, telecoms, research, defense, and
government. He has a special interest in architectures beyond IT and
integration between IT-based and non-IT-based services.

xv
Acknowledgments
I want to acknowledge and thank the people who helped me make this
book a reality. I am grateful to every person that I mention here.
First, a big thank you goes to every individual who took time to read
the final manuscript of this book and wrote a short review, which will
be used in various ways to inform the readers about the book’s benefits:
Dave Black, Jim Hammond, Preeti Baranga, Lasha Kochoradze, Nugzar
Nebieridze, and Romana Stasiv.
Furthermore, I want to thank those who provided invaluable feedback
about the manuscript by noticing typos or unclear sentences or even
proofreading it: Dave Black, Jim Hammond, Gomti Mehta, Preeti Baranga,
and Romana Stasiv. I know that all of you went the extra mile to ensure that
this book reached its deserved quality. Without you, I am afraid that I would
have published text that would make me feel embarrassed in the future.
Additional gratitude goes toward the Apress editorial team, who guided
me through turning this publication into a polished piece of work worth
taking to the shelves and screens of a broad audience. The Apress team
includes Aditee Mirashi, Shobana Srinivasan, Mark Powers, James Markham,
and Sowmya Thodur. A special thank you goes to the technical reviewer,
Thomas Graves, who provided subject-matter expertise, challenging technical
questions, and feedback essential to taking the book to the next level.
Finally, my unmeasurable appreciation goes to my wife, Romana
Stasiv, who patiently supported me while I worked on the book, both the
initial manuscript and with Apress. I wrote the text once, but I rewrote
it about 150 times! Nobody would have tolerated so many long working
hours without genuine love connecting our hearts. Also, with Romana’s
Agile expertise, I received early feedback about many topics in this
publication, which helped me pave the road to the finish line.

xvii
Preface
Before getting into the book’s central chapters, I want to explain why
I wrote it to begin with, what you will learn, and how it will benefit you on
your path to building software solutions.

Why I Wrote This Book


Looking back at my career in software development, I can see how
I ended up writing a book like this. It addresses gaps in the industry that
I experienced firsthand, and it reflects who I am—a software development
perfectionist (bear with me—I will prove that this is not a bad thing at all).
This work is an attempt to fix problems that always challenged me.
I know that these same issues worry many others too.
At every job I have had, I was bogged down by non-readable
code, non-practical architectures, a vast number of defects, unclear
requirements, unavailable domain experts, monolithic codebases, long
deployments (releases), and so on. The business side was not happy,
either. Domain experts complained about the quality of software, how it
worked, its capacity to handle more users, the cost of developing it, and
so forth.
I honestly believe that I have answers to all of these challenges for those
who want to solve them. I care because I experience these same problems
myself daily, and I address them successfully where my capacity allows me
to do so. I have developed my process over the course of many years, and it
is time to share it with others.

xix
Preface

Next, I present a couple of anecdotes from my past that inspired me


to write this book. I hope that some readers will recognize their own
experience or personality between the lines. This narrative will also explain
what kinds of problems we will be solving throughout this publication.

***
At my first job, I was the only developer on a team. I had the freedom
to write code in any way I wanted, and that seemed to be a perfect
environment in which to thrive. I developed many applications and
components from scratch, and I enjoyed the freedom of improvising in
code. Everything was going smoothly until the codebase grew to the point
that I had a hard time working with it. I almost wanted to start it all over
again! It turns out that many developers struggle with the same issue
throughout their career paths.
How can the code that we wrote ourselves bite us back? There must be
something wrong with what we do, don’t you agree?
Therefore, we will learn how to write code that does not become our
problem shortly after we author it.

***
At my second job, I worked on a team consisting of a couple of
engineers, so I had a chance to read code written by other developers. It
was a rather complex banking domain, and I needed to learn it fast to keep
the job.
When such a challenge faces us, we realize that the codebase can
either be our friend or our enemy, depending on whether it helps or blocks
us from the goal.
I read a lot of code, but it did not give me any knowledge about the
domain. Instead, it confused me more and more as time passed. I could
only explain this complexity by believing that the code was not supposed
to be understood by people because it was written just for computers. That
was a naive thought.

xx
Preface

We are humans in the first place, so we should write code for humans.
Computers will understand code no matter how we write it. So writing a
program for them is a piece of cake. Try to write code that humans can
understand—that is a challenge!
Therefore, we will learn how to write code that expresses valuable domain
knowledge and is readable by technical learners of the problem space.

***
I once worked on a project where developers had good knowledge of a
problem space, and specialists in the subject matter were also accessible.
However, meetings occurred in silos instead of leveraging access to
domain knowledge. First, a domain expert would describe a requirement
in business terms; next, the conversation would transfer to the developers,
while domain experts did not (or could not) participate in the discussion
from that point on. Engineers would “interpret” the expectation using
technical concepts, patterns, and frameworks, and would use their
terminology and tools for implementation. Because of this intentional
disconnect, the resulting solution was too technical and often had little or
no relevance to how the business worked; instead, it added inconvenience
and complexity for business SMEs (Subject Matter Experts).
Therefore, we will learn how to write software that serves both
developers and non-developers equally. It is time that we start helping
business colleagues instead of complicating their lives.

***
One more project comes to mind. We could not focus on new feature
development because the defects were frequent. We had to jump on them
as they appeared due to the high visibility of the application. We would fix
errors and then go back to our current sprint (iteration) backlog, and we
just knew that the next bug was hours, if not minutes, away. Consequently,
new feature development went slowly and was unorganized.

xxi
Preface

It is a terrible feeling when you cannot focus on something and finish it


without interruptions. It is like being tired in an airplane and trying to sleep,
but a narrow seat and limited legroom do not let you relax completely. In
those moments, you dream about a simple, comfortable bed.
Therefore, it is crucial that we know how to avoid defects and allow
ourselves to focus on new feature development instead.
Although many consider bug-free software impossible, we will learn
how to reach this objective in real life.

***
I remember the tired face of an engineer who was tasked with
supporting an application in a production environment. He did not even
write that software and did not know all the intricacies inside the system.
He had to keep bugging an actual development team with questions
when a new kind of issue was discovered. He had a handbook full of
troubleshooting steps for various types of symptoms that the application
could produce. He was hesitant to contact the development team every
time because the engineers were “cool guys” who had more important
tasks than to support the application (written by them in the first place).
As you can imagine, the mentioned system was a nightmare to run and
troubleshoot. In my mind, the root cause was developers’ being unaware
of production support’s pain points and lacking the necessary skills for
producing better software that would be easier to maintain.
Would the outcome be different if developers had to run and support
their solutions in a production environment instead of somebody else
doing it for them?
To tackle the described problem, we will learn how to build software
that works in a production environment without a dedicated production
support team by distilling ways to develop better programs and maintain
them in production with minimal to no cost.

***

xxii
Preface

Perhaps every developer has been on a project where developing a


new feature is like rocket science. The codebase is so complex that an
implementation process is merely a trial-and-error activity: a developer
needs to make careful changes to several moving parts while finding more
unknowns on the way. Such an increased level of complexity makes work
and estimation very difficult.
When software development becomes a discovery process when
implementing every task, this hints at problems in how an application is
structured.
We will learn about development and architecture techniques for
building better software systems that are easier to develop and change.
Another side effect that happens in the mentioned situation is a
slowdown in development pace.
Hence, we will also study techniques to accelerate software development
processes instead of slowing them down.

***
I recently encountered a web application that was deployed to three
servers to handle many parallel requests. Surprisingly to engineers
and their management, the system was struggling to serve only 100
simultaneous users. They tried to add more servers, but even more
strangely, it only worsened the situation. As a last resort, the team
rearchitected the application for better scalability, but that exposed other
bottlenecks, complicating the goal of reaching more users.
When such circumstances happen, you need to admit that your
application is not scalable.
Therefore, we will learn how to build software that scales out
horizontally by adding more instances of the application when the number
of users increases.

***
These situations just described served as a foundation for the six
primary pillars upon which this book is built. We will go into more detail in
the next section.
xxiii
Preface

For now, I hope that most of you either recognized your experience or
felt an urge to solve these kinds of problems at present or in the future.

Meet Effective Software


A computer program done right should prevent situations like those
just described. That is what I call “effective software.” We will distill this
definition next.

Definition of Effective Software


In this book, I define effective software as that which satisfies the following
criteria:

1. Meets users’ expectations.

2. Has no defects.

3. Scales out horizontally.

4. Has no dedicated production support team.

5. Accelerates development pace.


6. Doubles ROI per developer, team, and software.

You must remember these items because they form the foundation of
this book. If my writing is successful, you should see that each chapter or
section targets at least one of these points.
Throughout the book, I will be referring to these items in various ways
interchangeably: “six pillars of effective software,” “six elements of quality,”
and so on.
I will go into slightly more detail about each of the mentioned elements
in the next chapters, thus helping you understand why they are essential.

xxiv
Preface

 here This Book Fits in Among


W
Large-Scale Frameworks
In this section, I will briefly explain where this book fits in when applying
large-scale frameworks across organizations.

Enterprise Architecture Frameworks


Some chapters in this book (e.g., “Organizational Structure” in “Part II:
Crosscutting Concerns”) solve problems similar to those addressed by
TOGAF (Technology Open group Architecture Framework, see [TOGAF])
and other enterprise architecture guides (see [Gartner EA]). I want to
explain analogies and differences between popular frameworks in this
field and my own approach.
At the time of this writing, TOGAF is the most popular and proper
representation of the enterprise architecture field. Therefore, I will only refer
to it for simplicity instead of generalizing my comparison with the entire
area. Most of the points will apply to other frameworks too.
TOGAF is a leading approach for enterprise architecture, and it has
proven to be useful over the decades. Many large organizations choose
to use TOGAF for its reputation and all-in-one nature. It covers various
topics, from business architecture through governance and execution of
enterprise activities.
Various approaches that I describe in this book can be seen as a
basis of a modern, lighter-weight, and scalable enterprise architecture
framework. I firmly believe that the structures described here will suffice
and can be adapted by many organizations without the necessity of opting
into heavier-weight frameworks such as TOGAF.
Nevertheless, I do not intend to position this book as an alternative
to TOGAF as a whole: the two publications have distinct purposes and
problem scopes. Therefore, they propose different solutions.

xxv
Preface

SAFe—Scaled Agile Framework


SAFe (see [SAFe]) stands on several core values, such as Agile, Lean, and
Systems Thinking. Overall, this framework helps organizations align
their large-scale efforts across the enterprise by treating deliverables as
increments for the entire company.
For the described idea to be successful, besides process
enhancements, we need technical ownership and transformation in areas
such as applications, systems, enterprise architectures, DevOps, and CI/
CD, to name a few. The practice has shown that, without such supporting
mechanisms, SAFe can quickly become an artificial shell around unsolved
technology challenges that fall outside of the Agile framework’s focus. My
book can fill this gap by providing technical guidelines for implementing
high-quality, large-scale solutions.
To outline the compatibility between the two areas of study, here is
how this publication fits into SAFe’s core values:

• Part II: Crosscutting Concerns will explain how


enterprise-wide architectures need to be formed based
on the same Systems Thinking competency as SAFe.

• An Agile process, which comprises SAFe’s core values,


is a possible (although not mandatory) approach when
applying techniques described in this book.

• While also being part of SAFe competencies, Lean


development is an essential part of this book, such as
when I suggest validating product hypotheses before
implementing full-fledged solutions.

For all those synergies that I just described, the book in front of you
can become a supporting mechanism when implementing SAFe or other
organizational process initiatives.

xxvi
Preface

How to Read This Book


First and foremost, you need to look at this book as a guide to
implementing effective software. As I explained earlier, when I say
“effective software,” I mean a digital artifact that meets the six pillars of
quality described previously.
With each chapter, I intend to fulfill specific expectations of effective
software. Some sections will target just one issue, while others will target
several of them.
You will notice two types of chapters primarily:

1. A section that lays out a problem definition and a


solution to it, focusing on one or more of the ideal
pillars.

2. A textbook-style chapter that covers a complex or


commonly misunderstood subject, which I consider
to be a prerequisite for building effective software.

I hope that by presenting this material in such a format, I make it easy


to understand and follow in practice.
A higher-level structure of the book (see Figure P-1) will follow
the flow of the software development process in some way: we will
cover crosscutting concerns as well as all typical stages of the software
development lifecycle.

xxvii
Preface

Figure P-1. The book’s high-level structure

The topic of crosscutting concerns will precede the rest of the subjects.
This order is essential because most crosscutting solutions do not fit
into any of the typical stages but still require attention beforehand to
agree on fundamental assumptions. Afterward, diving into each step of
software development will uncover and address various concerns within
those areas.
At the end of the book, I have included references to reading materials
that support this publication. A link to a reference is a codename enclosed
with square brackets. For example, [Tutisani web] is a link to my website,
which you can find in the references under the “Tutisani web” codename.
An index with keywords is the last piece of this publication, which will
help you find specific terms in the book’s text.
Enjoy your reading!

xxviii
CHAPTER 1

Introduction
In this chapter, I want to examine the fundamental ideas surrounding the
building of effective software. Presented topics will range from historical
reasons for the industry’s problems to decisions of avoiding or accepting
ideal solutions. Additionally, I offer a deep dive into the definition of
effective software that I briefly introduced in the preface.

History of Inefficient Monoliths


Most of the software projects executed nowadays are inefficient. They are
slow and complicated, produce defective monoliths, do not meet users’
expectations, and so on. What is the reason behind these problems?
Haven’t we already learned how to build software? Yes, we have, but times
have changed.
When I started writing code, hardware was expensive. Companies used
to buy a server that had a “beefed-up” processor and memory capacity.
Afterward, developers wrote code that had to offer as much functionality
as possible. Organizations needed an all-in-one solution that had to run
on a single powerful machine. If there were not enough resources on a
server, an administrator would order additional hardware and connect it
to the server machine. There were not many people who used the internet
and software, so there was no need to worry about scalability. The world
needed monoliths, and developers learned how to build them. Computers
did not know how to talk to each other, and so distribution and integration

© Tengiz Tutisani 2023 1


T. Tutisani, Effective Software Development for the Enterprise,
https://doi.org/10.1007/978-1-4842-9385-0_1
Chapter 1 Introduction

were not concerns. A single team had to consist of hundreds of engineers


because there was no other way to work on a shared codebase; they sank in
communication overhead and always stepped on each other’s toes. These
challenges were a norm back then; software had to work for any price.
Today, the situation is entirely different. Servers are so cheap that
companies want to scale out automatically in the cloud, opting to pay
at the end of each month any amount that ends up in their invoices. In
return, there is no need to deal with hardware upgrades anymore. There
are so many people using the internet that no single server could handle
the load, even if just a small fraction of those users were to visit a website.
The only way to handle that load is to scale out, since scaling up has
demonstrated insufficient limits. A single application cannot manage
all functions, so companies want to build multiple mini-applications
(microservices) that work in a connected, distributed fashion. And thus,
we have numerous software development teams, each responsible for
independent solutions. Scalable and efficient software development
teams, processes, and systems have become a winning factor for leading
technology firms.
However, as I said in the beginning, most of the software projects still
employ legacy processes that are not compatible with modern needs. This
gap explains the problem of inefficient monoliths. To solve this issue, we
need to learn how to develop software that is ready for the future—effective
software.

 hy People Avoid Building


W
Effective Software
As we learned earlier in this book, effective software is a high-quality digital
product that can maximize return on investment (ROI). If these promises
are genuine, who would not want to build a program on such terms? It turns

2
Chapter 1 Introduction

out, people still hesitate, and I will explain some of the typical reasons for
this. I want to present these challenges to encourage you to overcome them
and to set realistic expectations.
Before we go any further, you should know that you have chosen not
an easy path for yourself, but also not an impossible one. I have a rather
low level of risk tolerance, and my suggestions are reasonable to me, which
should further assure you that matters are not hopeless at all. Instead, it is
my responsibility to tell you what to expect when attempting to build ideal
software solutions.

Learning Curve
I have collected the necessary skills to build effective software throughout
my career. At the time of this writing, that is more than 17 years.
Admittedly, it took me so long because I was not always sure what I was
seeking—I made up my mind on the way. Nevertheless, all the techniques
needed to build such a high-quality product are scattered everywhere—
process, technology, concepts, patterns, project management, testing,
development, architecture, and so on. While this book should help you
navigate your way in the universe of endless knowledge and information, it
will not shorten the journey drastically. It is just not possible. There is thus
a significant learning curve behind the effort of building effective software.
I am glad that you are still going for it, as not everybody does.

Quality over Quantity


Often, companies want to release many features within a short timeframe
and so cut corners whenever possible. I call this phenomenon “startup
syndrome” since newly formed organizations and teams commonly opt
for this approach. These people hope that they will rewrite the entire
solution once they have become profitable or showcased their abilities,
downplaying the need for the rework or increased number of bugs.

3
Chapter 1 Introduction

Their plans to recreate applications rarely succeed due to new


and pressing needs that follow getting their first paying customers.
Consequently, these projects experience further slow-downs since they
have built their solutions on quick prototypes, which they planned to
throw away or rewrite. Most important, what they fail to realize is that their
approach is not faster than building effective software, on average. Let me
explain the math behind this statement.
When you start practicing effective software development techniques,
the first few months are indeed slower and more cumbersome. This
weakness is a result of the learning curve that you must get through.
After that period passes and as you master advanced exercises, things
improve (see Figure 1-1). This turnaround is due to continuous process
improvement and the innovation that is only possible with a proper
foundation. From my experience, most projects reach this breaking point
in a couple of months.

Figure 1-1. Feature development cost with startup syndrome


surpasses effective software costs after a couple of months of project’s
existence

So, you are not giving up quantity for quality as long as your project
lasts for at least a couple of months. However, the misconception still exists
that effective software requires a sacrifice of quantity to attain quality.

4
Chapter 1 Introduction

Highly Paid Experts


For the very reason that building effective software requires a considerable
learning curve, those who can do it are highly paid and in demand.
Those teams or organizations that lack the necessary expertise
but still want to build effective software will need to hire experts and
pay their salary. On average, benefits will outweigh the costs when
we do so. Unfortunately, edge cases such as hiring an incompetent
expert or project scope creep serve as bad examples and discourage
attempts. Consequently, to avoid wasting money without results, many
organizations and teams avoid building effective software altogether.

Naive Hopes to Survive


Have you ever been in a situation like this? You are driving on a highway,
and a radio host is informing you that there is a severe traffic jam one
mile ahead of you. The road to the horizon is clear, and you are late for an
appointment. What do you do—take the next exit or continue pushing the
throttle?
People commonly hope that the news is inaccurate, or that the traffic
jam is too far away to affect them. So, they decide to stay on the road.
However, a better choice would be to take an immediate exit and seek
an alternate route. It is better to be late to an appointment by 15 minutes
instead of missing it altogether by arriving an hour late (which will be the
outcome for those who stay on a highway in such situations, assuming the
radio host has a reliable source of data).
Similarly, engineers and managers involved in software development
often cannot believe that things will get worse very soon, even though they
keep cutting corners. They experience a fast and smooth development
pace only because their projects are so new, and accumulated tech debt
does not seem so heavy yet.

5
Chapter 1 Introduction

These conditions are characteristic of new solutions! Sooner or later,


most software projects slow down due to complexity, defects, inability to
scale, and so on. This outcome arrives not suddenly but instead gradually,
which is what makes it so hard to measure, predict, or even notice.
Leadership then calls senior-level engineers for help, but it is impossible to
fix the situation without a complete rewrite.
Still, people have naive hopes that this will never happen to them, and
so they see no need to build effective software.
These are some reasons to avoid building ideal solutions, but what’s on
the other end of the spectrum?

 oftware Development Perfectionism


S
as a State of Mind
First of all, let me say this—I am aware that the world is not ideal and that
“perfect is the enemy of good.” I also know that most developers think that
software cannot be perfect or worth the investment. I will take my chances
and explain why I think you should choose to be a perfectionist.

Is It Crazy?
When you introduce something new and utterly different from everything
else, it may seem crazy. I do not want to take too much credit, but it is
similar to the effect of inventing electricity or discovering that the earth is
round and not flat. Those ideas were once considered crazy. Therefore, if
we want to improve, we must give a chance to new proposals.
I do what I teach in this book daily. Nobody thinks that I am crazy. So,
it is not so scary to try it.

6
Chapter 1 Introduction

If you worry that others will see you as stubborn, I assure you, that is
not what I am advocating. This book is only a collection of knowledge that
can improve your skills. The rest depends on how far you want to take it in
practice.

Desire Behind Perfectionism


Perfectionism, as described in this book, suits those people who want
to build software that always works and does not break. While I consider
this to be the mission of every developer, I understand that not everybody
shares this vision.
Nevertheless, to better digest the material in this book, you need to
adopt the proposed mindset. Afterward, everything I present will make
more sense.

Is It Worth It?


A commonly asked question around effective software is whether it is
worth the trouble. Is it not easier to build yet another system that works
more or less okay, breaks occasionally, and gets fixed when we need it?
From my experience, when techniques to develop ideal solutions
become part of our professional habits, building effective software
becomes no more difficult than writing any other program. From that
point on, we save a considerable amount of time on every aspect of
development, and we achieve customer satisfaction by delivering more
with less. Eventually, we become the winners compared to other software
projects that encounter overhead in every area where we are leaner.
So, yes, purely mathematically, it is worth it. The key is to judge the
worthiness based on a long-term advantage compared to other projects
and not only based on the volume of short-term efforts.
The objective is also easy to understand; we only speak about six
basic ideas.

7
Chapter 1 Introduction

Six Pillars of Effective Software


When I tried to define what I do daily, I discovered the six pillars of
effective software, as follows:
1. Meet users’ expectations.

2. Allow no defects.

3. Scale out horizontally.

4. Have no dedicated production support team.

5. Accelerate development pace.

6. Double the ROI per developer, team, and software.

While these pillars express the intent, they can also create confusion,
disagreement, and resistance. This split in opinion happens because
each of us is unique, and we look at things differently. Some will say that
the problems I try to fix do not exist at all; others will say that there is no
solution to them, or that I am not solving the right issue.
To align our vision, I want to clarify what each pillar means.

#1. Meet Users’ Expectations


This pillar is trying to solve any of the following problems:

• Developers closely follow requirements that the


domain experts write, but customer satisfaction still
keeps dropping with every release.

• Developers write software by using all the modern tools


and technologies, but the program is impractical to use
by the end users.
• Developers do not fully understand what domain
experts want, and there is a constant challenge in
collecting knowledge.

8
Chapter 1 Introduction

#2. Allow No Defects


For a start, let us agree that defect-free software is a reality. I have often
heard that engineers treat defects as a regular thing. At times this is due
to not knowing how to avoid bugs; in other cases, they consider finding
and fixing mistakes to be the optimal way to produce an application. I
will address the former opinion throughout this book (i.e., the means to
achieve a defect-free program). The latter view cannot be valid as bugs are
nothing but overhead. Specifically:

• Developers need to go through context-switching


multiple times. First, when they need to fix a suddenly
found bug urgently, and then again when it is resolved,
and they need to turn back to feature development.
Context-switching is a waste that burns time and
resources.

• Every defect must be discovered, documented,


prioritized, planned, assigned, investigated, fixed,
verified, tested, possibly automated, and tracked to
eventual closure.

• Developing new features in a system full of defects is


more complicated than doing so without defects. Bugs
require special treatment, workarounds, and tricks.
Also, broken functionality irritates those who often
encounter it—developers.

If not for all this overhead with defects, you could focus more on new
feature development. Furthermore, defects create discontent for both the
customers and the developers.

• Bugs often mean a broken user experience, which is a


frustration for a consumer of a program. It is a negative
hit on a company’s reputation too.

9
Chapter 1 Introduction

• Fixing defects is not the most favorite task for


developers. They would rather be writing new features.
We all understand this very well.

Do not be confused; there can still be defects caused by something


other than code; e.g., missing content on a page is an authoring issue if the
content is dynamically configurable.
This book will teach you how to avoid code defects specifically. It will
also provide guidelines on how to prevent other kinds of bugs on a case-­
by-­case basis, but more emphasis will be placed on code defects.

#3. Scale Out Horizontally


I will discuss and address scalability issues in two different contexts—first
in software and then in a development process.
With more users and customers, you should be able to deploy more
copies of your application and sufficiently handle the increased traffic.
That is horizontal scalability of software. Incorrect architectural or design
choices made earlier can hijack an ability to scale horizontally later.
Vertical scalability would mean to increase server memory again and
again until you reach a limit and cannot scale anymore. Hence, horizontal
scalability is much preferred as it has no such boundaries.
With a need to solve different business problems, you should be able to
form new teams and evolve systems and organizations organically. That is
horizontal scalability of a development process. Various things ranging from
incorrect code design to improper requirements management can affect
the ability to scale horizontally.
Vertical scalability would mean increasing the size of a single team
until the members of it started spending the entire day on communication
overhead, every day. So the horizontal scale is preferred since vertical
scalability amplifies costs.

10
Chapter 1 Introduction

#4. Have No Dedicated Production Support Team


Issues in the production environment often become so frequent that you
need to hire a dedicated production support team. This situation seems
quite ordinary when it happens.
It is possible to avoid that additional cost overhead by employing
proper tactics, which we will discuss in this book.
Let me clarify—I am speaking about a technical production support
team and not about a customer-facing support group, which you may still
need to understand end users’ concerns or to answer their questions in an
online setting.

#5. Accelerate Development Pace


Have you noticed how software development becomes more cumbersome
and slower over time? That is a typical pattern in most of the companies
and teams that develop software nowadays. It does not have to be that way.

# 6. Double the ROI per Developer, Team,


and Software
If you achieve all the previously mentioned elements, guess what happens?
You get more for the same amount of investment (imagine “buy one,
get one free”), or you get the same for less investment (imagine “50% off for
members perpetually”).
This item is an outcome of applying the approaches described in this
book. It has become part of the “six pillars” to explicitly emphasize the
business advantage that you gain.

11
Chapter 1 Introduction

Summary
This was quite an introduction. We glanced at both the hesitations and
enthusiasm behind building effective software and what it is that we aim to
deliver.
In the next chapter, we will look at commonly overlooked subjects vital
to delivering needed outcomes, such as leadership, people, and culture.

12
CHAPTER 2

Cross-cutting
Concerns
Building effective solutions is not only about writing code or architecting
systems; this process relies heavily on leadership, operations,
organizational structure, and even internal politics. Ignoring these vital
aspects is comparable to dismissing the weather forecast when predicting
the quality of harvesting season.
Experience has proven that an effective technology transformation
has to be driven by leadership. No matter how hard engineers try, their
attempts will not suffice against a wall of political resistance. Hence,
I will start this chapter with recommendations applicable to leaders and
managers.
After leadership accepts the importance of their role in the act of
producing high-quality software, it is time to rethink other supporting
factors for positive outcomes. The organization’s shape and processes
within it must aid the optimal flow of information, growth, and scale; this
reasoning puts the mentioned topics on our radar. Finally, we will drill into
culture and people as they are essential constituents of organizations. This
thread of thought guides the structure of the chapter.

© Tengiz Tutisani 2023 13


T. Tutisani, Effective Software Development for the Enterprise,
https://doi.org/10.1007/978-1-4842-9385-0_2
Chapter 2 Cross-cutting Concerns

Execution, Leadership, Management


Let’s first set some expectations for the leadership and management of
software engineering organizations in the context of transformation.

Importance of Software Development


Transformation
The technological world has changed 180 degrees since its inception.
Nevertheless, many organizations that formed during the early days have
not changed much since. It has become critical that these companies
transform and adapt to the newly established environment. If they cannot
revolutionize, their existence will soon be at risk due to their lack of
competitive advantage.
The need for transformation is also relevant to building software. To
appreciate what has happened in this field, let us recall that a couple of
decades ago, engineers did not write unit tests, there was no open source
community, and there was no such specialty as “Tester” or “QA.” Big waves
of breakthroughs have taken place in software development, architecture,
distribution, and scalability.
Therefore, it is highly critical that every engineering organization
transform and conform to today’s standards and demands.
Companies that are just forming should ensure that they meet modern
software development standards. Those that have existed for a while need
to transform at the earliest possibility.
If transformation does not take place, produced software will not
be worth the trouble. You will have to invest in building programs twice
as much as your competitors due to lower quality, higher human and
technical resource costs, decreased customer satisfaction, and so on.

14
Chapter 2 Cross-cutting Concerns

 ow to Achieve Software Development


H
Transformation
Transformation is a very complex task. In simple words, nobody comes
to their everyday job and says, “We will do things differently from now!”
Even if somebody says these words, things do not change overnight. This
problem is relevant for any size and kind of organization or team.
Furthermore, the quicker the transformation is, the better the
outcome. If it takes a long time, we risk playing a catch-up game forever,
because the target keeps moving while we slowly change. In such a case, it
also increases costs since our focus is on implementing changes instead of
executing an established business model. This stretch can result in losing
to competition or having an inability to gain an advantage over others.
The leadership of software development organizations should seek
ways to achieve transformation in the shortest time with the practical steps
and durable outcomes. Here is one technique that I recommend to reach
this objective:
Find an expert or group of experts that can assess your current situation,
lay out a transformation plan, and deliver it in a discrete timeframe. Give
them the power and right to execute. Follow their guidance and get to the
finish line together. Keep the experts accountable for delivering promised
results.
This approach is just one of the options, but the focus is on the timely
execution of a transformation to avoid getting into the never-ending
catch-up game.

Transformation Is for Everybody


At the time of this writing, many organizations are attempting to
accomplish an Agile or other technology transformation. Here is how
they typically approach this task: Management comes to developers and

15
Chapter 2 Cross-cutting Concerns

tells them about “new rules.” In a couple of months, engineering groups


learn how to be agile or follow best practices in the industry. Despite this
change, these companies do not see significant improvements in their
revenue or quality of work. Consequently, management declares that
transformation did not make any visible changes, and hence there is no
real value under such initiatives. This statement is inaccurate, as there are
other explanations behind the described failures.
Let me ask a simple question: What was management doing when
development teams were going through the proposed transformation?
Turns out, they were watching from the side! If changes touch only the
bottom of the company and its top continues operating as before, we
naturally end up having incompatible parts trying to work together. This
mismatch is the real reason for failed transformations!
Therefore, if you want to go through an Agile or other technology
transformation, tackle this goal throughout the company. Transform both
leadership and development teams, and not only one side of the equation.
Transformation is not an experiment for development teams; it is an
organization-wide strategic initiative, so treat it like one! If leadership is
not ready to change, I recommend not starting the transformation at all;
otherwise, do not be surprised if it fails later.
Here is how you should interpret the preceding recommendation for
Agile and technology transformations:
• Agile transformation must not be limited to applying
modern processes (e.g., Scrum or Kanban) to
engineering teams. Instead, leadership must consider
implementing a large-scale Agile framework such as
SAFe (see [SAFe]), which accounts for transforming
leadership too.
• Technology transformation must not be left up to only
engineering teams, because typically developers do
not have enough power and influence to modernize

16
Chapter 2 Cross-cutting Concerns

solutions across companies. Instead, leadership


must actively participate in changes by coaching and
mentoring people to follow the new guidelines. An
example of such a support is a letter from Amazon’s
leadership that promoted API strategy when the
company needed this improvement across all teams
(see [APIE AIAPI]).

Ad-Hoc Tasks vs. Process


Building high-quality software takes focused and consistent work that
represents a repeatable process. Context switching at unplanned points
should be avoided as it often delays deliverables, makes mistakes possible,
and decreases employee satisfaction.
Management or other stakeholders often come up with ad-hoc tasks
for engineers. They sometimes directly call a developer and ask them
to fulfill a specific request. An employee has to put aside their previous
assignment and work on this new task immediately. This approach creates
context switching, so I want to make managers and stakeholders aware of
the undesired outcomes.
Managers and stakeholders are advised to refrain from hijacking an
established software development workflow with their ad-hoc tasks. Instead,
their requests should go to a product owner or a project manager (or to a
person carrying a similar role in an existing process). These tasks will be
prioritized to be worked on later, as the schedule allows.
If you work in iterations, then the newly submitted task can be fulfilled
in the next sprint. For other processes, it can be queued after the work that
is currently in progress.

17
Chapter 2 Cross-cutting Concerns

H
 ands-on Leaders
Management often steps back and allows their teams to thrive and show
what they can do. This attitude helps give opportunities, but it can also
put people under pressure if the outcomes are critical to the organization
or the employees. If something does not work, now it is their fault, even
though they worked hard, while leadership stood aside.
On the contrary, I have also seen managers who want to make
all decisions themselves but fail to do so correctly. For example, one
manager, who had a great personality but lacked technical skills, would
not care which architectural choice was better (he did not understand
the importance of architecture at all) and picked one out of thin air. This
person put the project on a failure path, and in the end the developers
were seen as guilty again. Those engineers who think that the “boss is
always right” will probably never agree with the described issue, but such a
leadership style still has to be addressed.
Management should take development, improvement, and
transformation goals seriously. If leadership wants to get there, it will not
happen without their support. This section is a call not just for managers but
also for the hands-on leaders who can execute an IT organization roadmap
with their teams. They are ready to share responsibility for failure, and they
work as hard as their teams do.
While working with a hands-on leader side by side, engineers feel
empowered to deliver better-quality software that meets and exceeds
customers’ expectations. Also, they are motivated and feel like they are
part of a team. If success can only be planned, who can do it better than a
manager who influences their entire organization?

18
Chapter 2 Cross-cutting Concerns

Overall Support from Management


Recommendations from the previous sections by no means represent all
support that people need from their managers. Leaders should understand
organizational goals and aid their teams in getting there efficiently. In this
book, I will try to capture all steps of this journey. Management will need
to be familiar with this information to help their organizations succeed
and, more important, to transform them together.
Besides management, the organizational structure also impacts the
subject of this book, so it is our next big topic.

O
 rganizational Structure
In this section, I will draw a line between the organizational structure and
the optimal software engineering processes. This link may be non-obvious
out of the box. Hence, making it an explicit matter will help address this
book’s objectives.

A Couple of Important Definitions Upfront


In large, modern IT organizations, we typically have many teams and
applications and an elaborate graph of requirements. If we are not
careful when forming or managing such environments, we can introduce
unintentional overhead that can create complications and slow down a
significant portion of the company. In smaller organizations, these same
problems can quickly occur with growth if we do not plan properly ahead
of time.
Before I clarify and break down the described problem in the
next sections, it is essential that you understand the basic concepts of
subdomains (see [Evans DDD]), bounded contexts (see [Evans DDD]),
and microservices (see [Fowler Microservices]). I will base several

19
Chapter 2 Cross-cutting Concerns

important suggestions on these terms as they help define boundaries for


applications, systems, and subsystems. In this context, boundaries are
more important than what is inside them.
Make sure to familiarize yourself with these concepts before we go any
further. If you are already familiar with them, then let me quickly recap to
refresh your memory:
• A subdomain is a part of an overall problem that an
entire organization solves. For example, an established
brand can have a subdomain of “Sales” that expresses
how it sells its products online.
• A bounded context is a boundary within which a
specific terminology makes sense. A meaning of a given
phrase can change when looking at it from another
bounded context. For example, the word “Order”
within the “Sales” bounded context means a purchase
request received from a customer, while within the
“Procurement” bounded context, it represents an
intention to buy parts or equipment from suppliers to
compose a product.
• A microservice is a small-size application with well-­
defined boundaries.

F orming Organizations
Technology organizations often form chaotically—people do not
understand what problems their team or an entire company solves, how
they relate to each other, which project has a higher priority, and so on.
These knowledge gaps create many inefficiencies, such as making non-­
optimal decisions about systems, subsystems, and overall enterprise

20
Chapter 2 Cross-cutting Concerns

architecture; slowing down or hijacking the company’s success; or


misrepresenting the employer’s interests when delivering technical
solutions. These issues can affect many of the mentioned quality pillars,
including the ability to meet customers’ expectations.
Therefore, form an organization from top to bottom (as in architecture
and decomposition of the domain, not as in management). Define an
overall company-wide problem domain, then divide it into subdomains,
and divide each of them further, until there are no hidden subdomains in
any of the defined subdomains (see Figure 2-1). Document and popularize
this information so that members of the organization can speak to it.

Figure 2-1. Distilling subdomains within an overall organization


domain

When knowledge about the subdomain hierarchy gets into the hands
of the organization’s members, they will use it as a tool to solve business
problems, find their paths through complex flows of the field, correctly
prioritize projects and requirements, and so on. Overall, you will receive
higher employee engagement and satisfaction levels. Also, meeting
customers’ expectations will become more achievable for people in the
organization.

21
Chapter 2 Cross-cutting Concerns

Do not run this exercise mechanically. Instead, pay attention to the


boundaries of each subdomain. Ask yourself critical questions: Is it a
well-defined, cohesive problem? Is it an independent domain from other
subdomains? Does it serve the needs of a parent (containing or nesting)
subdomain?
Also, do not use factors besides business knowledge to identify
subdomains. For instance, it is a bad idea to use a project funding model or
professional specialties (developers vs. testers vs. project managers) to define
subdomains. You need to be solving business problems, and all else should
serve the same purpose, instead of fitting business objectives under unrelated
concerns. Otherwise, the formed organization will be helping the company’s
internal needs only rather than serving the needs of end users and customers.

F orming Subsystems
In engineering organizations, new software projects often start randomly
and maintain an unclear nature throughout their lifetime. Usually, each
new project aims to deliver a new subsystem. Still, clarity is missing about
boundaries, cohesiveness within its borders, relationship with other
subsystems, business value compared to other subsystems, and so on. As a
result, the project runs heavier and slower than it could due to unresolved
technical conflicts, incorrect implementations that require a rewrite in
the early days, and sometimes even duplication of effort among various
subsystems.
Therefore, treat each subsystem (both existing and new) as a bounded
context. Identify and document existing bounded contexts. Draw a context
map (see [Evans DDD]) outlining relationships between bounded contexts
as well as their related subdomains. Decide where the new bounded context
fits, which subdomain it will serve, and the ties it will have with other
bounded contexts (see Figure 2-2). Get in touch with teams that own the
existing bounded contexts and ensure that the planned rollout of the new
bounded context fits the overall picture (i.e., context map).

22
Chapter 2 Cross-cutting Concerns

Figure 2-2. Forming bounded contexts within subdomains

A well-understood and documented context map is an excellent tool


for software architects and engineers to help solve their everyday needs in
typical IT organizations (and ideally, beyond IT as well) while integrating
with other subsystems, prioritizing requirements, planning proper
implementation strategies, and so on. As a result, you have highly scalable
development processes, less complexity and thus acceleration, clarity on
relations between business and technical requirements, and so on.
Do not form subsystems just for the sake of having them. Randomly
defined systems usually cause confusion, misinterpretation, and misuse
among engineers and architects. This randomness will create a slowdown
and challenges to meet the users’ expectations. Also, such approaches
will affect your ability to scale processes horizontally. Choose natural,
business-defined boundaries instead of mechanical boundaries.
Otherwise, you will introduce complexity, and somebody will have to deal
with it.

23
Chapter 2 Cross-cutting Concerns

F orming Microservices
Microservice is a comparably new term that has many definitions
depending on the source of information. Historically, it is a refined form
of SOA (Service Oriented Architecture, see [Wiki SOA]), and hence some
people call it a “granular SOA.” While we all understand that microservices
architecture involves building interconnected services, it is easy to miss
the importance of defining proper boundaries. If you view a microservice
as nothing other than a mini-service and try to apply this pattern to your
work, then you will end up building an arbitrary number of services that
integrate based on mere technical convenience only. When you form
such systems, it is hard to see the point of using this architectural style
altogether, except maybe for the sake of the buzzword. No architecture has
the right to exist without clear business benefits, and there must be some
benefit to microservices too.
Define a microservice to implement a bounded context and maintain a
one-to-one relationship between the two. Use these terms interchangeably,
and adhere to the same boundaries for both of them. Use this mapping to
clearly express a business value behind a microservice—it is a subsystem
that solves the problems of a subdomain, just like a bounded context does.
Following the shapes of bounded contexts helps you implement
microservices in the right way out of the box because you have the
form established and it is well understood by both the business and the
technical people. On the contrary, incorrectly defined microservices create
all sorts of problems, such as a lack of technical scalability, integration
complexity, mental complexity, failing to meet users’ expectations,
and so on.
Later in this book, I will come back to the microservices topic from a
technical architecture standpoint. In the current section, I only wanted to
outline the relationship between microservices and bounded contexts.

24
Chapter 2 Cross-cutting Concerns

F orming Teams
Software development teams often deal with an overhead of
communication, conflict of interests, shared codebases, shared production
releases, and so on. It is easy to notice that the cost comes into the picture
when one team has to share something with another. On the other
extreme, an independent group has the luxury of moving as fast as they
want without worrying about dependencies on outside counterparts.
How can we maximize the number of autonomous efforts in an
organization that has multiple teams? As it turns out, the solution is easy to
explain after we have learned about context maps and bounded contexts.
The trick is to form teams around bounded contexts. Allow a group to
own one (which is ideal) or more bounded contexts, but do not allow more
than one group to hold ownership of any given bounded context (see
Figure 2-3). Help team members understand bounded contexts and
subdomains that they own and with which they interact. Ensure that people
integrate bounded contexts according to their connections on the context
map. Otherwise, the context map needs to change to express necessary
knowledge.

Figure 2-3. Forming teams to own bounded contexts

25
Random documents with unrelated
content Scribd suggests to you:
question of criticism. The simple programme of “stirring up the
people to uprisings and rebellions against the existing régime, in
accordance with varying local circumstances,” was in consonance
with her fiery temperament, impatient of all restraint.
Her three friends were also interesting characters, and I soon had
opportunities of talking to them and hearing the story of their
connection with the movement. First came the young Sophia
Bogomòletz;[67] her maiden name had been Prìsyetskaya, and she
was the daughter of a rich landed proprietor in the government of
Poltava. She had attended a higher grade school for girls, and later
the medical course in Petersburg; had married a physician, and then
—like Maria Kovalèvskaya—had left her husband and child to devote
herself entirely to revolutionary work. In 1880 she was arrested as a
member of the South Russian Workmen’s Union and sentenced to
ten years’ penal servitude. She attempted to escape,[68] but was
recaptured, and was then given five years more, which was again
increased by a year in consequence of a dispute with an official.
Besides this she was placed in the category of “on probation”
prisoners, which means, as I shall explain later,[69] that the term of
actual confinement in prison is lengthened. She, too, was by nature
an advocate of revolt, and throughout her imprisonment kept up a
constant feud with the officials. She went even farther than her
friend Kovalèvskaya, for while the latter only fought against injustice
and tyranny, Sophia Bogomòletz looked on all prison officials as her
natural enemies, and held even the smallest compromises, such as
most prisoners are obliged more or less to give in to, as unprincipled
and inadmissible; for example, she looked upon the medical
examination of prisoners as a personal insult. She was influenced by
no considerations of health, and was always prepared to risk her
own life, if she judged there was any reason for doing so. The staff
simply trembled before her, for they knew that their only means of
extorting submission—the fear of punishment—was here of no avail.
The story of the third member of this little band was as follows. In
the spring of 1879 the sum of 1,500,000 roubles was stolen from the
offices of the Finance Department in Kherson, the depredators
having broken in through the wall of the adjoining house. On the
same day the police arrested a woman driving through the town in a
country cart with some suspicious-looking sacks. The woman was
identified as Elena Ròssikova, wife of a landed proprietor in the
neighbourhood, and the sacks contained a million roubles. With her
another lady was also arrested; and in consequence of the latter’s
confession the rest of the money was found, with the exception of
some 10,000 roubles. It turned out that this wild undertaking had
been organised by Elena Ròssikova, who had planned to rob the
imperial purse, with the intention of applying the money to
revolutionary purposes. She and some other persons implicated
were tried before a court-martial, and she, as the ringleader, was
sentenced to penal servitude for life. She, too, waged unceasing war
against the whole staff of the prison, and was daunted by nothing
when a “protest” was in question.
The fourth of these women “politicals” was Maria Kutitònskaya.
She had been a pupil in a girls’ school in Odessa, and while still very
young had joined the revolutionists. In 1879 she was arrested as a
comrade of Lisogùb[70] and Tchubàrov, was condemned to four years’
penal servitude, and sent to Kara. At the expiration of her sentence
she was interned in the town of Aksha in Transbaikalia; but she was
soon back in prison. The authorities had ill-treated the male
prisoners in Kara (as to which I shall speak later); and Kutitònskaya
resolved to take vengeance on the chief offender in the matter, the
governor of the province, Ilyashèvitch by name. She fired a pistol at
him, but missed. The court-martial condemned her to death, but this
was altered to lifelong penal servitude.
Beautiful and distinguished-looking, with fair hair, and gentle,
winning manners, Maria Kutitònskaya won hearts by the score. While
she was under trial for the attempted assassination of the Siberian
potentate she was subjected to the most cruel and inhuman
treatment; thrown into a damp, gloomy dungeon, and allowed only
bread and water. Help came to her from the ordinary convicts, who
had seen her in the prison, and worshipped her; they brought her
food at great risk to themselves, and did her various other services.
These criminals had changed her name a little to suit themselves,
and always called her “Cupidonskaya”; having thus unconsciously hit
on a charming pet-name for the beautiful woman. But for their
assistance she might not have survived her treatment at that time;
as it was, her long imprisonment undermined her health, and she
became a victim of lung trouble, to which she succumbed in 1887.
CHAPTER XXI
THE CHIEF OF POLICE AT IRKUTSK—MEETING WITH EXILED COMRADES—FROM
IRKUTSK TO KARA—STOLEN FETTERS—A DUBIOUS KIND OF DECABRIST—
ANOTHER CONTEST—ARRIVAL AT OUR JOURNEY’S END

The detailed narrative of all that these women had gone through
impressed us greatly; for their sufferings had been severe, and often
caused by the most paltry tyranny. The wonder was that they had
ever been able to hold out. Our indignation against the chief of
police, under whose auspices this sort of thing had gone on, was
naturally roused to such a pitch that we longed for an opportunity to
testify our abhorrence of his conduct. This opportunity was soon
forthcoming. A higher official from Petersburg, who was inspecting
Siberian prisons, came one day with his suite into our cells, and the
chief of police was in attendance. The moment he entered, Làzarev,
our head-man, went up to him, (in accordance with a predetermined
agreement of our party,) and said in loud and distinct tones—
“We are astonished at your impudence in daring to appear before
our eyes, after having by your treatment forced our women
comrades into a terrible hunger-strike.”
The whole company of our visitors hastily took their departure, to
the tune of our comments and ejaculations, which contained nothing
flattering to the evildoer! No untoward results followed our action,
and the ladies heartily rejoiced at this humiliation of their torturer.
From these four we heard much about the conditions of life in
Kara, our appointed destination; as also from another comrade now
in Irkutsk, who could give us his personal experience of the prison
there. This was Ferdinand Lustig—formerly an artillery officer, and
afterwards a student at the Petersburg Technological Institute—who
had been sentenced in 1882, in the case of Suhanov and Mihaïlov, to
four years’ penal servitude. He had now ended his term in Kara, and
was going to be interned elsewhere, under police supervision. What
he told us was not comforting: the régime was severe, and the
governor of the political prison—a captain of gendarmerie, named
Nikolin—of the worst repute.
Four of us only were to travel eastward together: Maria
Kalyùshnaya, Tchuikòv, Làzarev, and myself. The other seven were to
be sent to various places in the government of Irkutsk; and the
nineteen-year-old Rubinok, whose sad case I have already
described, was to go northward to the deserts of Yakutsk.

At the end of September we started, in company with a party of


ordinary prisoners. We had now before us a journey of some twelve
hundred versts (eight hundred miles), which would take at least two
months. Winter in Siberia begins much earlier than in other places of
the same latitude, even in European Russia, and therefore we had to
expect many hardships. In two days the last steamboat was to start
for Listvinitchnaya, across Lake Baikal, and if we missed that we
should have to winter in Irkutsk.
The tempestuous Baikal treated us kindly on the whole, though
usually the autumnal storms are a real danger to voyagers on its
waters. It is often asserted that the scenery of its shores rivals that
of the Swiss mountain lakes; and without myself instituting any
comparison, I can vouch for it that the impression those magnificent
hills made on me was unforgettable.
We had to pass a night at the landing-station on the opposite
shore—Mysovaya; and we had been already shut into our prison,
when the grating of the lock again sounded, and the warder brought
in a young lady, who came straight towards me.
“Sonia!” I cried, in joyful surprise, as I recognised in her Sophia
Ivànova, a dear friend whom I had not seen for six years. Like
Sophia Perovskaya, Vera Figner, and other prominent women of the
terrorist organisation, she had joined the new party of the Naròdnaia
Vòlya in the autumn of 1879, when the society of Zemlyà i Vòlya
(Land and Liberty) was dissolved. It was just during that transition
period that I became acquainted with her and with other Terrorists;
and shortly after, in January, 1880, she was arrested in Petersburg,
where she had been assisting at the secret printing-press whence
issued the organ of the party, named like it, Naròdnaia Vòlya (The
People’s Will). At the time of the arrest an armed resistance was
made, in which Sophia Ivànova took an active part, for which she
was condemned to four years’ “katorga.”[71] This sentence having
been fulfilled, she was now being sent for internment into the
government of Irkutsk.
We were both heartily rejoiced at seeing one another again, but
our meeting could be only a brief one; the steamboat was to start
almost directly on its return journey, and Sonia could not miss it. We
hurriedly exchanged news of ourselves and of our common friends;
then came our parting, and I have never seen her since. To the best
of my knowledge she is still living in Siberia.

Soon after this we arrived at Verkhny-Udinsk, where—as in most


Siberian towns—the prison was filled to overflowing, and no room
could be found for us “politicals.” The sergeant (in Transbaikalia the
convoys of prisoners are always commanded by a sergeant, instead
of by a commissioned officer, as on the previous part of the journey)
took us on to the police-station. As, however, it was late the place
was all deserted, and no official could be found, which disturbed the
sergeant no whit; he simply left us there by ourselves in the office,
with unbolted windows and doors, and went his way. We also were
free to go or stay as we pleased, and were rather surprised at his
calm way of solving the difficulty. But the man knew what he was
about. It was true enough that we could walk off without anyone
being the wiser; but what then? It was, indeed, always easy to
escape from prison here; but it was well-nigh impossible to get any
further. Elizabeth Kovàlskaya had twice escaped from prison in
Irkutsk (once disguised as a warder), but on both occasions she was
caught before she had left the town; and if she had found
concealment impossible in a relatively big place like Irkutsk, with all
the allies and money she had at command, the case must certainly
have been hopeless for us, strangers, in a little hole like Verkhny-
Udinsk. Still, it was a curious feeling at the time, as I well remember,
to know oneself free and under no kind of observation, and yet to be
so helpless. We finished by waxing restive and miserable over the
trap we were in.
In this place we met another comrade on his way from Kara, going
off to be interned elsewhere. This was Steblin-Kamensky,[72] whom
his wife voluntarily accompanied. They had been too late for the
steamer, and were now obliged to wait in Verkhny-Udinsk till the way
again became open—three or four months probably. During that
time he was at liberty to go about in the place as he pleased, and
naturally we spent together the two days of our sojourn here,
Kamensky telling us all he could of life in Kara. He was a brilliant
talker, and described with an inexhaustible flow of humour the
doings of our comrades in every particular. True, our laughter over
his stories was mingled with much sorrow and indignation, for what
he related was often sad enough. He told us of the bitter hardships
inflicted on our comrades by an inhuman gaoler, and he described
Captain Nikolin, in command over the penal settlement for
“politicals” at Kara, as a malicious, ill-natured man, continually
devising petty humiliations for the prisoners.
These various comrades, from whose personal knowledges we had
information about Kara, all made the same impression upon us. They
bore the stamp of their long imprisonment; their voices were muffled
in tone; anxiety, deep and constant, was painted on their faces; the
hair of nearly all, despite their youth—hardly any had reached thirty
—was prematurely grey. But discouraged and broken-spirited they
were not; or at least with one or two exceptions only. Very few of
them could regard the future with any hopeful feelings for
themselves personally. Long years of exile lay before them, doomed
as they were to vegetate in some forsaken corner of Siberia, victims
to all sorts of hardships, far from friends and civilisation. To many it
seemed questionable whether their future lot might not be more
dreary than prison life itself. Yet even the semblance of freedom
attracted them—a doubtful freedom certainly, for the exiles, or
“colonists” as they are called, are subject to a thousand and one
restrictions at every turn.
I met one only who looked forward with a steadfast confidence in
the bright side of things, and this notwithstanding the fact that he
was bound for the worst part of Siberia—the government of Yakutsk.
Ivan Kashintsev[73] was then only twenty-five, and full of youth and
high spirits; he declared to me, on the occasion of our meeting at
one of the halting-stations (we already knew each other), that he
meant to escape at all hazards. This, in fact, he accomplished later,
and he is now living abroad.

Before those who were released from prison, to live in exile under
police supervision, reached their appointed destinations, they had at
that time many difficulties and delays to encounter. We ourselves
went at a snail’s pace on our way to Kara, but prisoners coming
thence progressed far more slowly. They had to wait at nearly every
halting-station until some convoy on the homeward journey could
pick them up and take them on for a certain part of the way, and
sometimes they were kept in this manner nearly a week at a station.
On an average they barely made five versts a day, and when the
distance they had to travel was some hundreds or even thousands of
versts, the journey might take months to perform.
At each meeting with comrades on the return journey from Kara, I
could not help thinking of my own future, and saying to myself,
“What will you feel like when after long years you tread this path
again? Or, indeed, will you ever tread it?”

One day I found I had sustained an odd loss: someone had made
off with a bag in which I kept some of my belongings, the chief item
among them being my fetters! I had to make the somewhat curious
confession to the commanding officer that, instead of wearing my
chains, I had allowed them to be stolen; and I was rather surprised
that, while commiserating me on account of my personal losses, he
did not seem at all agitated about the loss of the Government’s
property.
“What am I to do without my fetters?” I asked him, when I saw
that the absence of this important detail in the attire of a convict left
him unmoved.
“Well, of course we must get some for you somehow,” opined the
officer. “Just wait a moment; there ought to be things of the kind
lying about somewhere.” And he gave the sergeant orders to look in
the lumber-room, where a new pair of fetters was discovered.
“Take care you don’t lose these!” said the officer, as I packed them
among my luggage.
This is a specimen of the indulgent, almost fatherly demeanour
which our guardians more and more assumed towards us as we got
further east.
We were by this time in the thick of the Siberian winter and its
severities. We had passed the Yablonovoi mountain ridges, and were
nearing Tchita, the capital of Transbaikalia. At the last station before
our arrival there we observed a great bustle going on among the
ordinary prisoners; the sergeant and the soldiers were occupied with
them all night, continually going in and out in a quite unusual
manner. We racked our brains to imagine what could be on foot; but
the riddle was only solved next day, as will be seen further.
Although the distance from Tchita was considerable for one day’s
march,—about forty versts (twenty-six miles), I think,—we started
very late on the following morning; but after about twenty versts’
march we came to a lonely farmhouse, standing all by itself on the
high-road. We had heard from our comrades who had been in Kara
that an old man lived here who gave himself out as a Decabrist.[74]
Our party halted in the courtyard, we “politicals” were shown into
a room, and the master of the house presently paid us a visit. He
introduced himself by the name of Karovàiev; and was a vivacious
old gentleman, of eminently respectable appearance. According to
his account of himself he had been an ensign in the Guards, had
taken part in the revolt of the Decabrists, and had been exiled to
Siberia; he claimed to be eighty years of age, but did not look more
than sixty-five. He made himself very agreeable, and was most
anxious to show us hospitality, declining to take any money from us.
Meanwhile in the next room and the corridor things were very lively;
there seemed to be a sort of combined market and feast going on,
soldiers and convicts eating, drinking, and hobnobbing together like
boon companions.
It was already dark when we arrived at the gates of the prison in
Tchita, where we had at once to engage in a struggle with the
governor: first, because he received the ordinary prisoners first,
leaving us to wait; and next, because he gave us a room which was
absolutely unfit for us to spend the night in. Only after we had made
a great fuss, and threatened him with complaints, did he give us
proper accommodation.
Next day, when the party was mustered for departure, it became
apparent that the ordinary prisoners had hardly any clothes! Their
things had vanished, and they were literally half naked. A light was
now cast on the events of the preceding night, when there had been
such a carousal at the house of the Decabrist. That respectable and
hospitable old gentleman was evidently in league with the escort,
and had provided the convicts with vodka and other delicacies, in
exchange for their clothing, which no doubt he had obtained at a
bargain. That the transaction might not be discovered before our
arrival in Tchita, the soldiers saw to it that it should be as late as
possible before we got in, so that the inspection should be gone
through hurriedly, and the absence of the clothes not perceived.
In short, the respectable Karovàiev had not established himself in
that lonely spot for nothing. The jollification of the unlucky criminals
had evil consequences for themselves. In proportion as their clothing
and other State property were deficient they were treated to the
soundest of thrashings; and only when that had been administered
did they receive a fresh outfit.
In Tchita we had to part from our good stàrosta Làzarev, who was
to be interned here. We three others determined to secure for
ourselves a thorough rest in this place; for we had been six weeks
on the march from Irkutsk, and were thoroughly tired out. We felt in
no hurry to go on; a prison awaited us, while on the journey we had
at least a certain amount of freedom and variety. Moreover, we knew
that there were a number of our comrades interned at Tchita, and
we should be able to see something of them; while apparently all
intercourse with the outer world would cease for us after this stage,
where we must make our last adieux before the prison doors closed
on us. We therefore reported ourselves sick, and easily got the
prison doctor’s consent to our breaking the journey here; which
meant that we should be picked up by the next convoy in about a
fortnight’s time. Our comrades paid us frequent visits; that is, they
came to the prison gate when we were in the courtyard. The most
interesting news they gave us concerned the travels of the American
writer, George Kennan, who had just arrived in Tchita on his return
journey from Kara; and our friends were full of praise for that
excellent man.
During the last days of November we started again, this time in
company with a so-called “family party” of ordinary prisoners—
women and children as well as men going forward to prison and
exile. There had not been much snow that winter, and instead of
sledges two-wheeled carts were our means of transport, travelling in
which was a positive martyrdom. The cold became more intense
every day, and tried us severely, although we wore every warm
garment we possessed, so that we moved with the greatest
difficulty. The only way to keep warm was to march beside the carts,
and one can imagine the sufferings of the unfortunate children who
were accompanying their parents into this inhospitable desert. One
longed for the next halting-station and for possibilities of warming
oneself, which even there were not always all that could be desired.
The halting-stations had sometimes not been heated for a good
while, and the ordinary prisoners had first to chop wood with their
numb and frozen hands; even then there was not always sufficient
fuel. The stoves, too, were often out of order, and smoked so badly
that to stay in the room was a misery. It happened repeatedly that
we three “politicals” were accommodated in a peasant’s hut, and
sometimes the whole party had to be quartered in like manner. We
were always glad when this happened, for the wretchedest cabin
seemed comfortable in comparison with even the best étape. How
often we wished we could be by ourselves in a hut of this kind
during the rest of our imprisonment!

I have said that relations between prisoners and escort were now
very easy-going; strict discipline was no longer the watchword on
either side. This had its disadvantages, the soldiers being often very
rough with the ordinary prisoners. One day, as we were marching to
Nertchinsk, I saw a soldier behaving very brutally to a poor feeble
old convict, knocking him about with his rifle-butt for climbing on to
one of the carts, and apparently only because the soldier had meant
to ride on it himself. I intervened, and called to the sergeant in
command that I should report him for not keeping his men in order.
Next day, as we went through the town on our way to the prison, I
stepped into a sausage shop to buy some provisions, when the
soldier whose party I had left called after me, “Where are you
going? What do you want?” I let him shout, and concluded my
purchases. I then saw that the sergeant had driven on and
disappeared, but I only thought that he had taken some short cut to
the prison and would meet us there, and I was much surprised when
the governor of the gaol received me with the information that the
sergeant had reported me for insulting the guard and leaving the
ranks without permission. I suppose he wished to forestall the
complaint I had threatened him with, about which I had quite
forgotten, and I now turned the tables on him by making it in due
form. The upshot was that the sergeant apologised to me in the
presence of witnesses, and we were respectively pleased to
withdraw our complaints!
At Nertchinsk, Tchuikòv and I were taken to the men’s prison, and
Maria Kalyùshnaya was given a separate cell. I shall never in my life
forget the picture that prison presented. From the dimly-lighted
corridor one could see into the various rooms, where the prisoners
were already lying down, as it was late. Packed closely side by side
they lay not only on the wooden bed-places (which were two wide
shelves running along the walls one above the other), but all about
the floor; there was literally not an inch of vacant space. Most of the
men were clad in shirt and trousers, but many had only trousers on,
and lay uncovered on the filthy floor. The throng was so dense, that
in order to get to the “privileged” room we had actually to step on
the bodies of the sleepers. The stench was pestilential, the wooden
tubs filled with excrement were everywhere about, and as they were
leaky their contents had been trodden over the whole floor. Although
most of the men were asleep, here and there groups of excited card-
players squatted on the floor or the bed-places, and throughout the
whole place there was a deafening babel of sounds. The general
effect was most gruesome, a circle of the Dantean Inferno was the
only possible comparison.
The “privileged” room was also full of people, and we found there
some comrades from Kara—Tchekondze and Zuckermann. They were
lying close together on the crowded floor, and we with difficulty
found a vacant spot, so that we could lie down near our friends.
Zuckermann was known to me: he was a compositor, who in the
middle of the sixties had trudged on foot from Berlin into
Switzerland, where I subsequently had made his acquaintance. He
had gone to Russia later, and had worked at the secret printing-
press of the Naròdnaia Vòlya, where he was arrested at the same
time as Sophia Ivànova. I had been told by comrades how heroically
he had behaved during the trial. In order to shield the others he had
taken all blame on his own shoulders, declared that it was he who
had fired the first shot in resistance to the gendarmerie, and so on.
He had been condemned to eight years’ “katorga” and sent to Kara,
where he had become the darling of the whole prison. Always
sunny-tempered, full of wit and fun, he spread good humour
everywhere; moreover, he was unselfishness personified, ever ready
to help others at his own expense, one of those people who are
called “too good for this world.” Even as we lay on the floor in that
horrible place he told stories and jested, drawing the most glowing
imaginary pictures of his future life in Yakutsk, whither he was being
sent for internment. The reality, unhappily, turned out widely
different from his sanguine prophecies. Poor merry Zuckermann
could not hold out against the hardships and loneliness of his place
of exile, and he put an end to his own life.
Tchekondze I had not met before, but we had many common
friends. He came from Gruzia, and had graduated in the Petersburg
college for artillery officers. With other Caucasians he had then
participated in the Propagandist movement, had been arrested in
1875, and sentenced in the “Trial of the fifty” to banishment; but he
had escaped from Siberia, and had been recaptured and condemned
to three years’ penal servitude. He was now going into exile in
Yakutsk. He impressed one as a strong-willed, careful, practical man,
who would never be at a loss, but would find a sphere of usefulness
under any circumstances; and so indeed he proved in his after life.
The privations he suffered during long years of exile undermined his
health, however. When sent to Western Siberia in the early nineties
he fell seriously ill and died in Kurgan, on the threshold of Europe, in
1897.
At last, on the morning of December 24th, 1885, we arrived at
Ust-Kara, a little village wherein is situated the prison for ordinary
convicts and the prison for women “politicals.” Here we had to part
from Maria Kalyùshnaya, and I saw her that morning for the last
time. Tchuikòv and I had fifteen versts more to travel to Nizhnaya
Kara, where was the prison for male “politicals”; and we had to wait
till next day for the commandant, who received in charge both
ourselves and the ordinary criminals. Our luggage was put into a
cart; and accompanied by a guard, we marched off, having
previously donned our fetters in due form.
It was a frightfully cold day, and despite the chains and our heavy
clothing, we stepped out briskly as though we were in a hurry to get
under lock and key. We knew that this was our last tramp in the
open, that for many long years there would be only a trot round the
prison-yard for us, and our thoughts dwelt dismally on the prospect.
“There is your prison,” said one of the soldiers, and pointed out, a
little way ahead, a stockade made of tall posts set side by side.
Suddenly there appeared coming towards us a group of people—
two women, a Cossack, and a man in civilian dress. “Victor!” I cried,
recognising the latter as we approached nearer. It was my old friend
Victor Kostyùrin, whom I had not seen for nine years.[75] He was now
being removed from prison to his place of internment.
After hasty greetings he introduced me to the two ladies who
accompanied him—Natalia Armfeld and Raissa Prybylyèva, both
“colonists” in Kara. Kennan has given Natalia Armfeld’s story in his
book,[76] and I will only mention here that in 1879 she (with Maria
Kovalèvskaya) was implicated in armed resistance to the
gendarmerie, and sentenced to fourteen years and ten months’
penal servitude. Raissa Prybylyèva had been a member of the
Naròdnaia Vòlya, and had been sentenced in 1883 to four years’
“katorga.”
Victor and I had, of course, much to say to each other, but our
time was short, for our guards naturally did not see the fun of
remaining longer than necessary in the freezing cold of the open
field, and a few brief sentences were all we could exchange.
“A Frenchman would have had a lot to say about this,” I said: “we
two friends meeting on the threshold of a prison, one going in, the
other coming out.”
Another pressure of the hand, and we parted.[77]
“Shall we ever meet again?” I asked.
“Ah yes!” cried one of the ladies. “We shall all meet in Petersburg
at the triumph of the Russian revolution.”
For her, at least, that hope was vain. Natalia Armfeld died at Kara
in 1887, and Raissa Prybylyèva (who married afterwards the exile
Tiutchev) is also no longer among the living. Kostyùrin still lives in
Tobolsk; but since that day our paths have never again crossed.

Tchuikòv and I were now taken to the guard-room, which was


close to the prison. Our arrival was notified; and soon there
appeared, accompanied by some of the gendarmes, the governor of
the prison, an officer of Cossacks named Bolshakov, a man who had
been described to us by our comrades as respectable and humane.
We and our luggage were carefully searched. Of our clothes only
our warm under-garments were left in our possession; everything
else was to be taken to the wardrobe-room, except certain articles
which were reserved that Commandant Nikolin might decide whether
we should be permitted to retain possession of them.
“You need not put the fetters on again,” said the captain of the
guard, Golubtsòv. “They are not necessary here.”
It was evening before we were ready to be taken on by the
gendarmes to the prison—the goal of my long wanderings. Since my
arrest in Freiburg twenty-two months had elapsed; I had travelled
about 12,000 versts (nearly 8,000 miles), and I had visited more
than a hundred different prisons.
“Guard, there!” cried our escort. A bolt flew back with a crash, and
we stepped across the threshold.

MARTINOVSKY STARINKYEVITCH

SUNDELEVITCH ZLATOPOLSKY
PRYBYLYEV YEMELYANOV
To face page 208
CHAPTER XXII
FIRST DAYS AT KARA—FRIENDS OLD AND NEW

We entered a long, dimly-lighted corridor. Close to the door stood


a man in convict dress beside a mighty chest. “Good day,
Martinòvsky!” said I; for although I had never seen him before, I
knew from our comrades’ descriptions that he, being stàrosta,
remained on duty from early morning till late evening by this big
chest, which was the prisoners’ larder. He looked a little surprised at
the greeting, but on our announcing our names a pleasant smile
lighted up his grave features, and he shook hands with us warmly.
“Deutsch goes to No. 2 and Tchuikòv to No. 4!” The gendarme’s
announcement interrupted us. A door was opened, and I stepped
into my room. It was a large apartment; a long table and benches
stood in the middle; round three walls ran the bed-shelves; there
was a huge stove, and three great windows admitted plenty of light.
My new companions welcomed me warmly. There were fifteen
men in the room, two of them—Sundelèvitch and Paul Orlov—being
already known to me from of old. The first question to be settled
was where my sleeping-place should be, and it was decided that I
should lie next to Sundelèvitch, which meant that Starinkyèvitch,
whose place this had been, must find room elsewhere. I found later
that it was a great sacrifice this comrade had made for me, for
Starinkyèvitch was thereby separated from his friend Martinòvsky. In
a room where so many men lived constantly crowded together, the
only possibility of close intercourse and the sharing of intimate
thoughts between two friends was when they lay side by side on the
bed-shelf, and it was only subsequently that I found out what
significance this had in our situation.
When we arrived, supper was already over, but we were given
each a glass of tea with a tiny scrap of sugar, and a piece of black
bread. I was overwhelmed with questions, and was made to tell all
about my arrest, my adventures, and what was going on in Russia.
We chattered, joked, and laughed as only the young can, for except
Berezniàk and Dzvonkyèvitch, who were forty and forty-five
respectively, we were all between the ages of twenty-four and thirty.
I had an odd feeling, as if after a long absence I found myself once
more in an intimate family circle. Time flew, and it was late at night
before I lay down to sleep, spreading on the wooden boards of the
bed-shelf a little mattress that I had brought with me. My journey
from Moscow had lasted seven months; I was sick of moving about,
and now experienced a real feeling of comfort at the idea of having
come to anchor for years.

I had been rejoicing much beforehand at the prospect of meeting


in Kara my old friend Jacob Stefanòvitch,[78] from whom I had last
parted four years ago, in Switzerland. He had then returned to
Russia, had been arrested in February, 1882, convicted in the “Case
of the Seventeen,” and sentenced to eight years’ “katorga.” He had
been two years in Kara before my arrival. As he was lodged in
another room I could only pay him a flying visit that evening, for
soon after our entrance the rounds were made and the doors all
locked for the night. Next morning, as soon as the rounds had been
made and the roll-call got over, I called to the gendarmes through
the peephole in our door, and made them take me to No. 1 room,
where Stefanòvitch was. During the daytime we were permitted to
go from one room to another—a privilege obtained by the “politicals”
only after a long, hard fight, although in the criminals’ prison the
doors of the rooms had never been kept locked by day.
In No. 1 there were also sixteen men, that being the complete
number; and now that we had arrived every room was full. After
greeting the comrades here and chatting with my friend, I visited all
the other rooms. Of course, the advent of a new-comer is a great
event in the prison, and is generally expected beforehand, for
notwithstanding all official precaution, a good deal of intelligence
from without finds its way through the walls. The arrival is awaited
with the greatest impatience, as may be imagined; and for a few
days the monotony of the life is enlivened by the new-comer’s
tidings of the world in general and of the revolutionary movement in
particular.
Not only had I much to tell, but I was much interested in learning
the views of my comrades, though all that I heard was not entirely
to my liking. I recollect a conversation I had with an old
acquaintance, Volòshenko,[79] who passed for a very intelligent man.
He had been arrested at Kiëv in 1879, and sentenced to ten years’
penal servitude, afterwards increased by eleven years more in
consequence of an attempted escape. When I spoke of the new
tendencies in the Russian revolutionary movement, and mentioned
that a Socialist group had been formed calling itself the “League for
the Emancipation of Labour,” and professing the Marxian views held
by the German Social Democrats, Volòshenko seemed highly
amused.
“Social Democrats in Russia! That’s a comical idea! Who are these
people?”
“You see one of them before you,” I replied.
Volòshenko and many others in the room stared in blank
astonishment. Had I announced myself a follower of the prophet
Mahomet they could scarcely have been more surprised. The ideas
of Karl Marx were at that time but little known in Russia. It was
indeed thought one’s duty to read the first volume of Das Kapital,
which had appeared in a Russian translation, and it was usual to find
educated people in European Russia recognising Marx’s services to
the science of political economy; but in Kara they had not
progressed even so far. As to the philosophical basis of Marx’s theory
of Socialism practically nothing was known; nevertheless it was
rejected, partly owing to the influence of Eugene Dühring, partly to
that of the Russian author N. Mihailovsky, and finally on account of a
dictum of so-called “sane common sense” that Marx’s ideas were
quite inapplicable to Russia. This last was Volòshenko’s contention,
fortified, however, by no personal knowledge of Marx’s writings.
I was in a position to give more than verbal tidings of the new
tendency. We had succeeded, despite all official scrutiny, in
smuggling various prohibited writings into the prison, and among
them the first publication of our group, Plehànov’s Socialism and the
Political Struggle. For a long time no forbidden literature had
penetrated to Kara; the excitement was great, and the new material
for thought was seized on with avidity. I was very anxious to
discover Sundelèvitch’s attitude towards this problem, for in the old
days, when we were nearly all Terrorists, he was considered as more
or less of a Social Democrat—at any rate, he had been known to
approve of the German development on those lines, so far as that
country was concerned. We had been acquainted in 1878, when he
had in charge the transport of forbidden literature for the Zemlyà i
Vòlya (Land and Liberty) group; and he had made use of his special
experience in such illegal traffic to get Stefanòvitch and myself safely
across the frontier after our flight from Kiëv prison. At that time we
had had many hot discussions with Sundelèvitch over the methods
of conducting our struggle in Russia; for I was then a decided
opponent of the Social Democrats, and as a Terrorist and “Naròdnik”
(i.e. member of the party whose object it was to organise revolts
among the peasants) held the peaceful tactics of German Socialists
to be utterly ineffectual—naturally, therefore, I would have all the
more scouted the idea of introducing them into Russia. Sundelèvitch,
on the contrary, did not believe in “the People,” and thought
agitation among the Russian working-classes quite futile. In his
opinion the first thing to do was to fight for political freedom; and
then, as soon as that was obtained, to resort to the constitutional
methods of the German Social-Democratic party. Consequently, he
did not join the terrorist party till it began its political activity in
1878; and he was one of the first to enunciate the idea that its
methods were only temporarily adopted because they offered the
sole possible means in Russia of overthrowing the existing political
order. He was one of the most energetic in organising terrorist
conspiracies, and the party owed much to his help in carrying
through their active work; he was invaluable in striking out the most
effective and practical suggestions. He was arrested quite by chance
in a public library in Petersburg during the autumn of 1879, and was
prosecuted in the “Case of the Sixteen,” when Kviatkòvsky and
Pressnyàkov were sentenced to death, and he himself to lifelong
penal servitude.
I had been thinking much about our former arguments, for I had
since been converted to the views Sundelèvitch then advocated, and
I now hoped to find a kindred spirit in him. Even on purely personal
grounds I desired it; for when a man is convinced of the rightness of
his own plan of action, it must be irksome to live for years with
others who, while sharing his principles, differ entirely as to the best
means of carrying them out; and this is especially so when what one
holds most sacred is in question, no matter how tolerant one may
be. I earnestly hoped I should not be alone in my views, and I could
have asked for no better friend than Sundelèvitch, who was
incomparable as a comrade—one of the finest natures I have ever
known, unselfish, trustworthy, judicious.
As I now lay beside him during the long evenings we talked of our
common friends still in freedom and fighting for the cause, of the
victims of that fight who had died the death of heroes or were
languishing in Schlüsselburg; but instinctively I shrank at first from
touching on theoretical subjects, dreading that we might be out of
sympathy, for I soon heard that he was no longer of his old way of
thinking. Like many others during their first years of imprisonment,
Sundelèvitch experienced a reaction; he absolutely threw over the
Marxian doctrine, and would not admit the economic teaching of Das
Kapital to be sound. In time we fought many a tough battle on this
head, my friend declaring that for Germans Social Democracy might
do, but that such ideas would never effect anything in Russia.
With my other friend, Stefanòvitch, I had less opportunity for
conversation, as we inhabited different rooms; but to him also my
opinions came unexpectedly, and seemed strange and
incomprehensible. When we had parted four years back we had
been quite at one, and he had remained, as he was then, half
Naròdnik, half Terrorist; while I, having thoroughly assimilated the
new ideas, had, with some other companions, founded the Social
Democratic organisation, Tchòrny Peredyèl (Redivision of the Land).
He learned this now for the first time, and could not tell off-hand
how he should regard it; but being unusually thoughtful and far-
seeing, he appreciated the importance of the change that had come
over the opinions of his comrades in the struggle. He grasped the
trend of the new doctrine, and tried to comprehend it fully. It was
clear to him that through our organisation a way was being laid in
Russia for a perfectly new outlook on the world; he doubted whether
it would find favour in our country, but was far from meeting the
idea with enmity or contempt, as the shallower minds among the
revolutionists did both then and later.
This common life of so many young people in the prison had led
to the development of a peculiar jargon. Each room had its
nickname: the first was “the Sanhedrin,” the second “the nobles’
room,” the third “Yakutsk,” and the fourth “Volost,” i.e. “the
commune.” These names had their origin in the dim and distant
past, and I never discovered what had given rise to them.
The inmates of the “nobles’ room,” in which I was located, were all
clever, well-educated young men, full of life and vigour; each in a
way represented a different type, and some had a really remarkable
force of character. Among these latter I would especially class
Nicholas Yatzèvitch, who was the son of a priest in Poltava. When a
seventeen-year-old student in the Veterinary College at Kharkov he
was arrested for attempting to rescue Alexei Medvediev[80] from
prison, was tried, and sentenced to fifteen years’ “katorga.” He had
escaped (as I have said before) from the Irkutsk prison, had been
recaptured, and condemned to another fourteen years’ penal
servitude. He was barely nineteen when brought to Kara, where he
gained the goodwill of everyone by his admirable qualities. Modest
even to bashfulness, silent and reserved, he yet exercised over his
companions a quite wonderful influence. His thirst for knowledge
was without limit; he studied various subjects with unflagging
industry while in prison, especially natural science, philosophy, and
literature, besides learning several languages. He found time, too,
for manual work, at which he proved himself very quick and adroit.
He was on friendly terms with every one of his comrades in prison
without exception, always affectionate and ready to help. No wonder
he gained the esteem of all, and was willingly looked up to as an
authority, despite his youth (he was but five-and-twenty when I first
went to Kara); whether the question were one of household affairs
or an abstruse theoretical problem, his opinion was sure to find
favour with the majority. The bent of his mind was towards
metaphysics, and in philosophy as well as social science he gave
himself out as an eclectic; he shared the opinions of Dühring and the
Neo-Kantians, and in political economy was a follower of Carey,
Bastian, and similar bourgeois theorists. Of course, therefore, he
counted among the opponents of Marxism.
Of very different character were the two bosom friends
Martinòvsky and Starinkyèvitch, usually called “the two Vanitchki,”
though really only one of them answered to the name of Ivan.
Starinkyèvitch was another favourite of our little society, invariably
good-tempered and full of fun. His jokes, bon-mots, and nonsense
would often send us all into fits of laughter, when his own hearty
ringing laugh was sure to dominate all the others. He too was
talented, but not steady and persevering like Yatzèvitch. He was one
of those fortunate beings who are able to get the gist of a passage
with one rapid glance; but he squandered his gifts, attempting
everything, and doing nothing thoroughly. He was almost girlishly
tender, clinging, and confiding by nature; but could on occasion
become passionate and violent. Moscow was his birthplace, and he
was sent straight from the University in 1881, when a mere boyish
student, to twenty years’ imprisonment, simply because he refused
to say from whom he had received a manifesto that was found in his
possession. He was an enthusiastic member of the Naròdnaia Vòlya.
They say that two friends are generally of opposite temperaments,
and the two Vanitchki certainly bore out that theory. While
Starinkyèvitch was gay and lighthearted, Martinòvsky was grave,
sedate, almost morose. He seldom smiled, and I can never
remember hearing him laugh. He was a man of iron will,
commanding and even despotic in character. I cannot imagine his
ever being brought to yield a hair’s-breadth on any subject; on the
contrary, he seemed always to contrive to bring others round to the
fulfilment of his wishes. He was without doubt an extremely gifted
and capable man, who might have made his mark as a leader in
public affairs if he had had the chance. He was above all things
practical; yet could immerse himself on occasion in theoretical
problems, and was one of the first in the prison to take up the study
of Marxism. He too came from Moscow, and like his friend
Starinkyèvitch, had been condemned to twenty years’ imprisonment.
Martinòvsky had been sentenced, in the same case as Sundelèvitch,
Kviatkòvsky, and others, to fourteen years’ “katorga,” and an
attempted escape brought him an addition of another six years. His
having been chosen stàrosta (head-man) by his comrades proves
the complete trust they placed in him, and he was in every way a
model representative of our interests.
The following story concerns another of my fellow-prisoners at
Kara. On the 25th December, 1879, General Drenteln was driving in
his carriage through the streets of Petersburg. He had just been
appointed chief of gendarmerie, in succession to General Mezentzev,
(killed by the revolutionists; see pp. 92 and 263,) and was also the
head of the notorious “third section.”[81] Suddenly a man riding a
beautiful thorough-bred stopped the carriage and fired several shots
at the General through the window, none of the bullets hitting their
mark. The rider made off, the General cried to the coachman to
follow him, and a wild chase began. The people in the streets
understood nothing about what had occurred, and saw with
amazement this strange race between the General’s carriage and a
magnificently mounted horseman. More than once the latter seemed
on the point of being brought to bay, but always escaped down
some side street, closely followed by the General’s fast trotters. At
last the rider made a dash, left his pursuers behind, and was in hot
flight, when his horse stumbled and fell. The fugitive did not lose his
presence of mind, however; beckoning to a policeman, he said: “My
good man, this horse is hurt; just look after it for me while I go and
fetch the groom.” The policeman obediently took the bridle, and the
horseman vanished round the corner, cut through a passage, called
a droschky, and was seen no more. General Drenteln foamed with
rage when he found the horse in such safe keeping, but the rider
gone. The police were set to work, and easily discovered the steed
to be a racehorse named “Lady,” which had been hired from a riding-
school by a student named Mirsky,[82] already under police
observation. Mirsky was by this time no longer to be found in
Petersburg; he had escaped to South Russia. Several months later,
however, he met his fate at Taganrock, while under the roof of a
friend and comrade named Tarhov, a lieutenant in the artillery.
Another officer, having suspicions about Tarhov’s guest, put the
police on the scent, and the house was surrounded. Mirsky, unwilling
to surrender without a struggle, fired several revolver-shots at the
police, and tried to break through their cordon. He was
overpowered, however; was made prisoner, and in 1880 was
brought before a court-martial, together with Tarhov, the poet A.
Olchin, and some others. That was a time when even people not
actually implicated in terrorist attempts were condemned to death
off-hand by the courts-martial, and no one doubted that Mirsky—
whose assault upon the chief of gendarmerie was undisputed—
would be executed. Only he himself seemed to think otherwise. I
remember how, shortly before the trial, somebody who had visited
him in prison came to us and said that Mirsky wanted us to send him
black clothes and a white tie, to wear when he went before the
court. We were all very much surprised, and laughed rather
mournfully over his odd whim. It was the first time it had occurred
to any revolutionist to trouble himself about what sort of coat he
should put on to face his judges. But of course we provided him with
the means of shining for the last time in public; the papers remarked
that “the chief defendant presented a very gentlemanly appearance,”
and his speech of defence was reported with approval in various
foreign journals. He was condemned to death; and although this
sentence was commuted to one of penal servitude for life, he very
narrowly escaped suffering the full rigour of the law. Had the
attempt—planned for that very day—to kill Alexander II. at the
station in Alexandrovskaia been successful, or had the trial taken
place two days later, after the 19th November, when the Tsar’s train
was blown up at Moscow,—all would have been over for Mirsky. As it
was, however, he escaped with his life, and was confined in the
famous Alexei-Ravelin tower of the Fortress of Peter and Paul, where
at that time the most important “politicals” were imprisoned. Four
years later he was brought to Kara, and he was one of my
companions in the “nobles’ room.”
Instead of a slender, aristocratic youth, as Mirsky was described at
the time of his trial, I knew him as a robust, somewhat undersized
but well-built man, of about twenty-seven. And he had changed in
more than outward appearance; he was no longer the hot-headed
boy, ready for any rash deed, but a serious man who had been
through much and had thought deeply. Keen-witted and well
educated, he had formed his own conclusions as to social conditions
in Russia and their development in the future. The teaching of Marx
was unknown to him, but he had attained a similar standpoint by
following out his own reasoning. He was particularly sceptical
concerning the views then prevalent among Russian revolutionists,
according to which a purely Russian programme should be based on
the organisation of the artèls (workmen’s unions), and on the
already existing system of the joint ownership of land by the village
communes; a programme which must differ essentially from that of
Socialists in all other civilised countries. He did not believe that
anything further could be built on these remnants of patriarchal
institutions. He was of opinion that the complete overthrow of the
existing political régime was the first thing to be aimed at in Russia,
but he was convinced that terrorist tactics would never entirely bring
this about; and he expected equally little from any uprising of the
working classes, since the mass of the people were sunk in apathetic
resignation and hopelessness. Yet still the question tortured him—
how should this task be approached?—and he was of all the
prisoners in Kara the best prepared for the philosophical arguments
of a Marxist.
Mirsky had been a medical student; but during his imprisonment
he took up the study of jurisprudence, and was credited with such a
thorough knowledge of legal affairs that his judgments were more
trusted than those of some graduate lawyers who were among us.
Mirsky was of Polish extraction; but having been brought up in
Russia he was in every respect a thoroughly Russian Socialist.
CHAPTER XXIII
THE ORGANISATION OF OUR COMMON LIFE—THE “SIRIUSES”—WAGERS

On my arrival at the Kara prison I found in existence there an


extremely elaborate organisation regulating the prisoners’ daily life,
a system that the course of time had evolved and tested. The
fundamental principle of the arrangement was equality of rights and
duties; the inmates of the prison forming for all domestic purposes a
commune or artèl, although the needs and wishes of individuals
were taken into account as far as possible. It was free to anyone to
enter this artèl or to remain outside, and whichever they did,
material conditions—in the way of food, etc.—were the same for all.
[83]
The Government provided a certain quantity of food per day for
each prisoner—about 3¼ lbs. of bread, nearly 6 oz. of meat, a few
ounces of meal, and some salt. Friends of prisoners were permitted
to furnish them with the means of obtaining extra provisions, and
some of us, though, indeed, only a few, received such contributions
regularly, this money as well as the governmental allowances
becoming the common property of the artèl. The money was
distributed as follows: part was set aside to supplement the food-
rations, especially for buying more meat (this was called in our lingo
“provisioning the stock-pot”); another portion was reserved for what
was called common expenses—assistance to those who were leaving
the prison and going to their appointed place of exile, subscriptions
to such newspapers as we were allowed, postage, etc.; and a third
part was divided equally among all for pocket-money. This last was
spent according to the fancy of each individual, usually on tea,
tobacco, fish, butter, and such things as were considered “secondary
necessaries,” though sometimes these were sacrificed and the
money saved up for months, or even for a year or more, in order to
buy a book or some special luxury. Our funds were very scanty;
during my whole time in Kara there was never more than three or
four kopecks[84] per man per day for the “stock-pot,” and the pocket-
money for each never amounted to more than a rouble[85] a month,
often much less. In consequence of the primitive means of transport
everything imported into Siberia cost three times as much as in
Europe—a pound of sugar, for instance, cost thirty-five to forty
kopecks—and the prisoners had to deny themselves many of the
smallest comforts of material existence. Most of us used only brick-
tea, i.e. tea of the commonest kind, and drank it without sugar;
others thought even that a luxury, and drank hot water; while those
who used sugar had to make one lump do for the whole day—that
is, for three meals.
Actual money was never given us, everything was on paper only.
All remittances were received by the commandant, who kept us
informed of the amount he had in hand. Then we would order
various articles, which would be given to our stàrosta to keep in the
common chest, and whenever he gave anything out he made an
entry in his account-book. At the end of each month the accounts
were made up, each man being told whether he had overdrawn his
pocket-money and so must start the next month with a minus of so
many kopecks, or whether he had saved and was credited with a
plus. The former would try to make good their deficit during the
following month; but there were some who—with the best will in the
world—could never make their expenditure and income balance, and
were always in default, thus acquiring the nickname of “minuses,”
while the thrifty were called “pluses.” No shame was attached to the
being a “minus,” though it was scarcely a title of honour, and no one
cared for the position. The “minuses” always aspired to get straight
at any rate at Christmas or Easter, when pocket-money was
generally increased by an influx of gifts, but it sometimes occurred
that someone found it impossible to get his head above water, and it
was then the custom that at one of our festivals—at Christmas, or on
the commemoration of some revolutionary red-letter day—the
stàrosta or someone should suggest the “whitewashing” of the
bankrupt by wiping off his debt to the artèl. This proposal was
always accepted by the majority, only the “minus” himself
protesting, or refusing to consent.
Every morning the stàrosta presented himself with his order-book
at the doors of the different rooms, and asked what was wanted.
One would order a “sou’s” worth[86] of sugar, another a “brick” of
tea, and so on. These orders were entered, to be later transferred to
the account-book, and soon afterwards the stàrosta would bring the
articles and give them to us through the peephole. The stàrosta also
received from the steward for distribution all things that were due to
us in the way of clothing, linen, and so forth, and he was our
representative in all our dealings with the commandant. The election
of the stàrosta was by ballot, and for a term of six months. The
person elected was, of course, free to decline the post, and this
occasionally happened, as, though an honourable office, it was one
which entailed trouble and responsibility, and sometimes even a
degree of unpleasantness.
Not only the stàrosta, but any member of the artèl might make
proposals for changes in our arrangements, such proposals being
written down, considered by the inmates of the different rooms, and
then voted for or against in writing. It was the stàrosta’s business to
collect the votes and to announce the results through the peepholes.
Proposals of this kind were often most excitedly discussed, parties
being formed to support or oppose them; and occasionally a subject
would develop into a “cabinet crisis,” though the moving or rejecting
of votes of confidence in the “government” (for we had a whole
ministry, other officers being necessary besides the stàrosta) was not
customary.
All work within the prison precincts we shared among us; but such
services as made it necessary to go outside the yard (carrying wood
and water, sanitary cleansing, etc.) were performed by ordinary
criminals, whom we tipped, although not in any way obliged to do
so. Our own duties were of two kinds: work for the community—
such as cooking, cleaning the rooms, attending to the steam baths;
and private work—washing clothes, mending, etc. Everyone except
the weak or ill had to take his share in the former. The cooking was
undertaken by groups of five men, each group serving for a week at
a time. There were eight or nine such groups in all, the choice of
belonging to any particular group being left free without regard to
rooms. Each group had its head cook, his assistant, a cook for the
invalids, and two helpers. The work was not light, and was in no way
attractive; it began between six and seven in the morning, and was
not usually over before five in the evening, by which hour one would
be thoroughly tired out; and when the end of the week came it was
delightful to think of idling for a time. On the other hand, the labour
was a welcome relief to the monotony of our lives, and the kitchen
was a meeting-place for the inhabitants of different rooms, forming
a sort of clubhouse for those engaged in the cooking. Even when the
work was hardest we had merry times there, discussing news,
gossiping, and joking, the work itself often serving as a basis for fun
and all sorts of nonsense. The head cook would give a raw hand
some ridiculous job; one, for instance, would be set to pick potatoes
out of the pot with a fork; another ordered to stand by a hole in the
wall with a big stick and to knock on the head any blackbeetles that
might make their appearance. I myself was given the task of
chopping up millet-seed with a large knife, and other such
absurdities would be invented.
Our cooks had to manage with very scanty materials. Vegetables
frequently ran short, thus making it most difficult to vary the bill of
fare. At the time of my arrival there were no potatoes to be had, and
at midday, from motives of economy, only broth was provided, from
which the meat had been taken to be served up separately for
supper. When I sat down to dinner on my first day in Kara I was
prepared for a frugal meal, having heard beforehand how poor the
dietary was in this prison; but when I had spooned up the meagre
soup without any accompaniment but bread and realised that this
was my whole dinner, I felt somewhat downcast. I rose from table as
hungry as I had sat down; and it was a long while before I could
accustom myself to this sort of nourishment. Our culinary skill was
chiefly displayed in the way of serving up the soup-meat at a
subsequent meal. It was generally minced and heated up with some
vegetables. The dish most favoured by the majority was meat cut
into small pieces and mixed with groats; this was called “Everyone-
likes-it,” and it was the pride of the cooks to decorate our menu with
this original name at least twice a week. The greedy ones among us
used to spy around the kitchen, and never failed to spread the joyful
tidings: “They’re making ‘Everyone-likes-it’ to-day!” The cooks
generally put their best foot forward on Saturday, when their week
of office expired. For years it had been the custom to have an extra
dish on that day, a piròg or sort of pie made of flour, rice, and
mince. The cooks used to save up scraps of meat for it all through
the week, and sometimes the piròg would attain such dimensions
that we could not dispose of it at one sitting, and a remainder would
be left over for Sunday’s breakfast. On the whole our food was
insufficient, not very nutritious, and still less appetising. Bread only
had we at discretion, as the rations given out by the steward were
so large that some was always left over. Only those who had no
stomach for a quantity of dry bread need go hungry. But we hardly
ever had our fill except on great feast days, when not only was our
pocket-money augmented, but an extra allowance of food was
given. The cooks would then indulge us with various dainties and
luxuries; roast meat would come to table, or cutlets, and white
bread. Praise must not be denied to our cooks; there were among
them virtuosi, whose handiwork was quite artistic—worthy, as we
expressed it, “of better houses.”
Invalid diet was not provided specially; the cooks had to arrange
for that as best they could, and make it as varied as was compatible
with economy. During my time there was no severe illness, and
special diet was only needed for those who were delicate or who
suffered from some chronic ailment. The question who was to be
given invalid fare was decided by Prybylyev[87]—one of our number
who acted as our medical adviser, and who showed much skill in that
capacity, though at home he had only been a veterinary surgeon. His
fame in the art of healing became widespread, and afterwards when
he was living out of prison he was consulted by many people,
though there were three qualified physicians in the neighbourhood.
The helpers in the kitchen generally either knew nothing whatever
of the culinary art or else preferred rough work. I fulfilled both
conditions, and never made anything of actual cooking; my duties
consisted in carrying water, chopping wood, taking water and
charcoal for the samovar to the different rooms, apportioning the
food in the wooden bowls out of which we ate, washing up,
attending to the stoves, and cleaning the kitchen. Everybody
working in the kitchen got rather larger portions of food than the
others: that was an ancient custom.
Besides the head-man, who had charge of our larder, a special
“bread-dispenser” was appointed, whose office it was to cut up the
loaves and divide them among the different rooms; he had also to
collect all scraps and crumbs that were left, and send them on to our
comrades in the penal settlement,[88] where they were used to feed
a horse and a couple of cows which belonged to the artèl.
The “poultry-keeper” was another of our officials. We kept in the
yard a number of fowls which we cherished most carefully, and they
were a great amusement to us, especially when a brood of chickens
appeared or when the young cockerels showed fight.
Two other comrades were “bath-keepers”; had to see to the
cleaning of the steam-bath, etc., and—like all our “officials”—were
excused from kitchen work.
Finally, there was the very important post of librarian, which
ranked next to that of stàrosta, and, like it, was decided by ballot,
while the other dignitaries generally chose their own offices. In the
course of years our library had attained quite imposing dimensions;
it was composed partly of books brought by the inmates, partly of
those sent to us as gifts. Nearly all branches of knowledge were
represented in it, but particularly history, mathematics, and natural
science; there were also books in almost every European language,
including the classics. Two enormous cupboards in the corridor
contained this treasure, but the greater part of it was usually in the
hands of eager readers. The custodian had to look after the binding
and mending of the books, in which he found many willing helpers.
The tools and materials used were of the most primitive description;
we had no pasteboard, for instance, and had to contrive some by
pasting paper together. My travelling companion, Tchuikov, proved a
first-rate librarian, not only invariably remembering what books each
person had borrowed, but being always able to tell the whereabouts
of any particular article or treatise in our files of newspapers. He was
to the last always re-elected librarian.
Housework in the rooms was likewise done by strict rule;
according to our turns we had to be on duty twice a day, seeing to
the stoves, carrying the unsavoury wooden tubs in and out at night
and in the morning, and so on. Our rooms were kept scrupulously
clean and neat, and every fortnight there was a tremendous
thorough cleaning; the boards were scrubbed with hot water, beds
aired, tables and benches washed in the yard. We were very
particular about proper ventilation, and observed all hygienic
precautions most carefully; each man used the steam-bath once a
week, and each washed his own clothes—not one of our easiest
jobs.
Remembering that most of us were students fresh from the
universities, or at any rate had hitherto had little practical
acquaintance with domestic labour, and taking into account external
circumstances generally and the scanty supply of materials, I think
we might fairly pride ourselves on the practical and efficient
organisation of our household affairs. Of course our system was
liable to modification in details if necessary, but the principles on
which it was based were fixed and unchangeable.
That our life must have had much in it irksome in the extreme and
hard to bear is only too evident; living in such constant and close
intimacy for years with the same set of people must necessarily lead
to all kinds of petty rubs and differences; all the more because the
forced inactivity was such a strain to the nerves of many. These
were evils not in our power entirely to avert.
In the middle of each room hung a lamp with a dark shade—
lamps that we had ourselves provided. Our table was narrow and
long, so that a number of persons necessarily sat where the light
was very poor, insufficient for work of any kind; and this, of course,
was a misfortune for everyone, as those condemned to idleness
disturbed the more advantageously placed who wanted to study.
Even had there not been this drawback, serious concentration of
mind would have been difficult in a small room wherein were
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge


connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and


personal growth every day!

ebookbell.com

You might also like