Skip to main content

live big in little places

Being able to dwell on a small kernel of in idea in order to flesh it out and determine the parameters of the idea is important as it allows us to extract new realizations from an exploration that few seldom do. It is by looking at the areas that might be overlooked that form the intersections of various concepts or needs that hold the potential for new revolutionary solutions. In my work as a software engineer and architect of I encountered many areas in creating my service options that came to existence not from an active and conscious intention on my part to innovate them but rather by natural confluence of functionality provided by the services tying together with the potential for greater efficiency by slight modification of these existing functions or by radical modification through the use of a novel idea. One key insight has enabled the creation of 2 functions that would not exist had the infrastructure for their existence not been previously available in another function. The details of these functions must await the launch of the site for me to reveal the details but suffice it to say that it was by living big in the little place of a single idea that I was able to generate 2 new innovations that would not have existed had I failed to entertain the functionality that gave those innovations the potential for realization. A concrete example of this can be found in the piston of the common internal combustion engine, on its own the piston is a very unoriginal device, a weighted cylindrical object combined at a flexible joint to a fixed shaft. However, within the context of an engine core the piston becomes a lynchpin of the process of internal combustion...without it, it simply would not the question is begged which came first the piston or the engine core. The answer through history is clear, the piston (reciprocating mechanism for transfer of force, the first version of which can be said to be a pile driver which some claims put as being invented 500 years ago. If we want to really be strict a battering ram is a form of human powered piston and those are thousands of years old , as old as siege war fare) predated the core and doubtless the idea for internal combustion could only be given life once the action of a piston could be observed and the details of its behavior lived big in before the grander idea of a combustion block and reciprocally mounted pistons on a crank shaft could be combined to create the internal combustion engine marvel of modern land and sea based transportation. The interesting truth about this act is that the potential for revolution seems fused to what appears to be common and mundane and it is when we fail to dwell on new ways of seeing old things that we miss the opportunity to engineer by living big in little places and potentially sparking innovation.


Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…