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:

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