Contribution 32 - Revision history

Rmonson at 17:25, 11 July 2008

2008-07-11T17:25:56Z

←Older revision		Revision as of 17:25, 11 July 2008
Line 1:		Line 1:
	== Get the 1000ft view ==		== Get the 1000ft view ==

-	As an architect we want to know how good the software is we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying "I know it when I see it." But how can we see quality?	+	As an architect we want to know how good the software is that we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying "I know it when I see it." But how can we see quality?

	In an architecture diagram little boxes represent entire systems and lines between them can mean anything: a dependency, the flow of data, or a shared resource such as a bus. These diagrams are a 30.000ft view, like a landscape seen from a plane. Typically the only other view available is the source code, which is comparable to a ground level view. Both views fail to convey much information about the quality of the software, one is too high level and the other provides so much information that we cannot see structure. Clearly, what is missing is a view in between, a 1000ft view.		In an architecture diagram little boxes represent entire systems and lines between them can mean anything: a dependency, the flow of data, or a shared resource such as a bus. These diagrams are a 30.000ft view, like a landscape seen from a plane. Typically the only other view available is the source code, which is comparable to a ground level view. Both views fail to convey much information about the quality of the software, one is too high level and the other provides so much information that we cannot see structure. Clearly, what is missing is a view in between, a 1000ft view.
Line 7:		Line 7:
	This 1000ft view would provide information at the right level. It aggregates large amounts of data and multiple metrics, such as method count, class fan out, or cyclomatic complexity. The actual view very much depends on a specific aspect of quality. It can be a visual representation of a dependency graph, a bar chart that shows metrics at a class level, or a sophisticated polymetric view that correlates multiple input values.		This 1000ft view would provide information at the right level. It aggregates large amounts of data and multiple metrics, such as method count, class fan out, or cyclomatic complexity. The actual view very much depends on a specific aspect of quality. It can be a visual representation of a dependency graph, a bar chart that shows metrics at a class level, or a sophisticated polymetric view that correlates multiple input values.

-	Manually creating such views and keeping them in sync with the software is a hopeless ~~endeavour~~. We need tools that create these views from the only true source, the source code. For some views, a design structure matrix for example, commercial tools exists but it is also surprisingly easy to create ~~specialised~~ views by combining small tools that extract data and metrics with generic ~~visualisation~~ packages. A simple example would be to load the output from checkstyle, which is essentially a set of metrics on the class and method level, into a spreadsheet to render charts. The same metrics could also be shown as a ~~treemap~~ using the InfoViz toolkit. A great tool to render complex dependency graphs is GraphViz.	+	Manually creating such views and keeping them in sync with the software is a hopeless endeavor. We need tools that create these views from the only true source, the source code. For some views, a design structure matrix for example, commercial tools exists but it is also surprisingly easy to create specialized views by combining small tools that extract data and metrics with generic visualization packages. A simple example would be to load the output from checkstyle, which is essentially a set of metrics on the class and method level, into a spreadsheet to render charts. The same metrics could also be shown as a tree-map using the InfoViz toolkit. A great tool to render complex dependency graphs is GraphViz.

-	Once a suitable view is available software quality becomes a little less subjective. It is possible to compare the software under development with a handful of similar systems. Comparing different revisions of the same system will give an indication of trends while comparing views of different subsystems can highlight outliers. Even with just a single diagram we can rely on our ability to spot patterns and perceive aesthetics. A well-balanced tree probably represents a successful class hierarchy, a harmonious set of boxes might show code that is ~~organised~~ into appropriately sized classes. Most of the time a very simple relationship holds: If it looks good it probably is good.	+	Once a suitable view is available software quality becomes a little less subjective. It is possible to compare the software under development with a handful of similar systems. Comparing different revisions of the same system will give an indication of trends while comparing views of different subsystems can highlight outliers. Even with just a single diagram we can rely on our ability to spot patterns and perceive aesthetics. A well-balanced tree probably represents a successful class hierarchy, a harmonious set of boxes might show code that is organized into appropriately sized classes. Most of the time a very simple relationship holds: If it looks good it probably is good.

-		+
		+	(RMH Edited 7/11/2008)

	By [[Erik Doernenburg]]		By [[Erik Doernenburg]]

Erikd: /* Get the 1000ft view */

2008-07-11T10:04:28Z

Get the 1000ft view

←Older revision		Revision as of 10:04, 11 July 2008
Line 1:		Line 1:
	== Get the 1000ft view ==		== Get the 1000ft view ==
-
-	#32 Get the 1000ft view
-
-	#32 Get the 1000ft view

	As an architect we want to know how good the software is we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying "I know it when I see it." But how can we see quality?		As an architect we want to know how good the software is we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying "I know it when I see it." But how can we see quality?

Erikd: /* Get the 1000ft view */

2008-07-11T10:04:14Z

Get the 1000ft view

←Older revision		Revision as of 10:04, 11 July 2008
Line 1:		Line 1:
	== Get the 1000ft view ==		== Get the 1000ft view ==

-	~~[early draft of~~ the ~~concept]~~	+	#32 Get the 1000ft view

