Distributed development - Revision history

JaroslavTulach: /* Distant Teams */

2017-12-18T12:08:19Z

Distant Teams

←Older revision		Revision as of 12:08, 18 December 2017
Line 23:		Line 23:
	For some reason the art of organizing the [[teamwork]] for [[distributed development]] or at least adjusting one's development style in such away is easier for really independent teams. Once you have a separated, but connected team (like [[I]] have in case of [[Truffle]], [[Graal]] and various [[GraalVM]] language teams), everything starts to look impossible.		For some reason the art of organizing the [[teamwork]] for [[distributed development]] or at least adjusting one's development style in such away is easier for really independent teams. Once you have a separated, but connected team (like [[I]] have in case of [[Truffle]], [[Graal]] and various [[GraalVM]] language teams), everything starts to look impossible.

-	Suddenly people tend to require upstream fixes as soon as possible. They want to access sources of such components and modify them without any restrictions. They stop thinking about the project as being composed from [[modular]] components - rather they want to work with all of them as a whole. That is obviously more comfortable, but also it is not scalable.	+	Suddenly people tend to require upstream fixes as soon as possible. They want to access sources of such components and modify them without any restrictions. They stop thinking about the project as being composed from [[modular]] components - rather they want to work with all of them as a whole (for example have all the "modular" components in a single rather [[MultiGitRepository\|multiple Git repositories]]!). That is obviously more comfortable, but also it is not scalable.

	Looks like everyone is worshiping modularity, but nobody wants to give an inch up to really have it.		Looks like everyone is worshiping modularity, but nobody wants to give an inch up to really have it.

JaroslavTulach: /* Distant Teams */

2017-12-18T12:04:58Z

Distant Teams

←Older revision		Revision as of 12:04, 18 December 2017
Line 23:		Line 23:
	For some reason the art of organizing the [[teamwork]] for [[distributed development]] or at least adjusting one's development style in such away is easier for really independent teams. Once you have a separated, but connected team (like [[I]] have in case of [[Truffle]], [[Graal]] and various [[GraalVM]] language teams), everything starts to look impossible.		For some reason the art of organizing the [[teamwork]] for [[distributed development]] or at least adjusting one's development style in such away is easier for really independent teams. Once you have a separated, but connected team (like [[I]] have in case of [[Truffle]], [[Graal]] and various [[GraalVM]] language teams), everything starts to look impossible.

-	Suddenly people tend to require upstream fixes as soon as possible. They want to access sources of such components and modify them without any restrictions. They stop thinking about the ~~projects~~ as [[modular]] components - rather they want to work with all of them as a whole.	+	Suddenly people tend to require upstream fixes as soon as possible. They want to access sources of such components and modify them without any restrictions. They stop thinking about the project as being composed from [[modular]] components - rather they want to work with all of them as a whole. That is obviously more comfortable, but also it is not scalable.

	Looks like everyone is worshiping modularity, but nobody wants to give an inch up to really have it.		Looks like everyone is worshiping modularity, but nobody wants to give an inch up to really have it.

JaroslavTulach at 11:58, 18 December 2017

2017-12-18T11:58:19Z

←Older revision		Revision as of 11:58, 18 December 2017
Line 1:		Line 1:
	Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.		Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.

-	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]]. On the other side the users of ~~these~~ libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work quite fine in this setup.	+	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].
		+
		+	On the other side of the system there are the end developers consuming the [[libraries]]. Their behavior is important as well. However the good thing is that the users of such libraries are fine to consume them as immutable component - e.g. as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work quite fine in this setup.

	Up stream [[library]] developers work on completely isolated schedule and down stream end developers have the freedom to upgrade to newer components at their own will. Things tend to work fine, until...		Up stream [[library]] developers work on completely isolated schedule and down stream end developers have the freedom to upgrade to newer components at their own will. Things tend to work fine, until...

JaroslavTulach at 11:56, 18 December 2017

2017-12-18T11:56:55Z

