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.

Categories:

Tags:

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

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