I have always admired the cleverness of the name Hollywood Principle. I love its name! The essence of this principle is “don’t call us, we’ll call you”. As you know, this is a response you might hear after auditioning for a role in a Hollywood movie. And this is the same concept for the software Hollywood Principle too. The intent is to take care to structure and implement your dependencies wisely.

At its most basic level, the principle is about reducing the coupling in a software system. It gets back to the well known phrase in software development: loose coupling and high cohesion. You can keep classes loosely coupled by ensuring that you don’t have unnecessary references and you are referencing classes and other subsystems properly. Although the Hollywood Principle does not dictate anything about cohesion, it is an important aspect too. Cohesion is about keeping your classes true to their intent and not allowing their behavior to expand beyond its core purpose. Like high coupling, low cohesion doesn’t tend to cause systems to be unstable or not work properly, but will likely lead to difficulty in maintaining the software.

One of the most popular ways to implement, or obey, the Hollywood principle is to use events or callbacks. A well known pattern that follows the Hollywood principle is the observer pattern. This pattern allows one to observe the state of an object in a well defined and non obtrusive manner. It is typically implemented by injecting a callback object (observer) into the class to be observed (subject). The subject simply raises an event in all observers when its state changes. How the observer reacts to the event is outside the scope or care of the subject.

Dependency Injection (DI), which is a form of Inversion of Control (IoC) is another example of the use of the Hollywood principle. Take for example a shopping cart class that requires a reference to a currency conversion service. Traditionally, the shopping cart class would be designed with a reference to the currency convesion service or use a factory to get a reference to the appropriate service implementation. By contrast, using DI, an external mechamism (e.g. Spring or Spring.net) automatically provides a reference to the required currency conversion service at the time the shopping cart class is instantiated.

Cloud computing involves both the architecture of an application (i.e. the way it is designed and the intent behind its design) and the platform on which the application is deployed. Cloud computing is a way to build, deploy and manage applications using Internet-based server infrastructure. It dovetails well with Service oriented Architecture (SoA) in that applications in a cloud are typically developed in a distributed manner with all the application pieces communicating over the Internet.

Cloud offerings differ from different vendors, but, for example, Amazon offers:

• Computing capacity - Elastic Compute Cloud or EC2 is a Linux hosting capability
• Structured data storage - SimpleDB is a web service-based capability for accessing structured data
• Large data storage - Simple Storage Service or S3 is a web service-based capability for storing and retrieving chunks of data
• Queuing service - Simple Queue Service or SQS is a hosted queue for storing messages to support asynchronous message processing

The cloud is promising to companies of all sizes, but is most powerful for small to mid-sized companies that do not have the money, staff or IT infrastructure to support an on-site enterprise data center. Getting a server to be visible on the Internet is easy. But building the technology infrastructure and staff to support a truly 24×7 data center environment with proper redundancy (both from a hardware, software and networking perspective), backup mechanism and physical & software security is not easy. Especially if this environment has to handle heavy peak loads.

The Benefits
Cloud computing offers many benefits:

• Ability to handle increased capacity and expand capacity and capability without any large upfront investment
• Ability to pay for infrastructure much like you pay for your utilities at home. You pay for what you use and you can configure your application to handle peak load without paying for a massive hardware infrastructure.
• Possibility of reducing IT operations staff

The cloud lowers the bar (from a cost and complexity perspective) to entry for mission-critical, enterprise infrastructure and provides easy access to additional capacity as needed. However, not every vendor’s solution is created equal. To get the most out of certain cloud offerings, it may require modifications or rewrites to existing applications.

The Risks
Probably the largest concern surrounding the adoption of cloud computing is lack of trust (by some) in the security surrounding their data on the cloud. The fear of their enterprise data being compromised is a large concern and a barrier to entry for some companies.

However, despite what some folks may believe, most of the large cloud vendors have much more security talent than the typical corporation. And it is absolutely critical for the survival of any cloud vendor to keep their environment as safe as possible.

