Tag: concept

Focus on Thought

December 1, 2011 by Sherwin James | 0 comments

I have always had a strong interest in the mechanics and process of thought, particularly on how it relates to communities, groups or masses. We all have thoughts – most we keep to ourselves; some we share; a few we scream to the world. We often think that our thoughts are completely unique. On the edges they may be, but at their core they are very much like the thoughts of those near or far from us.

About a year ago I decided to start a little online experiment that is centered on thought (particularly shared thought). I created a web site titled Think.as.MANY. The site currently has two components (or apps), Think.like.ME? and Think.of.a.STORY. Here’s a screenshot of the main page:

Think.like.ME? enables a visitor to enter a thought (a statement, question, anything – excluding profanity). In return the visitor is presented with other thoughts that have been entered prior that are similar. This is all done anonymously. The visitor can also browse through existing thoughts, and traverse through similar thoughts (thought tree). The idea is to see how thoughts are alike (or not). As more thoughts are added, the experiment becomes more realistic. Also, I have built a simple Android app for this. You can find it in the Android Market with the name think.like.ME?.

Think.of.a.STORY is about building a continuous story. Each visitor contributes part of the story on each visit. It’s a concept that has been done often in the past, but I thought it might be fun and interesting to visual the result across the vast Internet.

With both of these apps, the more participation the better. I encourage you to visit, participate and share with others.

Is it important to know Why we are implementing something?

June 1, 2010 by Sherwin James | 2 Comments

When given a task to implement an application, or other software technology, most developers / development teams first ask the question “What are the requirements of the application that is to be developed?” (some even jump straight to “How to develop?” – but that’s a topic for a different discussion).  I believe that the first question, or at least the question right after “What“, should be “Why is this needed / desired?”.

Yes, understanding who, what, when, where and how are important (or even critical) to the successful implementation of a software product (or any other activity, for that matter).  But while the answers to these questions will most likely provide the quantitative controls for an implementation project (e.g. specific requirements, users and user types, delivery deadlines, internal vs. external usage, etc.) – the question of “why” seeks to answer the more qualitative ones.  The answers to why (when examined by someone of some level of experience) can provide valuable info on purpose, priority, constraints, dependencies, biases and other such matters.  It can lead to such decisions as whether the task should be undertaken in the first place; whether it would be better to buy a product, instead of build one; whether the development team should spend more time on making the UI top-notch vs. building a completely open and extensible back-end.  These insights, and much more, can result from asking “Why?“.

So when next faced with an implementation task, don’t be afraid to ask the sometimes difficult question of “Why?“.  It may save you a tremendous amount of effort in the pursuit of what and how, as well as the other questions of choice.

The ABCs and XYZs of IT

February 7, 2010 by Sherwin James | 0 comments

There exists an alphabet soup of acronyms and abbreviations within Information Technology. Included here are some of those that are important for any IT technologist to at least be aware of – but better yet to understand with some depth.

  • AJAX – Asynchronous JavaScript and XML
  • ALM – Application Lifecycle Management
  • API - Application Program Interface
  • BI – Business Intelligence
  • CSS – Cascading Style Sheet
  • ERD – Entity-Relationship Diagram
  • ETL – Extract, Transform and Load
  • HTML – Hyper Text Markup Language
  • HTTP – Hypertext Transfer Protocol
  • LAMP – Linux, Apache, MySQL, PHP/Perl/Python software bundle
  • MDM – Master Data Management
  • MVC - Model/View/Controller
  • ODS – Operational Data Store
  • OOD – Object Oriented Design
  • POJO – Plain Old Java Object
  • REST – Representational State Transfer
  • RIA – Rich Internet Application
  • RPC – Remote Procedure Call
  • RSS – Really Simple Syndication
  • SaaS – Software as a Service
  • SDLC – Software Development Life Cycle
  • SEO – Search Engine Optimization
  • SLA – Service Level Agreement
  • SLA – Service Level Agreement
  • SOA – Service Oriented Architecture
  • SOAP – Simple Object Access Protocol
  • SQL – Structured Query Language
  • SSO – Single Sign On
  • TDD – Test Driven Development
  • UML – Unified Modeling Language
  • URI – Uniform Resource Identifier
  • WSDL – Web Services Description Language
  • XML – Extensible Markup Language

