Don't Rely on "Magic Happens Here" - Revision history

Kevlin at 00:54, 17 July 2009

Kevlin — Fri, 17 Jul 2009 00:54:02 GMT

←Older revision		Revision as of 00:54, 17 July 2009
Line 1:		Line 1:
-	If ~~one looks~~ at any activity, process or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do.	+	If you look at any activity, process, or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do.

-	Programming is something some people do — some of the time. And the hard part — the thinking — is the least visible and ~~unappreciated~~ by the uninitiated. There have been many attempts to remove the need for this skilled thinking over the decades. One of the most memorable is the effort by Grace Hopper ~~early initiative~~ to make programming languages less cryptic — which some accounts predicted would remove the need for specialist programmers. The result (COBOL) has contributed to the income of many specialist programmers over the subsequent decades.	+	Programming is something some people do — some of the time. And the hard part — the thinking — is the least visible and least appreciated by the uninitiated. There have been many attempts to remove the need for this skilled thinking over the decades. One of the earliest and most memorable is the effort by Grace Hopper to make programming languages less cryptic — which some accounts predicted would remove the need for specialist programmers. The result (COBOL) has contributed to the income of many specialist programmers over the subsequent decades.

	The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obviously naïve. But the mental process that leads to this mistake is part of human nature and programmers are just as prone to making it as everyone else.		The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obviously naïve. But the mental process that leads to this mistake is part of human nature and programmers are just as prone to making it as everyone else.

-	On any project there are likely a lot of things that an individual programmer doesn't get actively involved in ~~—~~ eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old, ...	+	On any project there are likely a lot of things that an individual programmer doesn't get actively involved in: eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old, etc.

-	When ~~one isn~~'t actively involved in things there is an unconscious tendency to assume that they are simple and happen "by magic". While the magic continues to happen all is well — ~~but when (~~it is usually "when" and not "if") the magic stops the project is in trouble.	+	When you aren't actively involved in things there is an unconscious tendency to assume that they are simple and happen "by magic." While the magic continues to happen all is well. But when — it is usually "when" and not "if" — the magic stops the project is in trouble.

-	I've known projects lose weeks of developer time because no-one understood how they relied on "the right" version of a DLL being loaded ~~— and when~~ things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded.	+	I've known projects lose weeks of developer time because no one understood how they relied on "the right" version of a DLL being loaded. When things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded.

-	Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly in fact that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation — late, buggy and continually being patched.	+	Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly, in fact, that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation — late, buggy and continually being patched.

	You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't.		You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't.

AlanGriffiths at 13:13, 16 July 2009

AlanGriffiths — Thu, 16 Jul 2009 13:13:57 GMT

←Older revision		Revision as of 13:13, 16 July 2009
Line 17:		Line 17:
	Most importantly, make sure that when the magic stops it can be started again.		Most importantly, make sure that when the magic stops it can be started again.

-	By [[~~Alan Griffiths~~]]	+	By [[AlanGriffiths]]

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

AlanGriffiths at 08:41, 16 July 2009

AlanGriffiths — Thu, 16 Jul 2009 08:41:50 GMT

←Older revision		Revision as of 08:41, 16 July 2009
Line 1:		Line 1:
-	If one looks at any activity, process or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do.	+	If one looks at any activity, process or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do.

-	~~On any project there are likely a lot~~ of ~~things that a programmer often doesn't get actively involved in~~ — ~~eliciting requirements from users, getting budgets approved, setting up~~ the ~~build server, deploying~~ the ~~application to QA~~ and ~~production environments, migrating~~ the ~~business from~~ the ~~old, .~~...	+	Programming is something some people do — some of the time. And the hard part — the thinking — is the least visible and unappreciated by the uninitiated. There have been many attempts to remove the need for this skilled thinking over the decades. One of the most memorable is the effort by Grace Hopper early initiative to make programming languages less cryptic — which some accounts predicted would remove the need for specialist programmers. The result (COBOL) has contributed to the income of many specialist programmers over the subsequent decades.