The second risk is the fear of an outages at the cloud provider. Could this happen? It did happen earlier in 2008 when Amazon had a service outage and applications were not available. Due to these risks, some companies are planning to wait and see how reliable and safe these services are before jumping on board.

The Players
There are a few of big players (Microsoft recently announced their entrance into this market in 2009) and many small startups in the cloud computing space. Most organizations are selecting to work with the big players due to the potential risk involved in outsourcing their application and data to a small unknown vendor. But the smaller companies seem to be pushing the innovation and providing unique offerings.

The Single Responsibility Principle (SRP) is defined by wikipedia as every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.

Although the origins of this concept are someone disputed, most believe it was originally developed by Tom DeMarco in his book Structured Analysis and Systems Specification but was later popularized by Robert Martin in his book Agile Software Development: Principles, Patterns, and Practices. The principle simply states that a given class should have one and only one responsibility. And that the behavior of the class should be narrowly aligned with that single responsibility.

The essence of this concept has to do with the reason to change a class. If a class has more than one responsibility, it may have different reasons to change, each of which are independent of one another. Take for example a class that both imports data from a file and saves the data to a persistent storage mechanism. The single class needs to be modified for any change to the incoming file format as well as any change to the underlying data storage mechanism structure. These changes should not be connected. By modifying the class to adjust the file format, you risk introducing a bug to the file persistence code. In a hurry, without the safety net of automated unit tests (gasp!), developers tend to only test code that is related to a given change.

If your classes follow SRP, you probably can get away with only testing related code (although thorough automated unit tests are always the best course of action). If you violate SRP, you need to be extra cautious when considering the ripple effect from changes to your code. I believe SRP is so fundamental that it can make the difference between a system that is easy to maintain and one that is your worst nightmare to maintain.

Sounds simple right? Well it is, but it is common while designing and refactoring to find SRP violations. But let’s face it. Most software stinks and I have seen countless convoluted designs. Many of these designs (not designed by me of course) had a systemic SRP issue. SRP in one class in your system is not big deal, but SRP in most of your classes is sure recipe for disaster and a system that is very difficult to maintain.

When I have difficulty getting a design to feel right, I try to ask myself whether the classes in that portion of the system are following SRP. Many times, I find the core design issue stems from one or more classes with more than one responsibility.

There are many ways to deal with SRP violations. The most common are:

1. Delegation - To put behavior in another class and leverage a pattern such as Strategy
2. Aggregation - To push the behavior out to another class and reference this new class

Regards,
Matt

There are several Getting Things Done (GTD) two minute timers available. Most are commercial, but there are a few other free products. I’d like to introduce the first open source GTD two minute timer, YAGTDT. I’m hoping the GTD community will help me make Yet Another GTD Timer (YAGTDT) the premier two minute timer available. YAGTDT is completely free and does not contain any adware/spyware. You can download the program binaries here.

Below is a screen shot of the simple and intuitive user interface:

My thoughts behind the timer and its use:

I try to implement David Allen’s Getting Things Done (GTD) as best I can. One morning I started to wonder how well I implement the GTD principles. I wondered how well I deal with everything that comes at me during the day (things come at me via email, verbally, physically in my inbox, via telephone, …) and how well I evaluate and determine if I need to do anything and if so whether it is truly actionable.

According to GTD, if I encounter something new (or have the same thought more than once) that is actionable, I must decide if I want to:

a) do it right away
b) delegate it
c) defer it

GTD further defines: If I want to do it and it takes less than two minutes, I should just do it right away. If I want to do it and it will take more than two minutes I should put the item in my GTD system and evaluate its importance and priority along with the other items I need to do. If I want to defer it, I need to put something in my system or calendar to remind me of the next action to take against this deferred item at a later date.

