100% found this document useful (5 votes)
29 views

Effective Software Development for the Enterprise: Beyond Domain Driven Design, Software Architecture, and Extreme Programming 1st Edition Tengiz Tutisani download pdf

Effective

Uploaded by

huvindjuly
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (5 votes)
29 views

Effective Software Development for the Enterprise: Beyond Domain Driven Design, Software Architecture, and Extreme Programming 1st Edition Tengiz Tutisani download pdf

Effective

Uploaded by

huvindjuly
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 66

Download Full Version ebookmass - Visit ebookmass.

com

Effective Software Development for the Enterprise:


Beyond Domain Driven Design, Software
Architecture, and Extreme Programming 1st Edition
Tengiz Tutisani
https://ebookmass.com/product/effective-software-
development-for-the-enterprise-beyond-domain-driven-design-
software-architecture-and-extreme-programming-1st-edition-
tengiz-tutisani/

OR CLICK HERE

DOWLOAD NOW

Discover More Ebook - Explore Now at ebookmass.com


Instant digital products (PDF, ePub, MOBI) ready for you
Download now and discover formats that fit your needs...

Solution Architecture Patterns for Enterprise: A Guide to


Building Enterprise Software Systems 1st Edition Chanaka
Fernando
https://ebookmass.com/product/solution-architecture-patterns-for-
enterprise-a-guide-to-building-enterprise-software-systems-1st-
edition-chanaka-fernando/
ebookmass.com

Radical Therapy for Software Development Teams: Improving


Software Development Practices and Team Dynamics 1st
Edition Gregory Lind
https://ebookmass.com/product/radical-therapy-for-software-
development-teams-improving-software-development-practices-and-team-
dynamics-1st-edition-gregory-lind/
ebookmass.com

Flight Simulation Software: Design, Development and


Testing David Allerton

https://ebookmass.com/product/flight-simulation-software-design-
development-and-testing-david-allerton/

ebookmass.com

Latin Poetry in the Ancient Greek Novels Daniel Jolowicz

https://ebookmass.com/product/latin-poetry-in-the-ancient-greek-
novels-daniel-jolowicz/

ebookmass.com
Women’s Private Practices of Knowledge Production in Early
Modern Europe 1st Edition Natacha Klein Käfer

https://ebookmass.com/product/womens-private-practices-of-knowledge-
production-in-early-modern-europe-1st-edition-natacha-klein-kafer/

ebookmass.com

Hume's Imagination Tito Magri

https://ebookmass.com/product/humes-imagination-tito-magri/

ebookmass.com

Tres semanas para enamorarte (3-Escocia contemporánea) 1ª


Edition Nessa Mcdubh

https://ebookmass.com/product/tres-semanas-para-enamorarte-3-escocia-
contemporanea-1a-edition-nessa-mcdubh/

ebookmass.com

Retail Management 5th Edition Gibson E. Vedamani

https://ebookmass.com/product/retail-management-5th-edition-gibson-e-
vedamani/

ebookmass.com

A Soul to Steal: Duskwalker Brides Book Six (MM) Opal


Reyne

https://ebookmass.com/product/a-soul-to-steal-duskwalker-brides-book-
six-mm-opal-reyne/

ebookmass.com
(Original PDF) Intro Stats 5th Edition by Richard

https://ebookmass.com/product/original-pdf-intro-stats-5th-edition-by-
richard/