-	~~When one isn't actively involved in things there is an unconscious tendency to assume~~ that ~~they happen "~~by ~~magic"~~. ~~While~~ the ~~magic continues~~ to ~~happen all~~ is ~~well — but when (it is usually "when"~~ and ~~not "if") the magic stops the project is in trouble~~.	+	The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obviously naïve. But the mental process that leads to this mistake is part of human nature and programmers are just as prone to making it as everyone else.

-	I'~~ve known projects lose weeks of developer time because no-one understood how they relied on "the right" version of a DLL being loaded~~ — and ~~when things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of~~ the ~~DLL was being loaded~~.	+	On any project there are likely a lot of things that an individual programmer doesn't get actively involved in — eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old, ...

-	Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly in fact that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation ~~—~~ late, buggy and continually being patched.	+	When one isn't actively involved in things there is an unconscious tendency to assume that they are simple and happen "by magic". While the magic continues to happen all is well — but when (it is usually "when" and not "if") the magic stops the project is in trouble.
		+
		+	I've known projects lose weeks of developer time because no-one understood how they relied on "the right" version of a DLL being loaded — and when things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded.
		+
		+	Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly in fact that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation — late, buggy and continually being patched.

	You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't.		You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't.
		+
		+	Most importantly, make sure that when the magic stops it can be started again.

	By [[Alan Griffiths]]		By [[Alan Griffiths]]

Kevlin: Don't rely on "magic happens here" moved to Don't Rely on "Magic Happens Here"

Kevlin — Mon, 22 Jun 2009 18:18:34 GMT

Don't rely on "magic happens here" moved to Don't Rely on "Magic Happens Here"

←Older revision

Revision as of 18:18, 22 June 2009

Kevlin at 18:17, 22 June 2009

Kevlin — Mon, 22 Jun 2009 18:17:34 GMT

←Older revision		Revision as of 18:17, 22 June 2009
Line 1:		Line 1:
-	If one looks at any activity, process or ~~dicipline~~ from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and ~~programms~~ with no experience of management think the same of what managers do.	+	If one looks at any activity, process or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do.

-	On any project there are likely a lot of things that a programmer often doesn't get actively involved in - eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old, ...	+	On any project there are likely a lot of things that a programmer often doesn't get actively involved in — eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old, ....

-	When one isn't actively involved in things there is an ~~unconsious~~ tendency to assume that they happen "by magic". While the magic continues to happen all is well - but when (it is usually "when" and not "if") the magic stops the project is in trouble.	+	When one isn't actively involved in things there is an unconscious tendency to assume that they happen "by magic". While the magic continues to happen all is well — but when (it is usually "when" and not "if") the magic stops the project is in trouble.

-	I've known projects lose weeks of developer time because no-one understood how they relied on "the right" version of a DLL being loaded - and when things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded.	+	I've known projects lose weeks of developer time because no-one understood how they relied on "the right" version of a DLL being loaded — and when things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded.

-	Another department was running smoothly - projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly in fact that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation - late, buggy and continually being patched.	+	Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly in fact that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation — late, buggy and continually being patched.

-	You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it - or to appreciate someone who understands the bits you don't.	+	You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't.
		+
		+	By [[Alan Griffiths]]
		+
		+	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

AlanGriffiths: New page: If one looks at any activity, process or dicipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programms with ...

AlanGriffiths — Tue, 24 Feb 2009 12:52:49 GMT

New page: If one looks at any activity, process or dicipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programms with ...

New page

If one looks at any activity, process or dicipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programms with no experience of management think the same of what managers do.

On any project there are likely a lot of things that a programmer often doesn't get actively involved in - eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old, ...

When one isn't actively involved in things there is an unconsious tendency to assume that they happen "by magic". While the magic continues to happen all is well - but when (it is usually "when" and not "if") the magic stops the project is in trouble.

I've known projects lose weeks of developer time because no-one understood how they relied on "the right" version of a DLL being loaded - and when things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded.

Another department was running smoothly - projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly in fact that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organisation - late, buggy and continually being patched.

You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it - or to appreciate someone who understands the bits you don't.