As I pondered about my use of GTD, I began to wonder what could really get done in two minutes? Not what could get done in approximately two minutes, but actually two minutes. And I started to think how little time two minute really is. And (yes, this is pretty sad) I wondered, for example, if setting up a meeting that requires finding people and a conference room in a corporate directory takes more than two minutes.

Well, after I experimented I found that 120 seconds is not always enough time to schedule most meetings. And, surprisingly, most emails that need to have some formality or that are more than just two lines cannot really be written, reviewed and sent in two minutes.

So this was an interesting realization and it sparked my interest in a task timer. I searched the web and found that a few timers existed, but nothing that was free and had the ability to customize the task timeout. The YAGTDT is fun to use and makes my day more interesting by challenging me to finish tasks in under 2 minutes. You simply set the timeout for a given task (2 minutes by default for GTD) and begin your task. When the task timeout expires, depending on your configuration, you will hear or chime or see a dialog stating the timeout. Because I time many tasks throughout the day, it keeps me focused (and in some sick way challenged because I’m constantly battling against time).

Personally, I would not recommend that anyone pay money for a task timer for their computer because YAGTDT is freely available to download and use (see binaries link below).

YAGTDT is very intuitive and straightforward. It defaults to a 2 minute timer. However, as Dave Allen once said in a seminar, two minutes is the GTD suggestion, but you may choose to use a 1 minutes rule or 3 minute rule. If I could do anything in 3 minutes, I’d prefer to do it right away! I don’t think 2 minutes is magic.

As a result, YAGTDT allows you to configure the timeout for a task. And, it has a few preferences that allow you to customize whether a message box pops up and whether a sound is played when the task timer expires. All of these options are available from the options link (note that this link is unavailable while the timer is counting down…you must stop the timer to change the options). Your preferences are saved and will be your new defaults every time you run YAGTDT.

From a technical development perspective YAGTDT is straightforward and therefore not too interesting. It is developed in Visual Studio 2005 using the C# programming language. It is a WinForms (Win32 Windows) application and it uses the .NET 2.0 framework. Eventually I’d like to move the project to Silverlight or WPF. I will be posting the source code for YAGTDT shortly.

System requirements: .NET 2.0 framework (download from Microsoft)

There is no installation, simple download the binaries and copy them to a location on your computer. You need to make sure you copy all 3 files (.exe is the program, .ini is the configuration file with your preferences and .wav is a sound file). If you experience any issues, you probably do not have the Microsoft .NET runtime installed. Please download it from the link above and try again to run the program, YAGTDT.EXE.

And if you encounter any problem that persists, please email me. Please leave me some feedback on the tool.

Regards,
Matt

I have to admit that I resisted using the subproject feature in the NetCentrics Getting Things Done Outlook Add-In for some time. The concept of subprojects seemed overly complicated and I didn’t see the justification to make the system any more complicated. In the GTD books I’ve read and the Dave Allen seminar I attended never mentioned subprojects…

However, just recently I encountered a multi-step project that I needed to accomplish for a non profit organization. I already had a top-level project representing my ongoing work with this organization, but this new multi-step project was quite involved and needed to be executed flawlessly. So I realized that it was time to check out subprojects and get an understanding for how they work.

I started by googling, searching the help file and looking at the NetCentrics support site, but could not find much information beyond how to create a subproject, so I resorted to figuring it out by creating one.

I created a subproject by clicking add on the subprojects tab of the project dialog. The following screenshot shows the resulting subproject on the subproject tab (click to enlarge):

After creating the subproject I was surprised that I could not interact with it. I assumed I’d be able to double click its name in the subproject list and it would open into another project window and that it would behave like any other project. I was wrong. The NetCentrics subproject is really just a description of the subset of work. It is not an entity all its own like a typical top-level NetCentrics project.

The way you use the sub project is by associating tasks to the subproject after selecting its parent (top-level) project. I had to enable the “GettingThingsDone 2″ toolbar from the view menu (note that you need to be in the Task window to see this toolbar option) to see the subproject toolbar. Below are the two GTD toolbars:

