Time To Reorg – An Intro to Refactoring

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Organizations reorg all the time. And again. Why do they do that? Setting cynicism aside, organizations reorg to adapt to new realities, to new demands. A team of 5 people that grew to 20 people needs to split to smaller teams. A business group dealing with a fast-growing market needs to come up with a new strategy to cope with the demand. A startup of 20 people will need a different structure than that of a company of 100 people. As business demands change there is a need to adapt the organization’s structure.

Reorg is an expensive venture, yet organizations do it again and again. Because they have to do it – they have no choice.

In a similar manner, the codebase of a product needs to be reorganized again and again to adapt to changing circumstances. A class that has more and more methods needs to split into smaller classes, otherwise, it will be very difficult to maintain it. A conditional (If-Else statement) that grew up to a monster needs to be shrunk again, otherwise, it will be prone to defects. A once simple interface that grew and expanded needs to have some wrapper to make clients’ work bearable.

In fact, taking a hike on Conway’s Law it makes sense that refactoring will somehow be related to reorg, at least in the sense that a change in the organization structure is related to adaptations in the codebase.

We call the process of adapting the codebase “refactoring” – changing the structure of the code not to get new functionality but to make the code better adapted to our new demands, business and technical alike.

Unlike reorgs, refactoring is part of the ongoing work of every developer. Every time a developer is handling code she needs to think about whether she should change the structure of this code. Should the method be renamed? Should a new interface be extracted? Should she replace the conditional with subclasses?

Just like dev doesn’t work without test, dev and test don’t work without refactoring. There are many cases where refactoring is a key player in making the code testable (but I’ll write about it some other time).

I’ve never been in a scouts’ camp but I hear they’re supposed to leave it in better shape than they found it. In the same spirit, a developer should leave the code in a cleaner state than she found it.

Two issues immediately arise, though: First, refactoring takes time. Correct. Reorgs also take time, yet we do them. Refactoring takes less time and provides faster results.

The second issue is that constant refactoring will make the system change all the time. Changing names, changing structure. Won’t that be counterproductive? Won’t that inhibit maintenance? “I’m used to looking for method err4get and now someone renamed it”. The idea is that refactoring should make the system more maintainable. If it makes it less maintainable – don’t do it. Names should be clearer, the structure should be easier to understand, and easier to test and change. Getting into a state of mind that we’re not afraid to make changes in our code is a healthy thing.

Every time your organization goes through another reorg you should ask yourself when did you invest such efforts in your codebase. Codebase reorg should happen all the time, on small scale, getting the code ready for the coming business challenges.

Subscribe for Email Updates:

Categories:

Tags:

Agile Basics
Scrum Primer
Agile Product Ownership
Elastic Leadership
Frameworks
ScrumMaster Tales
Enterprise DevOps
Perfection Game
Kanban Basics
Jira Plans
Scrum Values
Kaizen Workshop
Scrum Guide
Daily Scrum
Release Train Engineer
WIP
Limiting Work in Progress
Agile Games and Exercises
Sprint Planning
Agile Mindset
Agile Product Development
Applying Agile Methodology
Video
Managing Projects
EOS®
POPM
Lean and Agile Principles and Practices
Agile Assembly Architecture
Risk Management in Kanban
Risk Management on Agile Projects
Built-In Quality
Nexus and Kanban
speed at scale
ALM Tools
Development Value Streams
Agile Techniques
Quality Assurance
Scrum Master
Change Management
Acceptance Test-Driven Development
Software Development
Scrum.org
ARTs
Scrum
Lean Risk Management
RTE Role
Portfolio for Jira
Artificial Intelligence
System Team
Hybrid Work
Lean Agile
Spotify
Professional Scrum with Kanban
Continuous Delivery
Team Flow
Software Development Estimation
Effective Agile Retrospectives
Implementing SAFe
Reading List
Achieve Business Agility
Agile Marketing
Agile Release Management
Tools
Nexus and SAFe
Code
Amdocs
RSA
Webinar
Rapid RTC
LeSS
User stories
Kanban
Lean and Agile Techniques
transformation
Kaizen
Lean Agile Basics
Confluence
Professional Scrum Master
The Agile Coach
Lean Agile Management
Planning
Sprint Iteration
Entrepreneurial Operating System®
Games and Exercises
AI Artificial Intelligence
DevOps
Rovo
Jira admin
Engineering Practices
System Archetypes
Program Increment
lean agile change management
Agile Israel
Large Scale Scrum
Atlaassian
Coaching Agile Teams
speed @ scale
Systems Thinking
Agile Project
The Kanban Method
SA
Continuous Improvement
agileisrael
Jira
Scaled Agile Framework
Nexus vs SAFe
Agility
chatgpt
Retrospectives
Nexus
Advanced Roadmaps
Self-organization
An Appreciative Retrospective
GanttBan
Continuous Integration
Certification
Risk-aware Product Development
NIT
Agile Release Planning
Agile
Agile Contracts Best Practices
IT Operations
Introduction to Test Driven Development
A Kanban System for Software Engineering
Sprint Retrospectives
Agile Delivery
Introduction to ATDD
SPC
Agile Games
Agile India
LAB
Agile Community
AgileSparks
Presentation
Agile Development
ATDD vs. BDD
Lean Startup
Agile Outsourcing
Lean Software Development
Kanban Kickstart Example
System Integration Environments
Kanban Game
Continuous Deployment
Releases Using Lean
Jira Cloud
Agile and DevOps Journey
Process Improvement
Accelerate Value Delivery At Scale
Agile Risk Management
Slides
Professional Scrum Product Owner
Legacy Code
Scrum With Kanban
Lean Agile Organization
Agile Program
Kanban 101
SAFe
Covid19
Atlassian
RTE
Product Ownership
Agile Israel Events
Operational Value Stream
Scrum Master Role
Value Streams
Agile Exercises
Lean Agile Leadership
Managing Risk on Agile Projects
SAFe DevOps
Scrum and XP
Lean Budgeting
Manage Budget Creation
AI
Continuous Planning
Nexus Integration Team
BDD
Implementation of Lean and Agile
Legacy Enterprise
PI Planning
Lean-Agile Software Development
LPM
Story Slicing
Agile in the Enterprise
Lean-Agile Budgeting
SAFe Release Planning
ATDD
ART Success
Pomodoro Technique
Certified SAFe
Principles of Lean-Agile Leadership
Agile Project Management
Business Agility
Test Driven Development
predictability
Keith Sawyer
TDD
QA
Product Management
ROI
Tips
Agile Testing Practices
Agile for Embedded Systems
Iterative Incremental Development
What Is Kanban
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart