Choose Your Tools with Care - Revision history

Gasproni: Choose Your Tools Wisely moved to Choose Your Tools with Care: New title sounds better

2009-06-25T14:11:50Z

Choose Your Tools Wisely moved to Choose Your Tools with Care: New title sounds better

←Older revision

Revision as of 14:11, 25 June 2009

Kevlin: Choose your tools wisely moved to Choose Your Tools Wisely

2009-06-23T16:37:58Z

Choose your tools wisely moved to Choose Your Tools Wisely

←Older revision

Revision as of 16:37, 23 June 2009

Kevlin at 16:37, 23 June 2009

2009-06-23T16:37:13Z

←Older revision		Revision as of 16:37, 23 June 2009
Line 1:		Line 1:
-	Modern applications are very rarely built from scratch, but they are assembled using existing tools--components, libraries, and frameworks--for ~~some very~~ good reasons:	+	Modern applications are very rarely built from scratch, but they are assembled using existing tools — components, libraries, and frameworks — for a number of good reasons:
-	* Applications are growing in size, complexity, and sophistication, while the time available to develop them is ~~less~~ and ~~less, so it is much better~~ if ~~developers~~ can concentrate in writing more business-domain code and less infrastructure code	+
-	* Widely used components and frameworks are likely to have fewer bugs than the ones developed in house	+	* Applications are growing in size, complexity, and sophistication, while the time available to develop them grows shorter. It is makes better use of developers' time and intelligence if they can concentrate on writing more business-domain code and less infrastructure code.
-	* There is a lot of high quality software available on the web for free, which means ~~less~~ development costs, and ~~higher~~ likelihood of finding developers with the necessary expertise	+	* Widely used components and frameworks are likely to have fewer bugs than the ones developed in-house.
-	* Software production and maintenance is human intensive work, so buying may be cheaper than building	+	* There is a lot of high-quality software available on the web for free, which means lower development costs and greater likelihood of finding developers with the necessary interest and expertise.
		+	* Software production and maintenance is human-intensive work, so buying may be cheaper than building.

	However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind:		However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind:
-	* Different tools may rely on different assumptions about their surroinding context--e.g., surrounding infrastructure, control model, data model, communication protocols, etc.--leading to an "architectural mismatch" which, in order to be fixed, may require hacks and workarounds that will make the code much more complex than necessary
-	* Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools. The more the tools the worse the problem becomes
-	* Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow very big very quickly. If this happens, the application may end up looking as if it was all written in XML plus a bunch of lines of code in some programming language, and it may become quite difficult to maintain and extend
-	* Vendor lock-in. Code that depends heavily on specific vendor products ends up in being constrained by them on several accounts: maintainability, performances, ability to evolve, price, etc.
-	* If you plan to use free software, you might discover that it's not free, after all. You may need to buy commercial support, which is not necessarily going to be cheap
-	* Licensing terms matter; even for free software. For example, in some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code

-	~~My personal strategy~~ to ~~mitigate~~ the ~~problems above is to start small by using only~~ the tools that ~~are absolutely~~ necessary~~--usually, to get rid of some low level infrastructure problems right away, e.g~~., ~~by using some middleware instead~~ of ~~using raw sockets for distributed applications--~~and ~~add more if needed~~. ~~I also tend to isolate~~ the ~~external~~ tools ~~from my business domain objects~~ by means of ~~interfaces and layering~~, ~~so that I~~ can ~~change the tool if I have to with just a small amount~~ of ~~pain~~. ~~A positive side effect of this approach is that I generally~~ end up ~~with~~ a ~~smaller~~ application that ~~uses fewer external tools than originally forecasted~~.	+	* Different tools may rely on different assumptions about their surrounding context — e.g., surrounding infrastructure, control model, data model, communication protocols, etc. — which can lead to an ''architectural mismatch'' between the application and the tools. Such a mismatch leads to hacks and workarounds that will make the code more complex than necessary.
		+	* Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools. The greater the number tools the worse the problem can become.
		+	* Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow out of control very quickly. The application may end up looking as if it was all written in XML plus a few odd lines of code in some programming language. The configurational complexity will make the application difficult to maintain and to extend.
		+	* Vendor lock-in occurs when code that depends heavily on specific vendor products ends up being constrained by them on several counts: maintainability, performances, ability to evolve, price, etc.
		+	* If you plan to use free software, you may discover that it's not so free after all. You may need to buy commercial support, which is not necessarily going to be cheap.
		+	* Licensing terms matter, even for free software. For example, in some companies it is not acceptable to use software licensed under the GNU license terms because of its viral nature — i.e., software developed with it must be distributed along with its source code.

		+	My personal strategy to mitigate these problems is to start small by using only the tools that are absolutely necessary. Usually the initial focus is on removing the need to engage in low-level infrastructure programming (and problems), e.g., by using some middleware instead of using raw sockets for distributed applications. And then add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecast.

	By [[Giovanni Asproni]]		By [[Giovanni Asproni]]

Gasproni at 13:23, 7 May 2009

2009-05-07T13:23:43Z