GettingThingsDone Toolbar (click to enlarge):

GettingThingsDone Toolbar 2:

You can also assign tasks to a subproject when creating a task from an email:

With a subproject, I had to tweak my weekly review slightly. Instead of viewing/reviewing my projects using the “Active Tasks By Project (GTD)” view I use the “Active Tasks By SubProject (GTD)” view. This view still displays the tasks by project, but also pulls in any sub projects. Below is a snippet of the view of tasks by subproject (click to enlarge):

In summary, I plan to create more subprojects for GTD projects that are ongoing concerns. For example, my first subproject had to do with a specific project within a longer-term project (my ongoing involvement with a non-profit organization). I can see other uses for subprojects within other ongoing projects in my personal life and in my career.

The Getting Things Done (GTD) weekly review is a key piece to Dave Allen’s Getting Things Done process. If you are not familiar with GTD, I’d highly recommend you visit Dave Allen’s company website. The weekly review is a weekly process to validate the information (things you need to do) in your GTD system is complete and accurate.

If you follow GTD you will learn quickly that a significant number of questions for GTD newbies revolve around the weekly review. And, in order for the GTD system to work and for the GTD practitioners to achieve a “mind like water” state, it is critical to trust that the GTD system contains everything that you need to do.

In order for the system to be complete, it must be regularly reviewed. Once you have a GTD system that you trust, and you are reviewing it regularly, it means you will automatically always know when you are doing the most important thing that you should be doing at that point in time (based on your physical surroundings). As a result, the weekly review is a critical activity.

I’ve been a GTD practitioner for about 2 years. Within the 2 years, I’ve had spans of time where I’ve been good about doing my weekly review…and spans of time where I’ve been pretty pathetic with my reviews. And, as I can attest, without regular weekly reviews, the system does not provide nearly as much value.

A friend told me about the Netcentric Outlook GTD Add-in about 1.5 year ago. At that early time in my familiarity with GTD, I tried the add-in but didn’t understand the value it could provide. At this point I was focused on the basic fundamentals of GTD and didn’t think I needed any fancy tool (and the $69 price tag turned me away too).

Late last year I thought I’d try the Netcentric Outlook GTD Add-in again (btw, I’m using Outlook 2003 on Windows XP SP2) to see if it would efficiently associate projects and next actions. In this second evaluation (with my head at another place and my GTD system pushing its limits in Outlook) I was very impressed by two features:

1. Ability to easily and painlessly link Next Actions to a project (key for weekly review)
2. Ability to create actions when processing emails in my in-box

The remainder of this blog will be focused on item #1 above and how it relates to the way I go about performing my weekly review. The GTD weekly review will be a bit personalized for different practitioners, but must contain the following:

• A review of all projects and next actions (not necessarily all someday/maybe items)
• A review of the prior week’s and the upcoming short and long-term calendar

The review assumes your physical and electronic in-boxes are empty and that all loose papers, notes, etc. have been processed. Finally, the weekly review may include a brain dump where you get everything out of your head (using trigger lists) and make sure there aren’t items missing from your system.

Reviewing the calendar is pretty straight forward, and if you are like me, you will typically find something that was planned on your calendar from the prior week that did not get accomplished for some reason. Or I’ll find something on my calendar that makes me realize I need to do something else…or there is a follow-on task to perform for the work I performed the previous week. And looking forward at the detail of my upcoming two weeks and a quicker scan of my calendar out about 6 months is pretty easy and quick to accomplish. If while examining my calendar I find something that requires an action or planning, I create the appropriate project and/or next action.

It is important to not do work while executing the review. This may sound ridiculous, but the temptation to just do some simple tasks (e.g. send an email) while performing the review is quite strong.

But reviewing projects and next actions is not so trivial. If you don’t have a system that ties your next actions to projects (and I didn’t for a long time) it is tedious and time consuming to know whether all next actions for a given project are in my system. My system currently contains 98 projects and 442 next actions (this does not include my 126 someday/maybe items). Of the 442 next actions, the bulk are associated with a project.