If you are not familiar with these, I strongly suggest you look them up. Google, Bing or Yahoo will do as a start.

Consistency Beats Correctness, Any Day

February 5, 2010 by Sherwin James | 0 comments

Let me start by stating the obvious: if I can have both consistency AND correctness in my technology dealings – I’ll take it. Unfortunately, that is seldom the case. Also, some definitions are needed to properly set the context for this discussion. For consistency, the meaning is fairly straightforward:

From: answers.com
1. Agreement or logical coherence among things or parts: a rambling argument that lacked any consistency.
2. Correspondence among related aspects; compatibility: questioned the consistency of the administration’s actions with its stated policy.
3. Reliability or uniformity of successive results or events: pitched with remarkable consistency throughout the season.

Correctness, however, is not so easy to pin down. Let’s take a look at a definition of correct (as an adjective):

From: answers.com
1. Free from error or fault; true or accurate.
2. Conforming to standards; proper: correct behavior.

The problem is, correctness – like truth – is relative and not absolute. What is correct for one, may be completely incorrect for another. So the best we can hope for is that something is appropriate for a person or group at a particular time or period. Standards help a bit to settle down this variance, but they have a long, long way to go.

So, with that context established, if I had to choose between consistency and correctness, I would hands-down choose consistency. A big part of being successful on any technology project is being able to predict the outcome with some measure of accuracy – whether its knowing the effort for each code component, system upgrade, hardware device, process change, or any other work item. That predictability is directly related to the consistency of the work items that must undergo change. Whilst the correctness of the existing targets of change has some impact on the effort for change, it doesn’t come close to the impact of having to apply multiple paths of change due to inconsistent target implementations.

Another aspect to consider is the consistency of the solution, as compared to the correctness of individual elements of the solution. An extensive amount of effort may be exerted in order to find and implement the correct individual solutions for each target of change, which can be of little benefit – or even be a detriment – to the successful and timely completion of a technology project. Often it is best to have an overall solution that is consistent across all or most targets, but may not be necessary totally correct for all targets of change.

Where Concepts Meet Reality

December 26, 2009 by Sherwin James | 1 Comment

As technologists , whether you are an architect, designer or developer, we often spend much time in that place where the concepts, that we believe to be important, meet the reality of the project or software development task that we need to complete.  That place can be one of enthusiasm and gratification, but it can also be filled with stress, indecisiveness and delays.

In my experiences I have found that having a set of key principles and guidelines with me as I travel through that place can be extremely helpful.  Here are a few of those:

  • Software development is not religion – One should take pride in their software development efforts, but avoid the temptation to follow the “rules” blindly.  The most important part of a technologist’s toolkit is their ability to think within the context of their environment.  Use the “rules” as landmarks and suggested paths as you navigate through that place where concepts meet reality.
  • State vs. Behavior – Understanding the difference between these two fundamental object oriented design concepts is important.  In addition, knowing how to separate the two (if needed) is crucial to solving a range of technical challenges.  In a true OOD implementation, an object encapsulates both state (properties) and behavior (methods).  In a services based implementation, state is held by the entity objects while the services handle the behavior.  I have found that it is often more practical to have a mix of the two within a software implementation, with groups (or categories) of objects conforming to the different approaches.
  • Build in and “out” – Try as we might to handle ALL  scenarios or events that could occur with the use of software,  we will inevitable fail.  Software design is best served, from a practical sense, when it attempts to be structured around those scenarios and events that are well understood and predicable.  However,  to handle those unexpected or rarely occurring events, the design should have an “out” or a “catch all” that can deal with those events in a generic manner.
  • Separate but together – When it comes to expandability and maintainability, having separate and distinct architectural layers in your software design can really help.  Traversal of layers in a contiguous order is also important, but sometimes we must forge non-standard paths to deal with particularly thorny issues (such as performance and compatibility).   But before we veer away from the true path, we must be aware of the consequences and be prepared to deal with them.
  • Test, test and test – Test early and often, late and big, or somewhere in between – your choice, but understand the costs, risks and benefits of your approach before a single line of code is written.