-	~~How do you maintain~~ an ~~understanding of~~ the ~~structure of your~~ software~~? A lot of the problems~~ we are ~~dealing with are becoming very large~~. ~~Especially large organizations have huge portfolios of~~ software, ~~and it~~ is ~~very difficult~~ to understand ~~what they are~~ and ~~how they work together. You generally only either get~~ the ~~30000 foot view where every system has~~ a ~~small~~ little ~~box~~ and lines between them ~~denote an arbitrary relationship~~ or ~~you have~~ the ground level view ~~where you are looking~~ at actual source code, but that ~~doesn't help~~ the ~~developers~~, ~~that doesn't help~~ the ~~management~~ and ~~that doesn't help the enterprise architects~~. ~~So we are looking for~~ a ~~way~~ to ~~actually find some middle ground to get~~ a ~~100 foot~~ view, to ~~get~~ a ~~better understanding~~ of ~~software~~ systems.	+	#32 Get the 1000ft view
		+
		+	As an architect we want to know how good the software is we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying "I know it when I see it." But how can we see quality?
		+
		+	In an architecture diagram little boxes represent entire systems and lines between them can mean anything: a dependency, the flow of data, or a shared resource such as a bus. These diagrams are a 30.000ft view, like a landscape seen from a plane. Typically the only other view available is the source code, which is comparable to a ground level view. Both views fail to convey much information about the quality of the software, one is too high level and the other provides so much information that we cannot see structure. Clearly, what is missing is a view in between, a 1000ft view.
		+
		+	This 1000ft view would provide information at the right level. It aggregates large amounts of data and multiple metrics, such as method count, class fan out, or cyclomatic complexity. The actual view very much depends on a specific aspect of quality. It can be a visual representation of a dependency graph, a bar chart that shows metrics at a class level, or a sophisticated polymetric view that correlates multiple input values.
		+
		+	Manually creating such views and keeping them in sync with the software is a hopeless endeavour. We need tools that create these views from the only true source, the source code. For some views, a design structure matrix for example, commercial tools exists but it is also surprisingly easy to create specialised views by combining small tools that extract data and metrics with generic visualisation packages. A simple example would be to load the output from checkstyle, which is essentially a set of metrics on the class and method level, into a spreadsheet to render charts. The same metrics could also be shown as a treemap using the InfoViz toolkit. A great tool to render complex dependency graphs is GraphViz.
		+
		+	Once a suitable view is available software quality becomes a little less subjective. It is possible to compare the software under development with a handful of similar systems. Comparing different revisions of the same system will give an indication of trends while comparing views of different subsystems can highlight outliers. Even with just a single diagram we can rely on our ability to spot patterns and perceive aesthetics. A well-balanced tree probably represents a successful class hierarchy, a harmonious set of boxes might show code that is organised into appropriately sized classes. Most of the time a very simple relationship holds: If it looks good it probably is good.
		+
		+

	By [[Erik Doernenburg]]		By [[Erik Doernenburg]]

Erikd at 05:28, 26 May 2008

2008-05-26T05:28:58Z

←Older revision		Revision as of 05:28, 26 May 2008
Line 1:		Line 1:
	== Get the 1000ft view ==		== Get the 1000ft view ==
		+
		+	[early draft of the concept]

	How do you maintain an understanding of the structure of your software? A lot of the problems we are dealing with are becoming very large. Especially large organizations have huge portfolios of software, and it is very difficult to understand what they are and how they work together. You generally only either get the 30000 foot view where every system has a small little box and lines between them denote an arbitrary relationship or you have the ground level view where you are looking at actual source code, but that doesn't help the developers, that doesn't help the management and that doesn't help the enterprise architects. So we are looking for a way to actually find some middle ground to get a 100 foot view, to get a better understanding of software systems.		How do you maintain an understanding of the structure of your software? A lot of the problems we are dealing with are becoming very large. Especially large organizations have huge portfolios of software, and it is very difficult to understand what they are and how they work together. You generally only either get the 30000 foot view where every system has a small little box and lines between them denote an arbitrary relationship or you have the ground level view where you are looking at actual source code, but that doesn't help the developers, that doesn't help the management and that doesn't help the enterprise architects. So we are looking for a way to actually find some middle ground to get a 100 foot view, to get a better understanding of software systems.

Erikd: New page: == Get the 1000ft view == How do you maintain an understanding of the structure of your software? A lot of the problems we are dealing with are becoming very large. Especially large organ...

2008-05-26T05:16:38Z

New page: == Get the 1000ft view == How do you maintain an understanding of the structure of your software? A lot of the problems we are dealing with are becoming very large. Especially large organ...

New page

== Get the 1000ft view ==

How do you maintain an understanding of the structure of your software? A lot of the problems we are dealing with are becoming very large. Especially large organizations have huge portfolios of software, and it is very difficult to understand what they are and how they work together. You generally only either get the 30000 foot view where every system has a small little box and lines between them denote an arbitrary relationship or you have the ground level view where you are looking at actual source code, but that doesn't help the developers, that doesn't help the management and that doesn't help the enterprise architects. So we are looking for a way to actually find some middle ground to get a 100 foot view, to get a better understanding of software systems.

By [[Erik Doernenburg]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Software Architect Should Know]] home page