So the way I do my weekly review of projects and next actions is to first review all projects and their associated next actions and then to review next actions that are not associated with a project.

I start my review by choosing the Outlook task “Ordered Tasks by Project (GTD)” view (as displayed in the following diagram) to simplify the process of walking through all my projects and reviewing its associated next actions.

I review every project title, one-at-a-time, in the “Ordered Tasks By Projects (GTD)” view to see if any are not bold. Note that this view is created by the installation of the Netcentric Outlook GTD add-in and is not part of the standard Outlook installation. A bold project is good because it means that the GTD add-in recognizes the Outlook task as a GTD project.

Tasks that are not bold are bad because it means that the task is not recognized by the GTD add-in as GTD project. Any non-bold projects need to be promoted to an actual project in the add-in by double clicking the non-bold project (Outlook task) and once it is opened, selecting “Add New Project” from the GTD add-in as shown in the following screen shot. (Note: The reason I sometimes end up with Outlook tasks in the Projects category that are not recognized by the GTD add-in as projects is because I also manage my tasks via NextAction! on my BlackBerry 8800.)

When you open projects that are bold, the built-in Outlook task dialog is opened. From this dialog, click the open project button (highlighted in red) in the following screen shot.

The open project button launches a custom dialog (see below) that contains information about the project (in my example the project name is “Mitigate Radon”) and contains a list of associated tasks for the given project (my tasks are “Discuss timing of work” and “Seal basement floor/wall joint”). This is the dialog from which you can think about the given project and add (by clicking Add Task Action), edit (double click the row for the given next action task) or delete (open the next action task and delete it as you would delete any Outlook task) tasks as you see fit.

After I have reviewed all projects I then review next actions that are not associated with a project by selecting the task “Active Tasks By Project (GTD)” view. This view groups all next actions by project and creates two groupings of “none” projects. All “none” projects are next actions that do not have an associated GTD add-in project. Some of these next actions are someday/maybe items (which I only review about once per month), but the remaining next actions need to be reviewed weekly.

I review each remaining next action, one-at-a-time, in the “Active Tasks By Project (GTD)” view. I double click each next action to open the default Outlook task dialog. Sometimes the next action’s title, notes, priority, due date or category needs to be adjusted. Other times I realize what once was though to be a single next action really needs an associated project. And there are times where I need to delete a next action because it is complete. (Note: I don’t use the completed concept in Outlook tasks. Although it would be gratifying to see all the completed tasks, I feel completed tasks just create more distractions. So I delete tasks when they are complete.)

The weekly review can be a daunting task. I hope this information helps someone make their review a little easier. It still takes time and dedication, but once you get into a rhythm with the weekly review you can execute it faster because you know the content in your GTD system better. Once you regularly execute a weekly review, you are on your way to “mind like water”!

Software design patterns have been around for many years. And as most who follow design patterns know, they gained tremendous traction after Gamma, Helm, Johnson, Vlissides (these gentlemen are fondly known as the Gang of Four (GoF)) released their book Object-Oriented Design Patterns book.

What many don’t know is that design patterns have their roots in architectural patterns. Not architecture as in computer software or computer network architecture design, but architecture as in buildings and towns. Christopher Alexander coined the term “pattern” in the late 1970s in his writings. If you want to get into the heart of the origins of patterns, you can check out his original book The Timeless Way of Building. And his second edition (with additional authors) A Pattern Language: towns, buildings, construction. Although Alexander’s books are interesting from a historical perspective, they will provide little value in your pursuit of software design patterns while taking a large divot from your wallet.

So what are software design patterns? They are solutions to common problems that developers and architects face. Many software design patterns address common situations that developers need to implement in every application they build (e.g. object initialization). Take just about any programming problem and there are only a few good implementation approaches, but many bad approaches. Software design patterns capture the experience of experts in a form that others can reuse.