←Older revision		Revision as of 11:56, 18 December 2017
Line 1:		Line 1:
	Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.		Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.

-	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].	+	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]]. On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work quite fine in this setup.
-		+
-	On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work quite fine in this setup.	+

	Up stream [[library]] developers work on completely isolated schedule and down stream end developers have the freedom to upgrade to newer components at their own will. Things tend to work fine, until...		Up stream [[library]] developers work on completely isolated schedule and down stream end developers have the freedom to upgrade to newer components at their own will. Things tend to work fine, until...

JaroslavTulach: /* Bugfix Upstream */

2017-12-18T11:53:00Z

Bugfix Upstream

←Older revision		Revision as of 11:53, 18 December 2017
Line 9:		Line 9:
	==== Bugfix Upstream ====		==== Bugfix Upstream ====

-	From time to time there is a need to fix something in the up-stream component. What can one do then? In a well organized [[teamwork]], one would submit a [[~~patch~~]] to the upstream, used local fork of the project temporarily, wait for the upstream project to produce fixed version and switch to it once it is published. That would be ideal state, but...	+	From time to time there is a need to fix something in the up-stream component. What can one do then? In a well organized [[teamwork]], one would submit a patch (well an [[API Patch]] as it has to change an observable aspect of the [[library]], e.g. an [[API]]) to the upstream, used local fork of the project temporarily, wait for the upstream project to produce fixed version and switch to it once it is published. That would be ideal state, but...

	... it is too much hassle! Rather than that the end developers hack. They workaround issues in upstream projects and once they get their own application running, they forget about the workaround. That is indeed the simplest solution at the moment - why think about future development? Why be afraid that a workaround may stop working in subsequent versions? Why worry now?		... it is too much hassle! Rather than that the end developers hack. They workaround issues in upstream projects and once they get their own application running, they forget about the workaround. That is indeed the simplest solution at the moment - why think about future development? Why be afraid that a workaround may stop working in subsequent versions? Why worry now?

JaroslavTulach at 11:48, 18 December 2017

2017-12-18T11:48:47Z

←Older revision		Revision as of 11:48, 18 December 2017
Line 3:		Line 3:
	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].		It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].

-	On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work ~~find~~ in this setup~~. Library developers work on completely isolated schedule and end developers have the freedom to upgrade to newer components at their own will~~.	+	On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work quite fine in this setup.

-	Things tend to work fine, until...	+	Up stream [[library]] developers work on completely isolated schedule and down stream end developers have the freedom to upgrade to newer components at their own will. Things tend to work fine, until...

	==== Bugfix Upstream ====		==== Bugfix Upstream ====

JaroslavTulach at 11:38, 18 December 2017

2017-12-18T11:38:16Z

←Older revision		Revision as of 11:38, 18 December 2017
Line 1:		Line 1:
	Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.		Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.

-	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].	+	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Spring]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].

	On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work find in this setup. Library developers work on completely isolated schedule and end developers have the freedom to upgrade to newer components at their own will.		On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work find in this setup. Library developers work on completely isolated schedule and end developers have the freedom to upgrade to newer components at their own will.

JaroslavTulach at 11:37, 18 December 2017

2017-12-18T11:37:55Z

