Monthly Archives: March 2015

Disassembling Software Architecture

Facebooktwittergoogle_plusby feather
modelt

Disassembled Model T - Henry Ford Museum

I've been time traveling after seeing a great O'Reilly Video by Mark Richards on Software Architecture Patterns http://goo.gl/vAQloM. He includes some well thought out metrics as well.

Mark describes 4 of the 5 architectures in his book(s):
1) Layered
2) Event Driven (brokered and not-brokered)
3) MicroKernel
4) MicroServices
5) Space Based

I remember the early days of IC design (70's-80's) when product ideas became components in future products (the engine of exponential growth). The 1T DRAM, 6T SRAM, PLA's, ALU's started out as chips on boards but eventually were microcoded together to create a microprocessor, then SOC etc.

In the mid 90's I saw Mr. Silicon Graphics and Netscape Jim Clark (I consulted with Jim in 1983 when his "Geometry Engine" ran slower than simulation) at a Stanford Hot Chips conference. He forecast...

1) "We used to build small/consumer products by cost-reducing components for big systems"

2) "In the future we will build big systems from cheap components developed for small/consumer systems"

He spotted the pattern.

After the video I compared Mark's 5 patterns to  "Software Architecture in Practice", Bass et al,  a Stanford U. early 00's Software Architecture class textbook.   Chapter 18 of 19 is "Building Systems from Off-the-Shelf Components". I'm struck by how software architecture has moved from case studies to building with off-the-shelf components Just like early IC's.

Fast forward to the mid 00's when I ran a SaaS company warehousing chip measurement data. The product started with a 3-layer architecture (browser + "big ball of engine" + OracleSQL). We bogged down trying to add new features. How do we dis-assemble and re-factor the engine while the car is in the race?  A recent piece by Mat Stine at http://pivotal.io/ pointed to two recipes from SoundCloud http://goo.gl/nluAmU and Karma http://goo.gl/HpUOSp . Nice to see my problem dis-assembled 10 years later.

TAKEAWAY: BUILD SIMPLE SYSTEMS FROM SIMPLE STANDARDIZED BUILDING BLOCKS. Unless you're on the bleeding edge of speed, the benefits over a product's lifecycle outweigh any monolithictarball  approaches appear to bring. For you scrummy, lean and agile folks, kludge a prototype but don't evolve a prototype into a platform.

George Whitesides does a TED talk http://goo.gl/YGd6ta about the same idea (importance of building complexity from simple building blocks) to build pieces of paper that diagnose diseases... Same movie different actors...

So there... at the "right" level of abstraction you can re-factor West Side Story into  Romeo and Juliet by changing the UI.

The Connection Machine

The Connection Machine -space based architecture

 

Facebooktwittergoogle_plusredditlinkedinby feather

"JTC1 Moats" TTM Simulation

Facebooktwittergoogle_plusby feather
14Mar23 " JTC1 Moats" TTM Simulation

14Mar23 " JTC1 Moats" TTM Simulation

JTC1 Moats  is a rotational trading strategy that ranks and selects from a proprietary list of approximately 100 stocks chosen for their defensible market position. It holds 8 stocks (if criteria is passed) and is re-balanced weekly. The system uses the S&P500 Volatility Index (VIX) and weighted averages to time the market. It invests in the iShares IEF 7-10 year treasury ETF during bear markets.

Facebooktwittergoogle_plusredditlinkedinby feather

"JTC1 Moats" 14 year Simulation

Facebooktwittergoogle_plusby feather
JTC1 Moats  14 Year Simulation

JTC1 Moats 14 Year Simulation

JTC1 Moats  is a rotational trading strategy that ranks and selects from a proprietary list of approximately 100 stocks chosen for their defensible market position. It holds 8 stocks (if criteria is passed) and is re-balanced weekly. The system uses the S&P500 Volatility Index (VIX) and weighted averages to time the market. It invests in the iShares IEF 7-10 year treasury ETF during bear markets.

Facebooktwittergoogle_plusredditlinkedinby feather

Paul Tudor Jones on the InJustice of Income Inequality

Facebooktwittergoogle_plusby feather

