Divide by Nought

Too often developers and engineers miss the point of objects within object oriented programming (OOP). Many create ever-larger containers, objects sets with lots of implicit knowledge about each other, and seem to have disdain for passing variables.  Object oriented programs are still procedural even if they also have a nice way of packaging related data and operations.

Objects should behave like objects.  They are not massive amalgams of things that are sort-of related because that’s how they’re needed right now.  If objects aren’t treated as automatic components, the whole point of object orient programming is being missed.

When creating an object some simple considerations can increase the readability of the code as well as reducing the amount of knowledge needed to update it (which should avoid a whole lot of maintenance).  In almost every situation all of these things are easy to do.  In fact, if they’re not easy to do, that probably means there are extraneous complexities in the overall design.

Things to remember:

1. Objects represent a single instance of some logical grouping of data.
2. Objects can contain only 2 types of things: operations (methods) and properties (variables).
   • Properties represent something about the Object.
   • Operations do something based on the Object’s properties (internally provided) and/or passed Parameters (externally provided).
3. Operations are always initiated externally; method calls, event callbacks, etc.

This implies that:

1. Properties specific to the Object should be stored in the object.
2. Parameters specific to an Operation should not be stored in the Object.
3. Parameters specific to an Operation should be passed to subsequent Operations.
4. Parameters created in/during an Operation should be treated as though they are Parameters; i.e. they are not Properties and should not be stored in the Object.

You may have noticed that all of these statements say “should”.  While this is nice and soft language in almost every case you should replace “should” with “must”.  If you’re not, your code is probably lower quality than it could and probably should be.

A good rule of thumb is that if you can’t explain it easily, it’s probably overly complicated.  You should be able to explain how and why something works to anyone.  Not any engineer, but anyone (using laymen’s terms of course).  These are some other good rules-of-thumb:

1. Prefer generic types.
   Using generic types lowers the amount of dependencies and knowledge of a system need by the implementing engineer.
2. Avoid using generic types if it overcomplicates the code.
   While generic types are great, they aren’t always appropriate.  It’s a balancing act.
3. Prefer enumerations over generic types (int, bool, etc).
   When passing a political party “3″ doesn’t mean anything.  And there are always more options than on and off, running and idle, even male and female.
4. Prefer parameter only input into methods.
   Using parameters helps to keep methods constrained as automatic units that can easily be called by anyone, at any time and in any order.
5. Avoid using globals or class-globals as input into methods.
   Using class-globals reduces the reusability and concurrent usability of a method.

Finding dead code removed with pre-compiler directives:
^:Wh*\#~(else|endif|if DEBUG|region|endregion):i*

Finding any unused exception blocks:
catch:Wh*\(:Wh*:a*Exception:a*:Wh*:a*:Wh*\):Wh*\{:Wh*\}

Finding unused exception blocks with exception members:
catch:Wh*\(:Wh*:a*Exception:a*:Wh*:a+:Wh*\):Wh*\{:Wh*\}

Finding unused exception blocks with comments:
catch:Wh*\(:Wh*:a*Exception:a*:Wh*:a+:Wh*\):Wh*\{(:Wh*//.*)+\}

catch(:Wh*\(:Wh*:a*Exception:a*:Wh*:a*:Wh*\)):Wh*\{(:Wh*//.*)+\}

Finding console outpout:
Console.*Write.*(.*);

Finding trace outpout:
Trace.*Write.*(.*);

Creating a dedicated SCCB (Software Change Control Board) user and using it only during SCCB meetings can make history tracking easier to handle.  This is because it…

1. Clarifies the context of the change; i.e. during an SCCB meeting.
2. Keeps the user consistent regardless of whether the SCCB chairperson changes.
3. Avoids confusion for the current chairperson when trying to determine who made a change, when and why; i.e. whether the given SCCB chairperson made changes during the SCCB meeting or as part of his or her “offline” work.

Of course it doesn’t tell who the chairperson was at the time.  Often that doesn’t really matter since the point of the meeting is group consent for changes; so the individual matters less.  If it does matter a field can be added to each record as to who the SCCB chair was or it can be captured in meeting minutes.  And of course only a limited number of people would have access to the account.

OmniFocus and Things are both great GTD/PIM/Productivity applications.  I’m using them both just too see which one I end up using more and then I’ll stick with the winner.  I would simply choose one, but they both have their limitations.  Omnifocus is a little too structured while Things is a little too loose and, even worse, manual. Nothing is ever perfect, but a couple small changes to either and my life would be so much easier.

OmniFocus being too structured appears to be the result of strict adherence to the GTD scheme.  As a seeming result it doesn’t offer things like deep projects (projects with sub projects that have their own sub projects…ad nauseam…).  It does have folders (aka groups), but that’s a completely different concept and requires manual organization.  That’s a big deal, manual operations take half of the value out of a task management applications.  It does, however, allow for hierarchal contexts.  This is a good thing overall, but even there it would be nice to have a little more depth.  A cross between relational organization and hierarchal organization would be super powerful.  Then again, nothing that I’m aware of offers that right now, so maybe I shouldn’t be surprised.

Things has projects, areas, hierarchal tags, and people.  All good things and allowing finer control over tasks than OmniFocus.  But it doesn’t allow for anything but tags to be entered (associated) during task entry.  Odd.  What this means is that project and area associations must be manually created after the task is created via a wizard like menu system.  This is the definition of kludgy and is Things biggest limitation.  Why?  Because entering new tasks needs to be very fast and shouldn’t required that I do anything else to organize them beyond that initial entry.  Unless of course I want to change something because I didn’t do something.

Finally, they’re both only available for the Mac.  I think Macs are great (more specifically OS X).  But I do have Windows machines both at work and home.  Why, oh why, must I use a Mac to have good task management software?  At a minimum a nice Ajax enabled web client is in order.

…at least they both have iPhone apps.

Despite my criticisms I do like both of these programs and think they’re better than anything available for Windows (Outlook doesn’t even come close).