ebookmass.com
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
Random documents with unrelated
content Scribd suggests to you:
The Elias Hasket Derby House
Among all the residences of Old Salem, that which was most
ambitious and pretentious no longer exists, save in picture and
memory. This was the famous mansion built by McIntire in 1798 for
Elias Hasket Derby, Salem’s greatest merchant, at a cost of $80,000.
Derby lived only a few months after taking possession, and the
upkeep of so expensive an establishment deterring prospective
purchasers, this splendid house was dismantled and finally razed in
1815—the land being donated to the town for a public market. Derby
Square, where the present Market House now stands, was the
location of the famous house.
McIntire was in 1804 erecting a house at 142 Federal Street for
Captain Cook. Business reverses greatly delayed its completion, and
McIntire continued it at his leisure, taking advantage of the
dismantling of the Derby mansion to utilize much of its beautifully
carved woodwork in the interior. The result was the Cook-Oliver
house, as it is now known—one of the most satisfying to the artistic
sense of any in all Salem.
Existing plans and sketches of the Derby mansion show us a huge
rectangular building, suggesting a court-house, or some such public
structure, standing well back from the street, its great doorway
flanked by double columns supporting a balustraded balcony. Above
this is a splendid Palladian window, and above this again hand-
tooled festoons of drapery. The door itself has ornate fanlight with
side-lights to correspond, and stands at the head of a flight of
massive steps.
The flat roof with its elaborate cornice and heavy balustrade is
supported by pilasters, six in number, having carved capitals; and
these in turn at the second floor level rest upon plain pilasters. A
huge cupola surmounts the roof, with bell-shaped top, carved
garlands, and arched windows. The lintels of the first two tiers of the
house windows are heavy with ornament, while the third tier
illustrates the familiar plan of foreshortening. A great deal of iron
fencing with ornamental posts surrounds the spacious yard.
With all the prodigality of architectural detail embodied in this great
mansion, it must still be admitted that it was not overdone, as the
large proportions and wide spaces pleasantly distributed the
ornamentation over a broad field.
The Derby mansion doubtless represented the climax of effort in
the line of house-building in Salem—the sudden death of its owner,
followed by its own demolition, being a melancholy comment upon
the uncertainty of human plans.
The Neal-Kittridge-Rogers House

THE NEAL-KITTRIDGE-ROGERS HOUSE

This fine residence, at 13 Chestnut Street, is closely associated


with the subject of Salem’s unprecedented commercial activity and
success from the earliest date, to which some reference has already
been made.
The adjacent waters swarmed with fish, cod, sturgeon, and
salmon; and for a hundred years this was the chief article of export.
So plentiful was North River salmon that the articles of indentured
apprentices contained a proviso that they should not be obliged to
partake of it more than three times a week.
Other items of export were ‘lumber, horses, whale- and fish-oil,
whalebone, furs, elk- and bear-skins.’
The Revolution halted Salem’s commerce, and with patriotic
devotion and Yankee ingenuity, the ketches and ships of trade were
quickly converted into privateers. All told, these numbered upwards
of 158; and during the war they took 445 prizes—an average of three
apiece.
At the close of the war, Salem found her fleet upon her hands; and
her merchants began to look farther from home for the trade to which
their newer and larger vessels were better fitted than for their
previous short voyages to the mother country or to near-by
European ports.
The daring spirit of American sailors turned toward Oriental
countries, with their glamour of romance and danger and their lure of
wealth; and soon the ports of all the East became familiar with
Salem vessels, and Salem warehouses were filled with the products
of foreign lands. India, Sumatra, China, Zanzibar, Batavia, and Africa
all made their contribution to Salem’s increasing wealth; and her
name became the synonym for commercial enterprise the world
over.
When one recalls the fact that early vessels were usually not over
sixty tons burthen, while their skippers were commonly no more than
boys—the captain and mates of the first Salem India-man being still
in their teens—the wonder grows. Interesting touches are found here
and there; as, for example, that the first elephant ever seen in the
United States came over from Bengal in 1796, in the ship America,
of which Captain Jacob Crowninshield, of Salem, was owner and
master.
One of these old-time merchant adventurers was Captain William
H. Neal, for whom was built the house at 13 Chestnut Street. Directly
across from Hamilton Hall, one might catch glimpses from the upper
windows of the festivities in that famous social center. Later, the
property was bought by Dr. Thomas Kittridge, and is now the
residence of his daughter, Mrs. Foster Rogers.
The doorway and porch are of severe and simple beauty, the
fluted pilasters, plain architrave, and rectangular-paned top- and
side-lights, together with the six-paneled green door, ornamented
with old-time brass knocker and latch, presenting a most harmonious
and pleasing effect.
The Arthur West House

THE ARTHUR WEST HOUSE

The name of West in Salem is closely associated with her


commercial enterprise. Nathaniel West was part owner of the
Minerva, the first vessel from this port to circumnavigate the globe.
The family was connected by marriage with the Peabodys,
Crowninshields, and Derbys, Nathaniel West marrying Elizabeth, a
daughter of Elias Hasket Derby, and building the handsome
residence at Peabody now known as ‘Oak Hill.’ Lieutenant Benjamin
West was the only man from Salem to lose his life at the battle of
Bunker Hill.
The doorway of the West house at 12 Chestnut Street maintains
the best traditions of Colonial architecture. The fluted columns,
dentiled architrave, plain top- and side-lights, and fine old six-
paneled door, present a pleasing ensemble. The capitals contain a
hint of the Egyptian in the use of the lotus-leaf.
The Hoffman-Simpson House