Paul Tudor Jones (PTJ) is a legendary trader  that runs one of the largest  Hedge Funds in the world....Tudor Investment Corporation. He recently gave a TED talk about income inequality.  https://www.youtube.com/watch?v=vesdt5vDIek PTJ shows data documenting a 40 year high in corporate profits as a % of Revenue and a 40 year low in the percentage going to labor (Classic substitution of capital for labor). I guess todays corporate leadership doesn't think like Henry Ford who famously paid his employees enough to ensure they could buy a Ford Automobile.

PJT has created an independent non-profit organization that will  poll 20k  Americans annually to  define corporate societal responsibilities that they will use to  rank the largest 1000 US companies.

Interesting that the early comments on YouTube are mostly negative. Commentators seem unconvinced PTJ is genuine. PTJ concludes that historically this level of inequality ALWAYS is corrected via Taxes, Revolutions or War. So is he worried about "killing the rich people"?  Perhaps, but someone of his stature needs to quit the BS that optimizing shareholder value is Smith's invisible hand. Read Smith, it's not.

I've  been inside the core of the Technology business (semiconductors and software) for over 35 years. I see four changes that are creating winner-take-all monopolies by compounding capital much faster than when I started in the 70's...

1) Repeal of Glass-Steagal and conversion from LLC's to Public Companies driving TBTF Banking   the largest corporate sector in total capital and profits.  We have ~$800T in capital supported by a  ~$80T global economy.

2) Knowledge (IP) , when exchanged, creates 2 owners of the same IP. The knowledge economy is a mathematical engine for exponential growth.  Most of world economic history was built upon physical object transactions which does not implicitly create shared ownership.

3) Globalization especially w/respect to the benefits of 2)

4) The flawed assumption of Ergodicity  in economic teaching and policy now well documented as a mathematical error in Menger's foundational book that created "modern" economics, http://rsta.royalsocietypublishing.org/content/369/1956/4913 . Lucky money compounds to +infinity but unlucky money stops at zero... game over for the unlucky.

I believe these have created a tangibly different environment than our economic history books.  I agree with PTJ that unintended consequences (inequitable distributions) will not settle out before Capitalism's benefits fail to benefit the majority of the people.

 

Facebooktwittergoogle_plusredditlinkedinby feather

Hardly anything hard to say about "The Hard Thing About Hard Things"

Facebooktwittergoogle_plusby feather

HardThingI recently read Ben Horowitz's book "The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers",  it was great!  I've read alot of management, marketing and strategy books but  I can honestly say it is the only book I've read that captured any of my experience as a CEO or being in the inner circle with a CEO in a startup. 

Einstein once said of his friend Kurt Godel http://en.wikipedia.org/wiki/Kurt_G%C3%B6del that his mere existence brought him happiness. I can say that about this book.

Ben captures five things that are integral to the role yet is never portrayed in the happy crap "small big company with freedom and payouts"  media and journalism stuff...

1) Impossible odds and running out of money (again)

2) Peacetime vs Wartime CEO

3) Firing / laying off friends

4) Lonely decisions (esp:  People Choices)

5) Overwhelming Guilt

Start ups are hard... it helps to be naive... why do people do it....  not all do...

Facebooktwittergoogle_plusredditlinkedinby feather

Mythical Man-months, Microservice Architectures and a Million Developers

Facebooktwittergoogle_plusby feather

farm-workersWatching a presentation on scaling microservices by Adrian Cockcroft http://perfcap.blogspot.com/  Adrian mentioned Twitter had over 1M developers using their API's. DEVELOPERS, not API calls or Apps using the API's etc. WOW!

So when Fred Brooks published "The Mythical Man-Month" in 1975 (MUST reading for all managers esp tech) he described solving the people scaling problem at IBM using clever team designs. His "Perfectly Partition-able Task" (like picking corn or strawberries) stuck in my head (I read it in the early 80's) as a framework ever since.

The gist was that teams working on complex systems had a communications/coming up to speed burden proportional to (N^2-N)/2 , where N is the number of team members (developers). So if we can scale "Dev Ops" unbounded using these architectures, I believe we have a tangibly different world than the words "big data", "cloud computing" or scalable software captures.

Partitioning tasks changed the size of things we built in the physical world... pyramids, Ford's assembly line, etc. it will do the same for what we build in the information world. A much bigger deal than many recognize...

Facebooktwittergoogle_plusredditlinkedinby feather