←Older revision		Revision as of 13:23, 7 May 2009
Line 1:		Line 1:
-	In 1995 David Garlan et al., wrote "Future breakthroughs in software productivity may well depend on the software community’s ability to combine existing pieces of software to produce new applications". Nowadays, their prediction has become true. In fact modern applications are very rarely built from scratch, but they are assembled using existing tools--components, libraries, and frameworks--for some very good reasons:	+	Modern applications are very rarely built from scratch, but they are assembled using existing tools--components, libraries, and frameworks--for some very good reasons:
	* Applications are growing in size, complexity, and sophistication, while the time available to develop them is less and less, so it is much better if developers can concentrate in writing more business-domain code and less infrastructure code		* Applications are growing in size, complexity, and sophistication, while the time available to develop them is less and less, so it is much better if developers can concentrate in writing more business-domain code and less infrastructure code
	* Widely used components and frameworks are likely to have fewer bugs than the ones developed in house		* Widely used components and frameworks are likely to have fewer bugs than the ones developed in house

Gasproni at 13:22, 7 May 2009

2009-05-07T13:22:40Z

←Older revision		Revision as of 13:22, 7 May 2009
Line 11:		Line 11:
	* Vendor lock-in. Code that depends heavily on specific vendor products ends up in being constrained by them on several accounts: maintainability, performances, ability to evolve, price, etc.		* Vendor lock-in. Code that depends heavily on specific vendor products ends up in being constrained by them on several accounts: maintainability, performances, ability to evolve, price, etc.
	* If you plan to use free software, you might discover that it's not free, after all. You may need to buy commercial support, which is not necessarily going to be cheap		* If you plan to use free software, you might discover that it's not free, after all. You may need to buy commercial support, which is not necessarily going to be cheap
-	* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code	+	* Licensing terms matter; even for free software. For example, in some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code

	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecasted.		My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecasted.

Gasproni at 13:17, 7 May 2009

2009-05-07T13:17:55Z

←Older revision		Revision as of 13:17, 7 May 2009
Line 14:		Line 14:

	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecasted.		My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecasted.
-
-	[this is still work in progress]

Gasproni at 13:17, 7 May 2009

2009-05-07T13:17:12Z

←Older revision		Revision as of 13:17, 7 May 2009
Line 7:		Line 7:
	However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind:		However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind:
	* Different tools may rely on different assumptions about their surroinding context--e.g., surrounding infrastructure, control model, data model, communication protocols, etc.--leading to an "architectural mismatch" which, in order to be fixed, may require hacks and workarounds that will make the code much more complex than necessary		* Different tools may rely on different assumptions about their surroinding context--e.g., surrounding infrastructure, control model, data model, communication protocols, etc.--leading to an "architectural mismatch" which, in order to be fixed, may require hacks and workarounds that will make the code much more complex than necessary
-	* Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools	+	* Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools. The more the tools the worse the problem becomes
	* Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow very big very quickly. If this happens, the application may end up looking as if it was all written in XML plus a bunch of lines of code in some programming language, and it may become quite difficult to maintain and extend		* Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow very big very quickly. If this happens, the application may end up looking as if it was all written in XML plus a bunch of lines of code in some programming language, and it may become quite difficult to maintain and extend
	* Vendor lock-in. Code that depends heavily on specific vendor products ends up in being constrained by them on several accounts: maintainability, performances, ability to evolve, price, etc.		* Vendor lock-in. Code that depends heavily on specific vendor products ends up in being constrained by them on several accounts: maintainability, performances, ability to evolve, price, etc.
Line 13:		Line 13:
	* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code		* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code

-	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and ~~wrappers~~, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally ~~planned~~.	+	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecasted.

	[this is still work in progress]		[this is still work in progress]

Gasproni at 13:15, 7 May 2009

2009-05-07T13:15:33Z

←Older revision		Revision as of 13:15, 7 May 2009
Line 13:		Line 13:
	* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code		* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code

-	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and wrappers, so that I can change the tool if I have to with a ~~minimum~~ amount of pain.	+	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and wrappers, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally planned.

	[this is still work in progress]		[this is still work in progress]

Gasproni at 13:10, 7 May 2009

2009-05-07T13:10:57Z

←Older revision		Revision as of 13:10, 7 May 2009
Line 13:		Line 13:
	* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code		* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code

-	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., ~~use~~ some middleware instead of using raw sockets for distributed applications--and add more if needed.	+	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., by using some middleware instead of using raw sockets for distributed applications--and add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and wrappers, so that I can change the tool if I have to with a minimum amount of pain.

	[this is still work in progress]		[this is still work in progress]

Gasproni at 13:06, 7 May 2009

2009-05-07T13:06:20Z

←Older revision		Revision as of 13:06, 7 May 2009
Line 13:		Line 13:
	* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code		* Licensing terms matter; even for free software. In some companies in not acceptable to use software licensed under the GNU license terms due to its viral nature--i.e., software developed with it must be distributed along with its source code

-	~~By all means use components~~, ~~libraries and frameworks~~, ~~but make sure you choose them wisely~~.	+	My personal strategy to mitigate the problems above is to start small by using only the tools that are absolutely necessary--usually, to get rid of some low level infrastructure problems right away, e.g., use some middleware instead of using raw sockets for distributed applications--and add more if needed.

	[this is still work in progress]		[this is still work in progress]