←Older revision		Revision as of 11:37, 18 December 2017
Line 1:		Line 1:
-	Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere. It is relatively easy to ~~consumer~~ well written libraries developed by completely independent teams (think of [[JUnit]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].	+	Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere.
		+
		+	It is relatively easy to consume well written libraries developed by completely independent teams (think of [[JUnit]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].

	On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work find in this setup. Library developers work on completely isolated schedule and end developers have the freedom to upgrade to newer components at their own will.		On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work find in this setup. Library developers work on completely isolated schedule and end developers have the freedom to upgrade to newer components at their own will.

JaroslavTulach at 11:36, 18 December 2017

2017-12-18T11:36:11Z

←Older revision		Revision as of 11:36, 18 December 2017
Line 5:		Line 5:
	Things tend to work fine, until...		Things tend to work fine, until...

-	==== Bugfix Upstream ===	+	==== Bugfix Upstream ====

	From time to time there is a need to fix something in the up-stream component. What can one do then? In a well organized [[teamwork]], one would submit a [[patch]] to the upstream, used local fork of the project temporarily, wait for the upstream project to produce fixed version and switch to it once it is published. That would be ideal state, but...		From time to time there is a need to fix something in the up-stream component. What can one do then? In a well organized [[teamwork]], one would submit a [[patch]] to the upstream, used local fork of the project temporarily, wait for the upstream project to produce fixed version and switch to it once it is published. That would be ideal state, but...

JaroslavTulach at 11:36, 18 December 2017

2017-12-18T11:36:01Z

←Older revision		Revision as of 11:36, 18 December 2017
Line 1:		Line 1:
-	Applications ~~can~~ no longer be written from scratch. They ~~need to be~~ assembled from [[modularity\|modular]] pieces. ~~The art~~ of ~~organizing the~~ [[~~teamwork~~]] ~~or at least the~~ development ~~style~~ in a way ~~that developement schedules can remain independent is called~~ [[~~distributed~~ development]]. ~~Its essential piece~~ is a [[~~modularity~~]] and [[BackwardCompatibility]]. ~~When~~ you have ~~these~~, ~~you~~ have the ~~freedom~~ to ~~stick~~ with ~~older version~~ of a ~~software and at any suitable time migrate~~ to ~~newer one~~.	+	Applications are no longer written from scratch. They are assembled from [[modularity\|modular]] pieces coming from elsewhere. It is relatively easy to consumer well written libraries developed by completely independent teams (think of [[JUnit]], [[Guava]], etc.). Developers of these components are relatively skilled to keep [[BackwardCompatibility]] - a first per-requisite for [[distributed development]].
		+
		+	On the other side the users of these libraries are fine to consume them as binaries. With tools like [[Maven]] it is then easy to assemble your application in a [[modular]] way. [[Distributed development]] seems to work find in this setup. Library developers work on completely isolated schedule and end developers have the freedom to upgrade to newer components at their own will.
		+
		+	Things tend to work fine, until...
		+
		+	==== Bugfix Upstream ===
		+
		+	From time to time there is a need to fix something in the up-stream component. What can one do then? In a well organized [[teamwork]], one would submit a [[patch]] to the upstream, used local fork of the project temporarily, wait for the upstream project to produce fixed version and switch to it once it is published. That would be ideal state, but...
		+
		+	... it is too much hassle! Rather than that the end developers hack. They workaround issues in upstream projects and once they get their own application running, they forget about the workaround. That is indeed the simplest solution at the moment - why think about future development? Why be afraid that a workaround may stop working in subsequent versions? Why worry now?
		+
		+	However nasty, this kind of development seems to work fine. [[Modularity]] of really distributed and distinct teams works!
		+
		+	==== Inside one Team ====
		+
		+	On the other hand, when one tries to apply the same principles to teams inside the same organization, one starts to get into troubles. The closer the teams are, the less acceptable it seems to be to consume just binaries and wait weeks (or at least days) for new version to be produced. Also, the closer the teams are, the less they think about [[BackwardCompatibility]] - suddenly the whole [[distributed development]] idea starts to be unsound.
		+
		+	== Distant Teams ==
		+
		+	For some reason the art of organizing the [[teamwork]] for [[distributed development]] or at least adjusting one's development style in such away is easier for really independent teams. Once you have a separated, but connected team (like [[I]] have in case of [[Truffle]], [[Graal]] and various [[GraalVM]] language teams), everything starts to look impossible.
		+
		+	Suddenly people tend to require upstream fixes as soon as possible. They want to access sources of such components and modify them without any restrictions. They stop thinking about the projects as [[modular]] components - rather they want to work with all of them as a whole.
		+
		+	Looks like everyone is worshiping modularity, but nobody wants to give an inch up to really have it.