In the early 1990s, the best source for information on software design patterns was definitely the GoF Object-Oriented Design Patterns book. At my previous employer, we issued the GoF book to all new developers because the book defined a set of well thought through patterns but more importantly defined a new lexicon. The introduction and popularization of the software design pattern lexicon provided a common language for developers to express design options in a very concise manner.

The GoF book was revolutionary because it defined many core pattern names and provided details regarding the intent of the patterns and also included some code snippets to clarify the suggested implementation approach. Unfortunately, the code samples for the patterns are written in C++. Today, with a large portion of business applications being developed in Java, PHP and .NET, you may find the GoF book harder to consume than some more recent pattern books such as Head First Design Patterns for Java and Design Patterns for C# for .NET.

In addition, Martin Fowler’s book Patterns of Enterprise Application Architecture has been very influential. In his book, Fowler identifies new enterprise patterns and provides clarification and enrichment to other lesser-known patterns.

GoF defined four essential elements that are required for any software design pattern:

1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two
2. The problem describes the context and when to apply the pattern
3. The solution describes the elements that make up the design, their relationships, responsibilities and collaborations. The pattern does not describe a concrete solution.
4. The consequences are the result and trade-offs of applying the pattern

GoF felt that a problem to be solved by a software design pattern must be seen repeatedly in practice to prove the pattern is applicable beyond the system in which it is first identified.

Patterns are typically divided into 3 categories:

• Creational - like the name suggests, these patterns focus on factories and other techniques that help create (”new”) objects. Although the category sounds fairly straightforward, creational patterns are used in conjunction with dependency injection (sometimes referred to as inversion of control (IoC)) to help avoid unnecessary dependencies in your code which can help, for example, to make unit testing easier (i.e. ability to easily change factory implementation to facilitate stubs or mock objects for testing). The Singleton is an example of popular creational pattern.
• Structural - as their name suggests, these patterns provide structure for one or more classes to achieve a certain objective. It is concerned with how classes are composed to form larger structures or subsystems.
• Behavior - are concerned with the inner workings of classes such as algorithms and the responsibility between classes. Template Method is an example of a popular and powerful behavioral pattern.

Most patterns cannot be read once and completely understood. If you want to be able to use a pattern, you must approach pattern literature with the attitude that you will study the patterns rather than just read them. Some patterns have slight variations between different authors and sometimes slight differences in their sample implementation approaches. Sometimes these differences are a result of different technology platforms and languages. For example, patterns in .NET tend to leverage .NET platform-specific capabilities such as generics and delegates.

However, when learning a new pattern, the single more important take-away is to understand its intent. Otherwise, some patterns start to look alike and many patterns are implemented in a similar fashion by introducing an interface, abstract base class, level of indirection, aggregate object, etc. For example, in .NET the Role Object Pattern (ROP) and State Pattern are similar in their implementation. Both patterns start with a primary class that needs to either have a role or have a state. At first glance, especially by scanning their UML, they appear to be almost the same.

However, after studying their UML more carefully, their implementations are very different - primarily because ROP aggregates one or more roles that are reference by their Role interface and the State Pattern is associated with one state, which is referenced through an abstract base class. But the biggest difference is the intent behind the two patterns - ROP gladly exposes the role(s) from the class and embraces the concept of a role. To the contrary, the State Pattern hides the concept of a state class and just provides a simplified state value to its consumer.

Although patterns are meant to be implementation independent, most texts provide sample implementations. If you do most of your work in one programming language, you will greatly benefit by finding a resource on patterns that has accompanying examples written with your primary language. Even though you might be able to translate say from Java to C# you may miss some platform-specific features in C# during your implementation. For example, some .NET patterns are written to leverage .NET delegate (which are essentially function pointers to simplify threading) and the Observer pattern will leverage the .NET events/event handlers.

In future blogs I will address many GoF software design patterns and provide working samples in C#.