THE HOFFMANN-SIMPSON HOUSE

Captain Charles Hoffman, original owner of the handsome brick


mansion at 26 Chestnut Street, was a prosperous merchant, whose
hobby when ashore was the care of his famous garden. He was the
importer of the first azaleas known in America, the old
conservatories which he used being still in existence.
The present occupant of the house, Dr. James Simpson, has kept
the beautiful old-fashioned garden intact, with the same varieties of
flowers which Captain Hoffman originally planted. The central feature
of the garden is an ancient summer-house, covered with a thick
growth of ‘Dutchman’s Pipe,’ the vine being over eighty years old.
For sheer beauty and taste, the porch and doorway of this old
mansion are scarcely surpassed by any in Salem. The fluted
columns are Ionic, the architrave directly above ornamented with
guttæ, while beneath the cornice is a line of ball moulding. The fine
old door bears a brass knocker; the leaded glass of top- and side-
lights is of exceptional charm. The casing of the doorway is finely
moulded; and the designer has added a unique completing touch by
painting the adjacent brickwork white.
The Doyle Mansion

THE DOYLE MANSION

The ‘Doyle Mansion,’ always so-called, stands at 33 Summer


Street, and possesses a most interesting history.
Its original owner was a Captain Doyle. Incurring serious losses
through unfortunate ventures in trade, the family took in two or three
‘paying guests.’ This plan proving successful, it was enlarged by
gradual additions until a second, and soon a third, house was
needed to care for the growing business. Recently a fourth house—
that standing next door, once the residence of Samuel McIntire, the
famous craftsman and architect—has been included in the
establishment, which has carried on its business continuously for
ninety-seven years.
It is gratifying to be able to record the fact that all the old
furnishings of the house have been kept intact. In the hallway, as
fresh as when originally hung, is a beautiful wall-paper of the familiar
‘castellated’ pattern.
The doorway is severely plain, the sole ornamentation being in the
brackets which support the porch roof, and the dentils and modillions
beneath the cornice.
Derby Street and Chestnut Street
Visitors to Old Salem who try to identify the scenes of the little
town’s ancient glory will find small comfort on Derby Street.
Stretching for the distance of half a mile along the water-front, this
was once the center of the thriving commerce of the place. Along
one side of the street were the counting-houses of the merchant
princes, around which hung the atmosphere and flavor of thrilling
maritime romance. Practically the entire male population, young and
old, was engaged directly or indirectly in the business of such as go
down to the sea in ships. Ship-builders and sailors, craftsmen and
navigators—Derby Street hummed with their activities. Before the
ports of New York and Boston had acquired touch with Oriental
trade, Salem had already dipped deep into the coffers of the East;
and the ambition of her bold adventurers was well expressed in the
motto upon the seal of the town—‘Divitis Indiæ usque ad ultimum
sinum’—‘Unto the farthest bay of wealthy Ind.’
Some idea of the volume of the trade whose center was in Derby
Street may be gained from the fact that in thirty years customs duties
totaled more than eleven million dollars, while over two hundred and
fifty vessels flew the flag in every corner of the seven seas.
All this brought into Salem an element not only of wealth and
comfort, but of culture and refinement as well; and so on Derby
Street, across from the counting-houses where the money was
made, arose the handsome homes of those who had made it, and to
whom it brought the means of maintaining a high standard of living.
Here were to be found all the finest residences of Salem; it was in
truth the ‘Court end’ of the town.
But to-day all is changed. With but a single exception here and
there, Derby Street presents a squalid and forlorn succession of
shabby frame houses, occupied mostly by foreigners. Commerce
consists in such humble trade as goes on in Greek restaurants and
Polish markets. The splendid homes of merchants and ship-owners
no longer gratify the eye; and what is of note to-day in architectural
beauty and taste in Salem must be sought elsewhere than in its
original location.
With the advent of the railroad, the maritime commerce of the town
began to decline. The counting-houses gradually closed. No longer
did the boys of the town, on the lookout for returning ships, descrying
a familiar rig or figurehead at the harbor’s mouth, race for Derby
Street to bring the earliest news and claim the customary reward. No
longer did the ship-owner pace the ‘Captain’s Walk,’ glass in hand, to
raise on the distant horizon the topsails of some overdue vessel. The
ancient glory was departed; and unwilling to linger where reminders
of past grandeur continually met the eye, the men of wealth and
standing with one accord took thought for a spot where they might
rebuild, and form a sort of neighborhood community where the
traditions of maritime greatness should be maintained in an
atmosphere all their own. A move was first made in the direction of
Beverly, but meeting some obstacles connected with land titles,
another selection was made, and Chestnut Street, with its double
row of beautiful and artistic Colonial mansions, stretches its half-mile
under the arching trees.
Some account such as the foregoing is necessary for the
understanding of the grouping of so large a number of splendid
residences in one quarter of the town. Washington Square, to be
sure, presents a somewhat similar case; but it was Chestnut Street
which was considered the most choice and exclusive section. It ‘kept
itself to itself,’ as the saying was: and woe to the social climber who
might unsponsored seek to make his way into the royal group.
As at first laid out, the land upon which each house on Chestnut
Street was located extended through to Essex Street on the one side
and to Broad Street on the other. The regret often finds expression
that these fine homes are built so close to the sidewalk as to lose the
setting of lawn and shrubbery at the front. The chief reason for this
probably lies in the fact that the garden was very dear to Salem
hearts, and all the space possible was desired for its development.
In the rear of many an old mansion may still be found, somewhat
shrunken in size, an old garden which is a veritable spot of beauty.
Some of these were laid out in the formal Italian manner, like that of
the Ropes Memorial on Essex Street; of the old-fashioned sort are
those of the Cabot-Low, the Pierce-Johonnot and the Cook-Oliver
houses. The Cabot garden used to boast of over six hundred
varieties of tulips, imported by its owner from Holland. On the street
itself, the handsome shade-trees were all set out by the owners of
the houses on either side.

