Improve Code by Removing It - Revision history

Kevlin: Improve code by removing it moved to Improve Code by Removing It

Kevlin — Sat, 11 Jul 2009 20:43:20 GMT

Improve code by removing it moved to Improve Code by Removing It

←Older revision

Revision as of 20:43, 11 July 2009

Kevlin at 20:42, 11 July 2009

Kevlin — Sat, 11 Jul 2009 20:42:44 GMT

←Older revision		Revision as of 20:42, 11 July 2009
Line 1:		Line 1:
-	''Less is more.'' It's a quite trite little maxim, but sometimes it is really true.	+	''Less is more.'' It's a quite trite little maxim, but sometimes it really is true.

	One of the improvements I've made to our codebase over the last few weeks is to remove chunks of it.		One of the improvements I've made to our codebase over the last few weeks is to remove chunks of it.
Line 5:		Line 5:
	We'd written the software following XP tenets, including YAGNI (that is, You Aren't Gonna Need It). Human nature being what it is, we inevitably fell short in a few places.		We'd written the software following XP tenets, including YAGNI (that is, You Aren't Gonna Need It). Human nature being what it is, we inevitably fell short in a few places.

-	I observed that the product was taking too long to execute certain tasks~~. Simple~~ tasks that should have been near instantaneous. This was because they were overimplemented; festooned with extra bells and whistles that were not required, but at the time had seemed like a good idea.	+	I observed that the product was taking too long to execute certain tasks — simple tasks that should have been near instantaneous. This was because they were overimplemented; festooned with extra bells and whistles that were not required, but at the time had seemed like a good idea.

	So I've simplified the code, improved the product performance, and reduced the level of global code entropy simply by removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation.		So I've simplified the code, improved the product performance, and reduced the level of global code entropy simply by removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation.
Line 15:		Line 15:
	* It was a fun bit of extra stuff, and the programmer wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you.)''		* It was a fun bit of extra stuff, and the programmer wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you.)''
	* Someone thought that it might be needed in the future, so felt it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now.)''		* Someone thought that it might be needed in the future, so felt it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now.)''
-	* It didn't appear to be that big an "extra," so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time to a large piece of work that needs maintenance.)''	+	* It didn't appear to be that big an "extra," so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time into a large piece of work that needs maintenance.)''
-	* The programmer invented extra requirements that were ~~not~~ documented ~~in the story~~ that justified the extra feature. The requirement was actually bogus. ''(Hint: ~~Programmer~~ do not set system requirements; the customer does.)''	+	* The programmer invented extra requirements that were neither documented nor discussed that justified the extra feature. The requirement was actually bogus. ''(Hint: Programmers do not set system requirements; the customer does.)''

	What are you working on right now? Is it all needed?		What are you working on right now? Is it all needed?

Kevlin at 21:06, 4 February 2009

Kevlin — Wed, 04 Feb 2009 21:06:57 GMT

Petegoodliffe at 08:40, 27 January 2009

Petegoodliffe — Tue, 27 Jan 2009 08:40:13 GMT

←Older revision		Revision as of 08:40, 27 January 2009
Line 13:		Line 13:
	So why did the unnecessary code end up there in the first place? Why did one developer feel the need to write extra code, and how did it get past review (or the pairing process?) Almost certainly something like:		So why did the unnecessary code end up there in the first place? Why did one developer feel the need to write extra code, and how did it get past review (or the pairing process?) Almost certainly something like:

-	# It was a fun bit of extra stuff, and the developer wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you)''	+	* It was a fun bit of extra stuff, and the developer wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you)''
-	# Someone thought that it might be needed in the future, so it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now)''	+	* Someone thought that it might be needed in the future, so it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now)''
-	# It didn't appear to be that big an "extra", so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write, and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time to a large piece of work that needs maintenance.)''	+	* It didn't appear to be that big an "extra", so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write, and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time to a large piece of work that needs maintenance.)''
-	# The developer invented extra requirements that were not documented in the story that justified the extra feature. The requirement was actually bogus. ''(Hint: Developers do not set requirements; the customer does.)''	+	* The developer invented extra requirements that were not documented in the story that justified the extra feature. The requirement was actually bogus. ''(Hint: Developers do not set requirements; the customer does.)''

	What are you working on right now? It is all needed?		What are you working on right now? It is all needed?

Petegoodliffe: New page: ''Less is more.'' It's a quite trite little maxim, but sometimes it is really true. One of the improvements I've made to our codebase over the last few weeks is removing chunks of it. We...

