Beware the Share - Revision history

Kevlin at 07:44, 17 February 2009

Kevlin — Tue, 17 Feb 2009 07:44:25 GMT

←Older revision		Revision as of 07:44, 17 February 2009
Line 1:		Line 1:
-	It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned &~~mdsah~~; commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening — reuse was frowned upon!	+	It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening — reuse was frowned upon!

	How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?		How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?
Line 7:		Line 7:
	Context.		Context.

-	The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those 4 lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.	+	The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those four lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.

	The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.		The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.
Line 13:		Line 13:
	While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.		While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.

-	These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context ~~they~~ are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.	+	These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context, these techniques are valuable. In the wrong context, they increase cost rather than value. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.

	Beware the share. Check your context. Only then, proceed.		Beware the share. Check your context. Only then, proceed.

Kevlin at 07:39, 17 February 2009

Kevlin — Tue, 17 Feb 2009 07:39:06 GMT

←Older revision		Revision as of 07:39, 17 February 2009
Line 1:		Line 1:
-	It was my first project at the company. I'd just finished my degree and was anxious to prove myself - staying late every day going through the existing code. As I worked through my first feature, I took extra care to put in place everything I had learned - commenting, logging, pulling out shared libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening - reuse was frowned upon!	+	It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned &mdsah; commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening — reuse was frowned upon!

-	How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me ~~- was~~ it all wrong?	+	How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?

	It turns out that I was missing something critical.		It turns out that I was missing something critical.
Line 7:		Line 7:
	Context.		Context.

-	The fact that two wildly different parts of the system performed some logic the same way meant less than I thought. Up until I had pulled out those ~~shared~~ libraries, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of ~~its~~ changing business environment. Those 4 lines of similar code were accidental - a temporal anomaly. That is, until I came along.	+	The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those 4 lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.

-	The ~~shared~~ libraries I created tied the ~~shoe-laces~~ of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the ~~shared~~ library required an order of magnitude more testing.	+	The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.

-	While I'd decreased the absolute lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical - had they been localized, it may have been justified, had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.	+	While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.

-	These mistakes are insidious in that, at their core, they sound like a good idea. ~~And when~~ applied in the right context, they are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.	+	These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context they are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.

	Beware the share. Check your context. Only then, proceed.		Beware the share. Check your context. Only then, proceed.

Udidahan at 11:15, 16 February 2009

Udidahan — Mon, 16 Feb 2009 11:15:57 GMT

←Older revision		Revision as of 11:15, 16 February 2009
Line 3:		Line 3:
	How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?		How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?

-	~~More to come..~~.	+	It turns out that I was missing something critical.

		+	Context.
		+
		+	The fact that two wildly different parts of the system performed some logic the same way meant less than I thought. Up until I had pulled out those shared libraries, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of its changing business environment. Those 4 lines of similar code were accidental - a temporal anomaly. That is, until I came along.
		+
		+	The shared libraries I created tied the shoe-laces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the shared library required an order of magnitude more testing.
		+
		+	While I'd decreased the absolute lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical - had they been localized, it may have been justified, had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.
		+
		+	These mistakes are insidious in that, at their core, they sound like a good idea. And when applied in the right context, they are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.
		+
		+	Beware the share. Check your context. Only then, proceed.

	By [[Udi Dahan]]		By [[Udi Dahan]]

Udidahan at 21:01, 4 October 2008

Udidahan — Sat, 04 Oct 2008 21:01:47 GMT

←Older revision		Revision as of 21:01, 4 October 2008
Line 2:		Line 2:

	How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?		How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?
		+
		+	More to come...
		+

	By [[Udi Dahan]]		By [[Udi Dahan]]

Udidahan at 21:00, 4 October 2008

Udidahan — Sat, 04 Oct 2008 21:00:52 GMT

←Older revision		Revision as of 21:00, 4 October 2008
Line 2:		Line 2:

	How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?		How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?
		+
		+	By [[Udi Dahan]]
		+
		+
		+	This work is licensed under a Creative Commons Attribution 3
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Udidahan: New page: It was my first project at the company. I'd just finished my degree and was anxious to prove myself - staying late every day going through the existing code. As I worked through my first f...

Udidahan — Sat, 04 Oct 2008 20:59:00 GMT

New page: It was my first project at the company. I'd just finished my degree and was anxious to prove myself - staying late every day going through the existing code. As I worked through my first f...

New page

It was my first project at the company. I'd just finished my degree and was anxious to prove myself - staying late every day going through the existing code. As I worked through my first feature, I took extra care to put in place everything I had learned - commenting, logging, pulling out shared libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening - reuse was frowned upon!

How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?