HOUSE OF MRS. EMERY JOHNSON


362 Essex Street

Walking down Chestnut Street to-day, one is impressed by the


beautiful porches and doorways which face one another across the
broad avenue between. They seem to speak of cordial hospitality
and to extend a welcome to expected guests.
Such hospitality was a well-known characteristic in fact of Salem
homes; and on Chestnut Street it was notably exemplified, though in
its own exclusive way.
Socially Chestnut Street was exceedingly gay. Many were the
‘parties’ which took place within those beautiful homes, and many
the distinguished guests entertained there. Invitations were always
delivered by the children, who went from door to door with note or
message telling of the place and time. Often the party was an all-day
affair, to which the ladies went each with her beaded bag containing
her work. Tea was served at four o’clock, out-of-doors if the weather
permitted, indoors if necessary. ‘Nimble-cake’ was a favorite adjunct
of the cup of tea. In the evening the gentlemen appeared; and one
may imagine the effect of small-clothes and ruffles, silken gowns and
India shawls, amid the handsome furnishings and lavish architectural
beauty of the spacious Colonial rooms and hallways.
Public balls and receptions were equally gay and equally
exclusive. Usually held in Hamilton Hall, on the corner of Chestnut
and Cambridge Streets, they included only such persons as were
socially vouched for by the proper authorities.
On these occasions the finest silver and linen were sent over for
the table, as were rugs for the floor, by the housewives.
Refreshments were available all the evening, and later on dinner
was served, featuring the favorite dainties of the time—not forgetting
‘sangaree,’ for the mixing of which there was always abundance of
imported stock.
THE HOUSE OF MRS. GEORGE WHEATLAND
374 Essex Street

At these Assemblies the students from Harvard College, as it then