Petegoodliffe — Tue, 27 Jan 2009 08:39:18 GMT

New page: ''Less is more.'' It's a quite trite little maxim, but sometimes it is really true. One of the improvements I've made to our codebase over the last few weeks is removing chunks of it. We...

New page

''Less is more.'' It's a quite trite little maxim, but sometimes it is really true.

One of the improvements I've made to our codebase over the last few weeks is removing chunks of it.

We'd written the software following XP tenets, including YAGNI (that is, You Aren't Going to Need It). Human nature being what it is, we inevitably fell short in a few places.

I observed that the product was taking too long to execute certain tasks. Simple tasks that should have been near instantaneous. This was because they were over-implemented; festooned with extra bells and whistles that were not required, but that seemed like a good idea at the time.

So I've simplified the code, improved the product performance, and reduced the level of global code entropy by simply removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation.

A simple and thoroughly satisfying experience.

So why did the unnecessary code end up there in the first place? Why did one developer feel the need to write extra code, and how did it get past review (or the pairing process?) Almost certainly something like:

# It was a fun bit of extra stuff, and the developer wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you)''
# Someone thought that it might be needed in the future, so it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now)''
# It didn't appear to be that big an "extra", so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write, and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time to a large piece of work that needs maintenance.)''
# The developer invented extra requirements that were not documented in the story that justified the extra feature. The requirement was actually bogus. ''(Hint: Developers do not set requirements; the customer does.)''

What are you working on right now? It is all needed?

←Older revision		Revision as of 21:06, 4 February 2009
Line 1:		Line 1:
	''Less is more.'' It's a quite trite little maxim, but sometimes it is really true.		''Less is more.'' It's a quite trite little maxim, but sometimes it is really true.

-	One of the improvements I've made to our codebase over the last few weeks is ~~removing~~ chunks of it.	+	One of the improvements I've made to our codebase over the last few weeks is to remove chunks of it.

-	We'd written the software following XP tenets, including YAGNI (that is, You Aren't ~~Going to~~ Need It). Human nature being what it is, we inevitably fell short in a few places.	+	We'd written the software following XP tenets, including YAGNI (that is, You Aren't Gonna Need It). Human nature being what it is, we inevitably fell short in a few places.

-	I observed that the product was taking too long to execute certain tasks. Simple tasks that should have been near instantaneous. This was because they were ~~over-implemented~~; festooned with extra bells and whistles that were not required, but ~~that~~ seemed like a good idea ~~at the time~~.	+	I observed that the product was taking too long to execute certain tasks. Simple tasks that should have been near instantaneous. This was because they were overimplemented; festooned with extra bells and whistles that were not required, but at the time had seemed like a good idea.

-	So I've simplified the code, improved the product performance, and reduced the level of global code entropy by simply removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation.	+	So I've simplified the code, improved the product performance, and reduced the level of global code entropy simply by removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation.

	A simple and thoroughly satisfying experience.		A simple and thoroughly satisfying experience.

-	So why did the unnecessary code end up there in the first place? Why did one ~~developer~~ feel the need to write extra code, and how did it get past review (or the pairing process?) Almost certainly something like:	+	So why did the unnecessary code end up there in the first place? Why did one programmer feel the need to write extra code, and how did it get past review or the pairing process? Almost certainly something like:

-	* It was a fun bit of extra stuff, and the ~~developer~~ wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you)''	+	* It was a fun bit of extra stuff, and the programmer wanted to write it. ''(Hint: Write code because it adds value, not because it amuses you.)''
-	* Someone thought that it might be needed in the future, so it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now)''	+	* Someone thought that it might be needed in the future, so felt it was best to code it now. ''(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now.)''
-	* It didn't appear to be that big an "extra", so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write, and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time to a large piece of work that needs maintenance.)''	+	* It didn't appear to be that big an "extra," so it was easier to implement it rather than go back to the customer to see whether it was really required. ''(Hint: It always takes longer to write and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time to a large piece of work that needs maintenance.)''
-	* The ~~developer~~ invented extra requirements that were not documented in the story that justified the extra feature. The requirement was actually bogus. ''(Hint: ~~Developers~~ do not set requirements; the customer does.)''	+	* The programmer invented extra requirements that were not documented in the story that justified the extra feature. The requirement was actually bogus. ''(Hint: Programmer do not set system requirements; the customer does.)''

-	What are you working on right now? ~~It is~~ all needed?	+	What are you working on right now? Is it all needed?
		+
		+	By [[Pete Goodliffe]]
		+
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page