Test Driven Developer
You got a TEST for that?
Home
|
Syndication
|
Sign In
Tuesday, September 06, 2011
How to Sell Refactoring
Why would a stakeholder want to care about refactoring. It only makes development take longer, which means they get fewer features delivered. In some places it's a hard-sell. These are the situations where we find a lot of "Red, Green, Done" code written. Sometimes it's just Green, Done and even Done, Green. Let's examine why and how refactoring could be of interest to a stakeholder.
Stakeholders shouldn't know or care if a developer is writing unit tests, main-line code, or refactoring something.
It's not their job, it's the developer's job. There needs to be trust, and it goes both ways.
The stakeholders should be focused more on business strategy and how features and information can help the company make more money.
If they are that involved with development tasks they are either micromanaging or just nosey.
Not that there shouldn't be transparency - there should. But people should focus on their area of expertise and let everyone else do their jobs too.
Refactoring improves the code. Here are but a few reasons to do it.
More robust - fewer issues
Faster - more performant
Easier to change, requiring less training
Easier to understand the logic
Less easy to write bugs
Code operation is more stable
Cheaper/faster to maintain
Cleaner and simpler
Refactoring the design clarifies intent and makes testing easier
Clear code tracks more closely and obviously with business requirements
Refactoring sometimes makes bugs obvious and they can be eliminated in development rather than after test phases.
We can map these advantages to direct dollar savings in development
Most bugs can be tracked to code that is obtuse, complex, or convoluted.
Many studies have been done that show bugs are much less costly to eliminate in the earliest phases, design and development.
Not writing bugs is far less expensive than finding them and fixing them.
Truly informed stakeholders will not only accept refactoring, they will encourage it, because the practice actually saves time and money in the long AND short-run.
Refactoring
Tuesday, September 06, 2011 8:40:46 PM (Pacific Standard Time, UTC-08:00)
Comments [0]
|
Trackback
Comments are closed.
© Copyright 2012, John E. Boal
Calendar
<
February 2012
>
Sun
Mon
Tue
Wed
Thu
Fri
Sat
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
1
2
3
4
5
6
7
8
9
10
Total Posts: 53
This Year: 0
This Month: 0
This Week: 0
Comments: 22
Archives
December, 2011 (1)
November, 2011 (1)
September, 2011 (1)
August, 2011 (1)
May, 2011 (1)
April, 2011 (1)
March, 2011 (0)
February, 2011 (1)
November, 2010 (1)
September, 2010 (1)
June, 2010 (1)
April, 2010 (1)
March, 2010 (1)
February, 2010 (1)
September, 2009 (1)
August, 2009 (1)
June, 2009 (1)
May, 2009 (1)
April, 2009 (1)
February, 2009 (1)
January, 2009 (2)
December, 2008 (2)
November, 2008 (2)
October, 2008 (2)
September, 2008 (4)
August, 2008 (3)
July, 2008 (5)
June, 2008 (4)
May, 2008 (1)
April, 2008 (2)
March, 2008 (4)
February, 2008 (2)
January, 2008 (1)
On this page
categories
ABN
Acceptance Criteria
ATDD
Automation
Bugs
C#
Continuous Integration
Mocks
MSTest
Python
Refactoring
Selenium
SQL
TDD
Testing
Tools
Unit Tests
Video
WatiN
Links
Home
Test Driven Development, Defined (Wikipedia)
Test Driven Design
Test-Driven.com - Agile development tools
NUnit
Book: Test-Driven Development in Microsoft .NET
CodeProject - Advanced Unit Testing: Unit Test Patterns
John Boal's Personal Blog
John Boal's Agile Development Blog
Blogroll
OPML
Lazy Coder
Scott Koon's Blog
#2782
Ade Miller's Tech Blog
Agile Development
Mitch Lacey's Agile Development Blog
Espresso Fueled Agile Development
Mike Puleio's Blog
Geek Noise
Noise de Peter Provost
Sneal's Blog
Shawn Neal's Blog
Search
About
© Copyright 2012, John E. Boal
Sign In