was, were very popular, and found many a fair partner among the
Salem beauties, of whom there was no lack. No less a personage
than President Washington himself commented, at the time of his
reception at Assembly Hall in 1789, upon the large number, upwards
of a hundred, of handsome ladies present.
Mention of the Chestnut Street festivities would hardly be
complete without reference to the Salem Cadets, an exclusive
military organization resembling the famous Seventh Regiment of
New York. They had an armory at 136 Essex Street, formerly the
residence of Colonel Francis Peabody, to which a drill-shed was
added. In the ‘Banqueting Hall’ of the Peabody mansion Prince
Arthur of England, in the country for the purpose of attending the
funeral of George Peabody, the London banker, in 1870, was
entertained at dinner. This handsome room was finished in carved
oak in the Elizabethan Gothic style. The figure of Queen Victoria
appears over the fireplace, supported by mailed figures.
This woodwork has been removed to the Masonic Temple on
Washington Street, where it adorns one of the smaller rooms. The
Peabody house was demolished in 1908.
Wearing their famous scarlet uniforms, and swinging down
Chestnut Street, their favorite parade-ground, with handkerchiefs
waving from the classic porches on either side, the Salem Cadets
lend a touch of color and life which is most attractive against the
Colonial background.
Famous Names in Salem
The house is nothing without its inhabitant; and thus Salem
architecture, however beautiful, would lack in significance if
dissociated from the persons, men and women, who have passed in
and out of these hospitable doors, or spent years of life beneath the
sheltering roofs.
As one scans the roster, he is led to wonder that so many famous
names are found upon it—both inhabitants and guests—considering
the size of the place: ‘infinite riches in a little room.’ For among those
who were born in Salem, or lived here long enough to call it home,
are Nathaniel Hawthorne; Nathaniel Bowditch, the famous
mathematician; the Honorable Jacob Crowninshield and his brother
Benjamin, Secretary of the Navy under two Presidents; Colonel
Timothy Pickering, of Revolutionary fame; General Henry K. Oliver,
the well-known musician; President E. C. Bolles, of Tufts College;
Colonel George Peabody, art-lover and merchant prince; William
Bentley and William H. Prescott, the historians; General Israel
Putnam; Count Rumford; Henry FitzGilbert Waters, the genealogist;
Charles T. Brooks, essayist and poet; the Honorable Rufus Choate;
John Singleton Copley, the artist, whose son became Lord
Chancellor of England; the Honorable George B. Loring,
Congressman and Minister to Portugal in Harrison’s administration;
Benjamin Peirce, eminent among the scientists of his day; the
Honorable Nathaniel Read, Congressman and inventor of the cut
nail; John Rogers, the sculptor; Jones Very, the poet; Joseph E.
Worcester, of dictionary fame; General Frederick T. Ward, organizer
of the Chinese troops which in the Tai-Ping Rebellion were called the
‘unbeatable army’—and many others.
Among the noted visitors who were at various times guests of the
town appear the names of the Marquis de Lafayette, President
Washington, Alexander Hamilton, Henry Clay, President Monroe,
General W. T. Sherman, the Right Honorable Joseph Chamberlain,
War Governor John A. Andrew, President Chester A. Arthur, King
Edward VII of England (then Prince of Wales), President Andrew
Jackson, Louis Kossuth the Hungarian patriot, General George B.
McClellan.
Wealth accumulated in Salem, but men did not decay. Few towns
in New England can boast of such striking history and such valuable
achievements on the part of their citizens, within a like period of time,
as can Old Salem by the Sea.
Palladian Windows
The earliest hallways in old Salem houses, as we have seen,
whether at front or rear, were not hallways in any real sense of the
term, but were entries, tiny and dark, receiving a dim illumination
from the bull’s-eye or square-paned windows in the upper panels of
the door, or from the narrow horizontal transom which was later
placed above it. There was little of convenience, and still less of
hospitality, in these cramped spaces, which were usually just large
enough for the door to swing back against the wall, while the
entering guest squeezed by into the room opening at the side.
But with enlarging ideas of comfort and convenience, the entry
gradually developed into a hallway proper, leading right through the
house, the staircase no longer a meager Jacob’s ladder screwing its
way upward, but now a wide and handsome ascent of noble
proportions, with carved balusters and newel-posts.
Up such a staircase the guest would pass, pausing on the broad
landing to admire the beautifully laid out garden which graced the
yard of the fine estate, and resting for a few moments upon the
cushioned seat which commanded the charming view, framed as it
was in a large ornamental window set in the house-wall at the head
of the stairs.
These Palladian windows—so-called after Andrea Palladio, an
Italian architect of the sixteenth century—consist of a central
opening, usually in scale with the other windows of the house, and
having the same number of panes, but with an arched top, circular or
elliptical, sometimes resembling a fanlight, rarely a solid segment of
wood embellished with carved ornaments. Flanking this central
opening are side-lights, of plain or tastefully leaded glass, and as
most often in Salem houses the Palladian window is placed directly
above the main entrance, the pattern of these side-lights, as also the
architectural motif of frame and entablature, echo those of the
doorway and porch below.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and


personal growth!

ebookmass.com

You might also like