Working 40 Hours in 3 Days? Possibilities for Making it Work

I've been thinking about different kinds of work schedules. I found this poll interesting:

http://boards.straightdope.com/sdmb/showthread.php?t=608388

Question: If you could choose your own work week hours

Responses:

5 hours, 42 minutes/day, 7 days a week		0	0%
6 hours, 40 minutes/day, 6 days a week		0	0%
8 hours/day, 5 consecutive days a week		10	12.35%
8 hours/day, 5 non-consecutive days a week		2	2.47%
10 hours/day, 4 consecutive days a week		32	39.51%
10 hours/day, 4 non-consecutive days a week		9	11.11%
13 hours, 20 minutes/day, 3 consecutive days a week		13	16.05%
13 hours, 20 minutes/day, 3 non-consecutive days a week		1	1.23%
20 hours/day, 2 consecutive days a week		0	0%
20 hours/day, 2 non-consecutive days a week		0	0%
40 consecutive hours a week		0	0%
40 varyingly distributed hours (i.e. something else)		11	13.58%
I'm retired		3	3.70%

So, is it really possible to do 3 straight days, 13.20 each, and then have 4 days off each week?

Of course, it is possible if you can swing it and really want to.

Some variations:

12:05 - 6:05 AM sleep
7:00 - 1:30 6.5 hours work
1:30 - 2:15 lunch
2:15 - 3:15 nap
3:15 - 6:45 3.5 hours work
6:45 - 8:45 dinner, socialize/family, exercise (whatever you want)
8:45 - 12:05 3 hours, 20 minutes work

Maybe you'd prefer to exercise from 2:15 to 3:15 instead of nap, and do an evening nap later before the last sprint, but whatever.

If you could get by on 6 hours nightly sleep PLUS the nap during the day or evening.

Or maybe you could try two 6:40 segments from 7 to 1:40 and 5:20 to midnight.

Alternative to three day: 3 big days, 1 tiny day

The more I think about it, the more I like the idea, in general, but 13:20 seems to push it a bit too far.

How about:

7:30 - 1:30 work (You can eat some snacks while working to tide you over before lunch; besides, isn't it said you should have small meals throughout the day anyway?)

1:30 - 6:00 free time. Eat, drink, visit friends, family, do errands, and take a nap after an earlyish dinner. Sleep from 5 to 6 to get your second wind ready.

6:00 - 12 work

This ends up at 12 hours. Or maybe you could handle 7:30 to 3:30, followed by 8 - 12. You get the picture.

The Numbers Game

After 3 days, it's 36 hours worked. On Thursday morning, you do 4 hours of review and preparation for the next week's worth of work.

But, the big benefit is now it's noon on Thursday, and you have 3 and a half days completely to yourself, your family and friends, and your own goals.

Lots of small excursions or even just local travels can be done in 3.5 days. 

Suppose you have 3 weeks off and 10 holidays. You probably still end up working something like 1,880 hours a year.

There are 8760 hours in a full year. Subtract 8 a day for sleep. You're still left with 5840.

So, you already have about 3960 to yourself. That's 100 more than twice 1,880!

The Trouble With Today's Work Environments

So, why is it so difficult these days to actually feel like you're not working all the time? Maybe it's because you actually are, in your brain.

It's not always possible to "just turn off" your brain when you're working on difficult, and interesting, problems to solve.

And, when you work in technology, sometimes a "schedule" like 9-5 is a ridiculous thing to even talk about. Creative problem solving work is not the same thing as assembling parts in a factory that have *already been creatively designed by someone else long ago and made into a formulaic process to follow*. It can, and should, be mentally exhausting work to create technological products and services properly.

Poorly designed technologies often result when people are completely burnt out and treated as if they belong in the long out-dated stereotypical factories of the 19th and 20th century.

Work Hard, Recover Harder

A lot of self-styled "rugged" or "progressive" companies adore the phrase "Work Hard, Play Hard", or something like that. Often this works out to something more like:

"We own this company, and you work for us, but we also like to have fun -- at least, the kind of fun that we deem to be fun, and therefore you also should deem to be fun. Therefore, when you are here, you will work hard, and we will inject our form of 'fun' into the day in order for you to see us as a company that also 'plays hard'."

Needless to say, this is misguided.

Daniel Pink's Drive and the Results Only Work Environment

Have you read Drive, by Daniel Pink? If not, have you heard what BestBuy's corporate office did? They turned themselves into what they call a ROWE, a results-only work environment. Here's more about the people who pioneered the concept:

http://www.gorowe.com/

Results-Only Work Environment goes beyond telework. It's a management strategy where employees are evaluated on performance, not presence. In a ROWE, people focus on results and only results – increasing  the  organization's performance while cultivating the right environment for people to manage all the demands in their lives...including work.

Think this is just a gimmick, that BestBuy is a fluke? Think again. How about these companies:

http://www.gorowe.com/about/clients/ 

Are they flukes too? Gap, Banana Republic, etc. 

Personal Summation

In the modern age, it's ridiculous to expect creative, skilled knowledge and information workers to want to work the "routines" of the 19th and 20th centuries. Obviously, companies like BestBuy Corporate, GAP, etc have found better ways of working and retaining talented thinkers and leaders.

Working 9 to 5 (or 7 to 5, or whatever) 5 days a week is not a badge of honor. It's often a curse, because many of us do not, cannot, simply be "present" for x number of hours and turn off our brains and attend to "the rest of life". We are goal and results-oriented, and want to create valuable results by working long hours that require intense concentration and attention to details that often get overlooked.

So, in a culture that, at large, has not yet adapted to the mental and creative demands of the 21st century, we must find ways to "put in our 40" creatively, and in a sustainable way.

For me, that definitely means giving a short at "4 10s", or even "3 12s and a 4".

Wish me luck.

Test

test

Leading Technical Teams is Not Like Managing an Assembly Line

Often times people who grew up in another era or time equate management with "task mastering". This is unfortunate when it comes to the management of software projects, because it's not an effective way to manage people, products, services, or projects.

I don't have much to say that has not been said better elsewhere on this subject.

Two good references are Mary Poppendieck's presentation named The Role of Leadership in Software Development:

http://www.youtube.com/watch?v=ypEMdjslEOI

And, Daniel Pink's book Drive: The Surprising Truth About What Motivates Us:

http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/0143145088

Sonatina I Progress, the Wisdom of Slowness in Music Practice, and Agile Songware Development

I've decided to mostly keep just one blog and start doing a better job with tags for separating out categories. In that spirit, this one is for my own tracking of piano progress. But, it will have some tangents with agile, anyway.

A few years ago when I decided I wanted to stop just toying with "Alfred's All in One Adult Beginner Course", I realized I needed to focus on one complete song, from end to end. I even joked with a coworker who I had helped introduce Scrum at a company with that I was going to work toward a "potentially performable songware increment", like Scrum's "potentially shippable software increment".

This absolutely worked for me. I focused on learning a relatively short song called "October", a song that features mostly piano, from the 1981 album of the same name by U2. I picked this because I remembered long ago wondering what I would have to do to play it if I actually knew how to play piano.

But, it also reminded me of my aunt Kara, because she had introduced U2's music to me when I was 10 years old in 1987 by handing me a copied tape of The Joshua Tree, complete with a photo-copied insert cover.

Kara was by this later time in 2008 ill with Lou Gehrig's disease. I wanted to be able to play the song someday for her. I soon became proficient enough with the song on my little electronic keyboard, and recorded it on MP3 and sent it to her. Later, after she passed away in early 2011, I performed the song at her memorial service, which was about a year ago now in June of 2011.

For me, someone who had only played a recorder in 2nd grade, to ever have imagined myself performing anything musical in front of people was a big confidence booster. I did not make any glaring mistakes either, which I was also happy about (phew!)

During the process of *learning how to play that first "playable song increment"*, there is no way a teacher would look at what I was doing and say my form was correct, or that my fingering was optimal.

I had one teacher as Little Five Points Music Center, Natia, who helped me get through that first song and started me on what has become a more "methodologically sound" approach to learning, which includes understanding reading music, understanding scales, intervals, chords, modes, etc.

But, again, in the beginning, I simply forced myself, note by note and measure by measure to figure out which keys to push down with the right hand and which to hold down with the left hand, and eventually when to push the pedal with my foot -- which I still don't have totally correct.

I have now been taking lessons with Charles Hutton, from Charles Hutton Piano Studio, for almost a year now after that first performance. He has helped me start from where I was to progress through playable "increments" of music that teach the fundamentals of scales, chords, inversions, and intervals. Each song has helped me to experience the important satisfaction of adding to my reportoire, or my "portfolio" if you will, while also learning about those musical theory concepts.

I would, as I am sure he would, still classify myself as an "Advanced Beginner". But, if you are the kind of learner, like I am, who cannot sit still, physically or mentally, without a combined practical and theoretical understanding, then I would definitely recommend Charles and his approach for learning.

Touching back on agile software, we know that Iteration is fundamental to Incremental delivery. That,is, one must build a software module in an iterative fashion. Iteration means approaching the analysis, design, development, deployment, and testing in repeated cycles. This is coupled with incrementalism, which means approaching the problem by breaking the large goal, the entire system, into smaller slices.

During each iteration, learning happens. This learning then feeds back into the next iterative step. This process cycles round and round and continues to pull in more and more incremental slices of the system as it goes. This process resembles the "Plan Do Check Act" approach, and even the basics of the "Scientific Method".

Given a piece of music, it is already replete with requirements! After all, the sheet music is staring you in the face. All you have to do is read that requirements document and just play it.

Of course, a software requirements document is rarely anywhere near as complete or unambiguous as a sheet of music is. No, not even close, and that is a subject for a different day.

It is actually highly possible for well trained, seasoned musicians, of course, to sit down in front of a piano and play directly from the sheet music the first time they see it. Sometimes in one sitting they can get it "right". Even then, they will rarely feel like they did it perfectly the first time, and will repeat it many times before feeling proficient.

I have been struggling to feel any real progress recently in learning new songs, partly due to lack of practice time, but partly due to gaps in my approach, which Charles has helped me to see and approach differently, and in fact much closer to the way I develop a software program anyway.

Here's how:

First, from reading Neil Miller's The Piano Lessons Book, I became convinced of the "Learn it Backwards" method, something Charles also said other teachers call "The Reverse Brick Laying Method".

This means take the last two measures of a song, learn those FIRST! Then, add measures backward toward the beginning.

Why? Well, when you start to play back what you have practiced this way, you start at what you more recently learned, and have played fewer times, and progress toward measures you have played more often.

Since you have played them fewer times, you are more likely to make a mistake on those, and will thus waste less time than if you were to always play back from the beginning and into less frequently practiced measures toward the end.

However, Charles helped me to start to logically segment pieces into phrases and groups of measures that flow well together. So, in my current piece, Sonatina I by Thomas Attwood, we have marked off measures 17 to 24 as a logical group.

Within that, we have:

17 to 18 Right Hand
19 to 20 RH
17 to 20 RH
21 to 22 RH
21 to 24 RH
17 to 24 RH

Then, same thing but with Left Hand, or bass.

And, then trying them with both left and right hands.

As you can tell, this is the epitome of an Iterative, and Incremental development process.

And, it is also an iterative and incremental analysis, design, and delivery method.

Here is how Charles has explained what should happen when practicing this way, and what it should feel like:

When playing 17 to 18, do it slowly enough to play the notes correctly, and with the correct fingering, ignoring the rhythm count for the moment.

Next, try it again, slightly faster.

If I make a mistake, then learning has not happened properly yet, and something is wrong. Stop the line. Correct it immediately. Go back.

But, wait, here is where we diverge from "Lean Manufacturing" and it's "stop the line" mantra you may recognize and move closer into agile software, at least the way I see agile.

As Charles explained it, helping me get past my reluctance to move further into more measures, you MUST move forward when still uncomfortable, and while still *making mistakes*.

That is: yes, stop and fix the measure, to a point. But, after correcting it to a sufficient degree, expand the surface area of practice. Move down to measures 19 and 20. If you flub on those, also stop and fix, but only to the point of basic comfort.

Then, cycle back (iterate) on measures 17 through 20.

Again, this iteration should procede slowly enough to get the notes correct the first time. But, next it should be played at a more uncomfortable, error-prone pace.

When making errors at this pace, seek to "pin point" where, and then "zoom in" on those points.

Are they transition points?

Are they fingering oddities or shifts?

Incorrect fingerings?

Incorrect timing? Held a note too long, not long enough?

The diagnosis will vary from "fracture" to fracture, now zoom in and correct it in *isolation*, or in collaboration with adjacent measures to assure smooth entry and exit.

According to Charles, doing this will NOT feel comfortable, and mistakes and fractures will happen. This is expected and good, and the remedy is the iterative process, the repeition, the cycle.

What mitigates against the failure besides the repitition? What ensures eventual success?

Well, quite simply: your own ears and others' ears. The expectation of correct playback is already encoded in our ears. We will know it when we hear it. Fair enough.

The parallel to software development here is more nuanced. We cannot know that a subsystem of function works by hearing or seeing it! Most of software happens below the user interface, and nobody ever sees or hears it.

This is why the test-driven, unit-test covered, and acceptance-test driven approaches to software are so important.

TODO: fnsh

Draft: The Centers for Defect Control and Prevention: Public Health and Epidemiology Principles for the Development of Information Systems

Introduction

Have you ever thought much about the following statement?

"CDC 24/7: Saving Lives, Protecting People, Saving Money through Prevention"

This is the banner headline on http://www.cdc.gov, the home page for the United States Centers for Disease Control and Prevention. It's an important statement that conveys the constant vigilance, goals, and primary mindset required in today's world needed to help keep people healthy!

Another thing you may have never thought about is the vast and varied number of information systems required for epidemiologists and other public health professionals to quickly and reliably perform the public health surveillance and other scientific work required to achieve their goals of improving human health. It's easy to understand why such systems are necessary, though. Simply consider how quickly people travel today from country to country and how quickly infectious diseases can spread. Recall the SARS pandemic from 2003 as an example.

In the world of public health, these systems operate all over the United States and world, at local, state, territorial, and federal levels and in collaboration across national boundaries. They empower the public health workforce to control and prevent disease in a variety of biological populations. Human health also depends upon animal health and the health of plants, trees, and ecosystems as a whole. The entire ecosystem is the shared environment, or context, within which we all live.

Disclaimer

I do not work directly for CDC or as a federal employee, so these opinions are based only in my own experience working with contracting companies on technology teams providing services to CDC and the public health community at large. I am also not a public health expert, so these ideas are a work-in-progress as my own understanding of public health and epidemiology evolves.

Article Series Goal: Building The Centers for Defect Control and Prevention

Having helped build CDC mission-critical information systems that protect the public's health, I feel is important to share ideas for improving those systems and the process undertaken to build them. This is the first of a multi-part series of articles that will create a vision for CDC's information systems acquisition and development process, a vision that applies the very principles of public health itself and epidemiology to guide those processes. As we'll see, there are already many parallel concepts between the disciplines. The goal is that CDC should also stand for Centers for Defect Control and Prevention when it comes to its information systems.

This first article will introduce several fundamental concepts of epidemiology and disease control and prevention while drawing parallels with the activities necessary for designing and developing successful, useful, and cost-effective information systems. 

Terms we'll introduce related to epidemiology are:

• Epidemiology
• Populations
• Control (as in controlling health problems)
• Disease
• Determinant
• Incidence
• Prevalence
• Incubation Period
• Subclinical Infection
• Quarantine and Isolation

For each of these concepts from the domain of epidemiology, which pertains to biological, chemical, ecological (ultimately physical) objects, we'll draw parallel models within the world of information systems which pertain, ultimately, to technological objects.

Definition: Epidemiology 

CDC defines epidemiology as:

The study of the distribution and determinants of health-related states in specified populations, and the application of this study to control health problems.

Source: http://www.cdc.gov/excite/classroom/outbreak/steps.htm

There is a lot more to say about that, but for this article, let's highlight these two parts:

• Populations—One of the most important distinguishing characteristics of epidemiology is that it deals with groups of people rather than with individual patients.
• Control—Although epidemiology can be used simply as an analytical tool for studying diseases and their determinants, it serves a more active role. Epidemiological data steers public health decision making and aids in developing and evaluating interventions to control and prevent health problems. This is the primary function of applied, or field, epidemiology.

Controlling and Preventing Information System Disease in Populations of Technological Objects 

Information systems are like ecosystems. But, instead of being composed of populations of biological objects, they're composed of populations of technological objects. Beyond that obvious differences in these types of populations are a great many similarities regarding control and prevention surveillance and intervention techniques needed to keep these populations healthy and free of disease.

Wait, can information systems really be diseased? I believe they can, and that all too many of them are. 

Here's a standard dictionary definition of the word "disease":

"a disordered or incorrectly functioning organ, part, structure, or system of the body resulting from the effect of genetic or developmental errors, infection, poisons, nutritional deficiency or imbalance, toxicity, or unfavorable environmental factors; illness; sickness; ailment."

Source: http://dictionary.reference.com/browse/disease

Definition: Information System Disease 

Here's my adapted definition for "Information System Disease": 

"an incorrectly functioning or incomplete component, feature, sub-system, or unit of a an information system resulting from the effect of requirements, design, or developmental errors and defects, performance, usability, or capability deficiency, or unfavorable environmental factors such as network communications failures or operating system incompatibilities." 

Aside: With the increasing use of biotechnology and nanotechnology that interacts with our own biology, it will become increasing difficult to draw any clear distinctions between a designed technologically-augmented biological system and one that is strictly naturally evolved.

The phrase "developmental errors and defects" has a much catchier name: Bugs! That actually sounds a bit like the germ-theory of disease doesn't it? A lot of people refer to catching "the flu bug" or being "sick with some bug".

Here is a photo of the "first actual bug" found in 1946:

Trivia aside, our definition encompasses a lot of different types of "inputs", though not all, but it focuses in the beginning on one critical perception: 

an incorrectly functioning or incomplete component, feature, sub-system, or unit

This brings us to one more important definition before we move on.

Definition: Determinant 

any factor that brings about change in a health condition or in other defined characteristics

In epidemiology, a determinant can take on a broad range of concrete forms. In summary, the World Health Organization groups them into these categories: 

• the social and economic environment,
• the physical environment, and
• the person's individual characteristics and behaviors. 

Source: http://www.who.int/hia/evidence/doh/en/ 

The Determinants of Information System Health are Almost Always Human-Caused 

Information systems differ from biological systems because they are specifically designed by humans to serve human needs or goals. Because information systems are designed by us, we have better internal control over the resulting  behavior, and thus the healthy status, of information systems. Compare this to the medical or epidemiology professions where purely naturalistic, biological systems are constrained only by the laws of nature, many of which we only partially understand and have only partial external control.

Since software development is entirely human-made, and consists of a closed set of concepts entirely understandable and controllableshould we understand and follow a few simple guiding principles that we'll introduce in the next article. Because of this fact, software development can be done in a way that defect prevention is this built in from the beginning. But for now, let's introduce a few more epidemiology terms and see how they apply to software development.

Definition: Incidence 

Incidence refers to the occurrence of new cases of disease or injury in a population over a specified period of time 

Source: 

http://www.ihs.gov/medicalprograms/portlandinjury/pdfs/principlesofepidemiologyinpublichealthpractice.pdf

 Definition: Prevalence

Prevalence, sometimes referred to as prevalence rate, is the proportion of persons in a population who have a particular disease  or attribute at a specified point in time or over a specified period of time. Prevalence differs from incidence in that prevalence includes all cases, both new and preexisting, in the population at the specified time, whereas incidence is limited to new cases only.

 Source: http://www.ihs.gov/medicalprograms/portlandinjury/pdfs/principlesofepidemiologyinpublichealthpractice.pdf 

Applying Incidence and Prevalence to Information System Development and Defect Control and Prevention 

We saw above that defect prevention can be built into the software development process from the beginning. While this is true and will be explained in detail in another article, we need to consider the all too common scenario that we are all used to: buggy software.

Let us equate a software defect, bug or otherwise "incorrectly functioning or incomplete component, feature, sub-system, or unit", with"disease or injury" from the definition of incidence.

Now, suppose an organization hires a contracting company to build a large information system. The contractor says the system will be ready to deploy to a production environment for use by the end of one year's time from project inception.

Next, suppose this company sets out to analyze and define all the requirements to build that system before building even a single small portion of the system. Suppose this process takes six months before any new code is written at all. The company delivers large requirements and design documents to their customer at the end of this process.

At this point, there may already be a high prevalence of undiagnosed defects inside of the requirements and design documents for that system! Thus, any ensuing "disease" has not yet had a "date of first occurrence" because none of the system's code has been written, tested, or used -- not even in prototype or proof-of-concept form!

Here are a few more epidemiological terms that draw immediate analogies:

Definition: Incubation Period 

A period of subclinical or unapparent pathologic changes following exposure, ending with the onset of symptoms of infectious disease.

Definition: Latency Period 

A period of subclinical or unapparent pathologic changes following exposure, ending with the onset of symptoms of chronic disease.

Defects Latent in Large Documents Have a Long Incubation Period Followed by Sudden Onset 

Now we can understand that when the contractor spent six months building a large requirements and design document, but built no physical code for others to review and use they raised the risk of "infection" which will likely result in a sudden, or acute, onset of a variety of problems. Ultimately, this will be measured as both a  high incidence and a high prevalence during the time period the defects are discovered.

Latent Defects are Like Subclinical Infections Until Onset 

Wikipedia defines a subclinical infection as follows:

"A subclinical infection is the asymptomatic (without apparent sign) carrying of an (infection) by an individual of an agent (microbe, intestinal parasite, or virus) that usually is a pathogen causing illness, at least in some individuals. Many pathogens spread by being silently carried in this way by some of their host population. Such infections occur both in humans and nonhuman animals."

Now we know such infections occur in humans, nonhuman animals, and large requirements and design documents not yet tested by tangible development. Keep in mind that "tangible development" does not mean 100% complete and ready for release, but it does mean, at minimum, prototyped and delivered in a visible, clickable, malleable form -- not just words on paper or promises in contractual agreements.

Applying Quarantine and Isolation Tactics Not Just at Borders 

Let's now consider quarantine and isolation practices, considering the SARS outbreak mentioned above. When SARS happened, public health officials acted quickly and implemented quarantine procedures to try to control and prevent the spread of the pathogen into their own populations. Consider this summation of quarantine measures from Taiwan:

During the 2003 Severe Acute Respiratory Syndrome (SARS) outbreak, traditional intervention measures such as quarantine and border control were found to be useful in containing the outbreak. We used laboratory verified SARS case data and the detailed quarantine data in Taiwan, where over 150,000 people were quarantined during the 2003 outbreak, to formulate a mathematical model which incorporates Level A quarantine (of potentially exposed contacts of suspected SARS patients) and Level B quarantine (of travelers arriving at borders from SARS affected areas) implemented in Taiwan during the outbreak. We obtain the average case fatality ratio and the daily quarantine rate for the Taiwan outbreak. Model simulations is utilized to show that Level A quarantine prevented approximately 461 additional SARS cases and 62 additional deaths, while the effect of Level B quarantine was comparatively minor, yielding only around 5% reduction of cases and deaths. The combined impact of the two levels of quarantine had reduced the case number and deaths by almost a half. The results demonstrate how modeling can be useful in qualitative evaluation of the impact of traditional intervention measures for newly emerging infectious diseases outbreak when there is inadequate information on the characteristics and clinical features of the new disease-measures which could become particularly important with the looming threat of global flu pandemic possibly caused by a novel mutating flu strain, including that of avian variety.

Source: http://www.ncbi.nlm.nih.gov/pubmed/17055533

What this summary illustrates is that quarantine, when applied at a higher level in the chain of transmission led to a far better reduction in the incidence rate of infection. The other measure led to a more modest, 5% reduction of cases and deaths.

What would happen if we applied this kind of model to the development of information systems, and did it at many levels, in order to prevent large populations of infected, buggy, defect-ridden documents or code from becoming integrated with healthy, corrected, defect-free populations (of software objects)?

Defining the Quarantine Model of Integration

Let's define a simplified "Quarantine Model of Integration" that can apply to more than just humans with possible infections crossing borders, but can also apply to requirements documents, design documents, napkin sketches, whiteboard scrawling, information system releases or upgrades, specific system features, and certainly all the way down to discrete units of software code.

Population A: Some set of individual objects.

Population B: Another set of individual objects similar to Population A.

Population B-Harmful: Some potential subset of population B with harmful characteristics that would disrupt and weaken the integrity of desired characteristics if introduced into Population A.

Population B-Benign: Some potential subset of population B without harmful characters if integrated into Population A.

Mitigating Filter Procedures: A set of actions that can be taken upon Population B to identify Population B-Harmful and Population B-Benign, thus allowing Population B-Benign to be integrated into Population A without harming it (while also isolating and preventing Population B-Harmful from integrating)

Improving Outcomes by Applying the Quarantine Integration Model Throughout the Development of an Information System 

We will delve into the specifics of how to apply a model like this to control the development process in the next article. However, the type of control and prevention practices that are necessary when building an information system are different from what you might have seen in many large projects, such as the fictional one described above. Many projects undertaken by large corporations or governments attempt, with good intention, to prevent exposure to risks and defects by trying to define as many "requirements" and "design details" in large documents long before any of the software system is constructed. This is most often a mistake. It's a mistake, as we'll see, that goes back at least 42 years to 1970, but perhaps even further.

You probably remember that I earlier wrote:

Because information systems are designed by us, we have better internal control over the resulting behavior, and thus the healthy status, of information systems.

The key phrase there is "resulting behavior". What is unstated is that the process of creating that resulting behavior is itself can take a very meandering path that is very iterative (completed in multiple passes) and incremental (completed as a series of smaller divisions of a larger whole) 

It's often said that an empirical model of process control is needed to properly manage this kind of creative, evolutionary process. 

Definition: Empirical Process Control Model 

The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.

Notice that an empirical process control model is a lot like the scientific method. In the next article, we'll also discuss how scientific knowledge advances through iterative, incremental, and evolutionary spurts. For example: we all know that one woman's hypothesis and experiment would not overturn the germ-theory of disease if she claimed that illness was caused by another mechanism. 

Peer Review is the Hallmark of Sound Science (And Also of a Sound Information Systems Development Process)

In the case above, we know the scientist's ideas must face the rigor of the peer review system that is the hallmark of science. The peer review process is just one implementation of the "Quarantine Model of Integration" we just defined. And, peer review is, in fact, the self-correcting mechanism built into the heart of science which differentiates it from countless other "ways of knowing" that our human species has and continues to utilize.

That peer-review system is also, naturally, at the heart of what CDC does in its constant effort to do sound science. And, as we'll preview next time, several types of peer review, and even-wider-review, are at the heart of any successful process for developing a winning, useful, and cost-effective information system.