Life Lesson, The missed assignment

Who doesn't enjoy dessert from  time to time?  Sharing ice cream shakes at the local hangout with your spouse or your child can be a rich memory.  Certainly I've enjoyed such experiences with my wife, my son and my step-son.  But my story is a different one and highlights not just Dessert, but Just Desserts.  In 1982, I took a leave of absence from College to decide what I wanted to do in life. While the following years would prove this to be a wasted effort, I did learn a great deal about what I did not want to do with my life.  I worked for a period of time with an insurance company in the commissions department preparing distributions to he agents each month.  At nights, I found that I had time to work a second job and was ultimately hired to work as the night manager at Orange Julius in Thousand Oaks Mall.  For those not familiar with Orange Julius, they are a purveyor of the most delicious Orange Shakes that you will ever taste..  The store mamager was a strange, shifty character, but the job paid quite a bit better than Minimum wage and I was very happy to get the job.  When I started work at the store, The Store manager took great care in introducing me to the night staff, and walking me through the store shutdown procedures.  The job was not especially difficult. or taxing.  My role involved:

1) Supervising the night shift
2) Assisting customers during busy periods and closing down the store at the end of the evening.

For this second responsibility, the Store Manager spent some time carefully describing the closing procedures:

a) The store had to be cleaned so that the day crew would arrive to a clean store ready for business the following day.
b) The cash registers had to be closed out which required the final totals to be run on each machine, the cash was then removed and placed in a bank depository satchel.  Then the satchel along with the cash from the register drawers was placed in the store safe so that cash could be deposited  in the bank the following day after the register drawers were restocked from the satchel.

Each night, after I returned home from my day job, I would freshen up and then drive to the Thousand Oaks Mall, clock in and begin my duties.  I would start by going to the back office and reviewing any special instructions left by the day manager.  every so often, I would be called to the front of the store to assist with customer service during the many evening rushes.

I  found a comfortable routine in my two jobs.and I continued in this vein for several weeks.  about this time, I was contacted by the vanpool administrator for the insurance company and asked if I would be interested in taking a hand at the vanpool job which had recently opened.  I needed to commute quite a distance to the office which would be relocating nearer to my home in a few months, so, I needed to travel regardless and I accepted the position, which paid an additional $50 per day.

As time passed, I learned why the prior vanpool driver quit.  Everyone in a vanpool is very particular about how the van is driven and they complain loudly when there are near misses or sudden stops which are frequent in Los Angeles area traffic.  After 3 weeks, I was asked to quit and I complied with this request.  Shortly after quitting the vanpool driver position, I became aware that there was an intense drug culture in the commissions department at the insurnce company.  Furthermore, the old-guard employees were not happy about the department's relocation to Ventura County, as they all lived in Downtown Los Angeles.  This created a schism between the old guard and the new recruits, including myself.  I found that the training that I received was incomplete; as a new-hire, my work was scrutinized more heavily than the other staff and any errors in my work caused by the old-guarrd employees were pinned to me.  When my 90 day review came, I was fired citing errors in my work - errors that were caused by my co-workers mind you, but it did not matter.  The only person that I would be held accountable to was the Manager who was currently doing everything that she could to keep the department in Los Angeles until she could find a new job with equal or better pay.

The evening of my dismissal from the Insurance company I smiled as I went to work at my night job. No longer would i have to work two jobs.  No longer was I driving he vanpool.  I just had a rather easy gig as the Night manager for Orange Julius.  However, as fate would have it, I was greeted at the Orange Julius by the store owner.  It turned out that the Store Manager had informed the owner that someone had been stealing from the night depository satchel or the register drawers and that this theft had occurred on the night shift, which was my responsibility.  I was advised that I was fired. I asked the owner if she trusted her day manager, and explained that I knew for certain that he had been stealing the money.  She told me that if I didn't leave immediately that she would call the police and have me removed from the premises.  As I walked away I asked her why would her store manager would specifically advise the night manager not to talley the cash before locking it in the safes?  I also asked if my fate was the same as the prior night manager.  I never got an answer.  She simply pulled out her cell phone and started dialing -- perhaps to the police or the security office.  A scam like the one perpetrated by the store manager cannot be played indefinitely and even a store owner can only have the wool pulled over her eyes a few times before the certainty that the store manager is the culprit begins to dawn on her.  I suspect that this store manager after finally being relieved  of his duties a few months later moved on to bigger and better scams, before finally getting caught and spending 5 to 10 years in state prison, all stemming from an experience with that delicious dessert drink: Orange Julius!  Lesson learned:  Always be diligent and look over your shoulder and question authority relentlessly.

The reader may wondrer, ,what does this haft to do with "The Missed Assignment"?
Allow me to explain.  Now Jobless, I tucked tail and returned to college, Where I signed up for a creative writing class.  In the first month, I was given a writing assignment to produce  a story about a conflict. The most important requirement is that it could not be a story about a courtroom conflict.  I punted and wrote the courtroom conflict anyway as I didn't recall any conflicts, in my then short years on plaaet earth, that I felt would make for a good read...

Dear Professor,

Here is my rewritten assignment  I'm sorry that it is a few years late!

When Democracy isn't

Rarely is it debated whether we live in the greatest country on the planet.  We Americans living in the United States arguably still enjoy the highest standard of living than most of the balance of the earth, yet our experiment with Democracy has snaked toward some very dangerous ground. The country was founded on the concepts "Of the people, For the People, By the People".  Yet, from time to time I wonder: which people?  Over the years, Democracy has morphed into various forms of Aristocracy and even Tyranny of the Majority.  It is the Tyranny of the Majority that I wish to discuss now.  Politicians are beholden to this Tyranny.  Should a politician favor a policy that does not suit the Majority and even fail to endorse or promote policies that are supported by the Majority, they will not have long careers in politics.  of greater concern is the fact that our state legislatures and State Courts are virtually uninterested in the opinion of the general public.  It appears that they have concluded that the majority of the people who take time out of their days to address policy issues in committee meetings are not among the mainstream.  Public input and open meeting laws are ignored even to the point of violating state law to move court rules and legislation through the political engines that have been built.  Certain legislation is voted into law with language that clearly intends to help people, but once the legislation is in place how does anyone learn that they have new rights or benefits that they may avail themselves of?  It appears that it's not the job of our branches of govenment to get the word out about legal rights, government benefits or services that may be beneficial to Jane Q Public.

I have recently studied a law that provided rights to a certain class of citizens in my home state of Arizona.  As I read further, I discovered that the right could  only be vested 30 days after some life event occurred, but that it was up to the individual to recognized the life event and to know that the 30-day limit applied to them.  Furthermore, there is no publicizing of the law and people who experienced the same life event prior to the enactment of the law do not qualify; thus, they are unable to enjoy the same protections under the law as someone who experienced the same life event just days after the law was enacted.

In my opinion this is all smoke and mirrors -- a mere pantomime of democracy.  The pretense of enacting such legislation is little more than a snub at the grand experiment in democracy that  so captivated Alexis De Toqueville.  In many respects, technology and especially the Internet has been the great equalizer, but in an era where the internet provides the means for any two people anywhere in the world to communicate at almost no expense whatsoever, It is enourmously disappointing that our government has done so very little to provide the public with access to the policy machinery that is in place.  It is ludicrous that an interested citizen must take off time from work and physically travel to their respective State Capitol to attend legislative or Judicial hearings  where policy decisions are made.  Why can't these hearings be streamed live over the internet and permit private citizens to comment in advance of committee votes on policy so that our legislative and court committees have public comment right at hand when they are voting on policy matters?  The only rational answer is:  because our government bureacracy has determined that this is not desirable.  In the end analysis, technology -- the greatest force in democacy is not wanted in government because of one unshakeable truth:  Democracy isn't.democracy anymore.

Phoenix Suns - Decision to fire Jeff Honacek, keep Markieff Morris

The media is abuzz with question why Phoenix has fired Coach Jeff Hornacek and kept allegedly disgruntled Markieff Morris on the team.  How exactly does the organization rationalize these two intertwined decisions?  In my Opinion, this is a no-brainer for anyone who has been a careful observer of the Phoenix Suns Coaching and Players.

Jeff Hornacek could not justify keeping his job during a winless stretch where Markieff Morris was largely relegated to being a role player, coming off the bench.

Regardless of his summer tirade in response to the trade of his brother Marcus Morris to Detroit, Markieff has been a Model of Character if you exclude the alleged towel-throwing incident for which Morris was the model of repentance and insisted that it was an accident..    In contrast, when you read about Blake Griffin punching one of the members of the Clippers staff, there is no mention about trading Blake Griffin.

To gain perspective on the decision to Keep Markieff on the team, you must watch the interaction of the players on the team, Markieff is extremely well-liked by his teammates, and presumably this extends to Markieff's conduct in the locker room.  While Markieff has had some conduct issues in the past, it appears that these may have been largely instigated by his Twin brother.  Markieff is still a talented prospect and a reliable contributor on this team.  With a coach who is willing to put the past in the rear-view and work with him, there is litle doubt that he will again become the player that he once was.  With all of this in mind, it is clear that this young team is actually better with Markieff than without him. Furthermore, Morris' contract is very kind in terms of the salary cap for a team that has massively over-paid two  point guards who the team is unable to keep on the court due to health reasons.  I haven't looked carefully at his effectiveness stats, but it appears from watching him play that he makes his teammates better whenever he is on the floor.  Sure he gets more personal fouls than Jeff Hornacek found acceptable, but his technical fouls are way down from last year, which is surprising in a year when the team is substantially struggling, and also considering that he was benched for several weeks.

In short, it is impossible to imagine this team proceeding without Markieff Morris.  He has clearly bonded with and is looked up to by the Suns emerging star, Devin Booker,  and the team would be disrupting young Booker's development should they trade his friend and mentor.  If you don't believe me, watch the two of them during warm-ups.  They are nearly inseparable.  The team has even tried to showcase the relationship between Devin Booker and Tyson Chandler with a media campaign -- perhaps to downplay the more influencial relationship between booker and Morris.  The team can hype the relationship between the elder statesman and the Rookie as much as they like, but It's clear that Devin Booker is blooming under the mentorship of Markieff Morris far greater than the experience of Tyson Chandler.

I disagree with Sports 98.7's Dave Burns when he says, "Jeff Hornacek deserved a chance to coach a team that did not have a Morris twin on it.."  In the final analysis, any astute basketball insider would have to agree that, with the dearth of talent that this team has, it is a team that ultimately is better with Markieff on the roster than not.Without him, they would be arguably worse.

To continue this story, shortly after I first published this blog-post, it was announced by Yahoo Sports' "The Vertical" that TJ Warren is out for the season with a broken foot.  Immediately I realized the wisdom of the Suns keeping Markieff and recognized that his stock to remain on this  team keeps going up every day.  Despite that, sources within the Phoenix Suns suggest that perhaps Markieff will be gone by the trade deadline.  I remain unconvinced as sources within the Suns organization had made similar comments that he would be gone before the start of the Season.  Since Markieff broke out for 30 points against the Raptors on Tuesday night, it seems like Markieff is not going anywhere unless the Suns are given an incredible offer -- perhaps a straight-up swap for another alleged problem-child, Blake Griffin?

Bottom line: every game that he suits up for this year's Phoenix Suns, he is one of the 2 best players on the roster regardless of whether he's starting or coming off the bench.

kylehanan@gmail.coml

1/30/2017 Update:  Phoenix Suns: 15 Wins - 32 Losses; Jeff Hornacek's NY Knicks: 21 Wins - 28 Losses - would lead one to conclude that Jeff Hornacek is the superior coach.  Furthermore, the subsequent trade of Markieff Morris to the Wizards was another questionable decision; regardless of whether that was what he wanted.

4/20 Update: Phoenix Suns have plodded through the drudgery of 3 losing seasons and even though this resulted in 2 top-flight draft picks, the Suns have suffered a self-inflicted wound.  It's ownership knows nothing whatsoever about Basketball.  Meanwhile the GM that they fired 5 years ago has gone on to appear in the playoffs in 5 consecutive seasons and won 3 championships during that same timeframe.  It's also not clear what the goal of the coaching merry-go-round is all about.  The coaches that they have had on the team since Jeff Hornacek have been utterly useless. If the goal of the team has been to tank and live through each of these seasons as the resident cellar dweller, then they accomplished that with near perfection.  Unfortunately, the Suns have wasted some of those draft choices, and furthermore the development of a young roster has been entrusted to a revolving door of coaches - meaning that the development of the roster has not proceeded very well.

A Brief Introduction to Software Stability in the Enterprise (part II)

In the previous blog post in this series, I introduced the concept of Software Stability as it applies to the Enterprise. However, it is important to understand what is really at stake when we examine the life-cycle of typical enterprise software solutions.  There are two prominent lifecycles that permeate enterprise computing.  The first type, I will refer to as "the Serpent" because it snakes a path through a software wilderness sustained by fundamental business needs, while undergoing numerous evolutions, tranformations and redesigns.  The second type I refer to as "Wag the Dog".  Such enterprise software solutions become so fundamentally core to the operation of the business that there is no amount of investment that is too much to dissuade the enterprise from investing in larger and larger change initiatives.  In fact, the entire viability of the enterprise may be dependent on the operation of the solution.  And at it's core, it constrains the solution space for any business changes or transformation to the point that the entire enterprise is beholden to the software and cannot adapt to changes in the marketplace without exhorbitant cost to the enterprise itself.  So many departments or divisions within the enterprise may be dependent on the Wag the Dog solution that it is impossible to transform the company in the way that the business executives would like.  In far less worst-case scenarios the cost of maintaining or supporting the Wag-the-Dog solution may be so high that it literally eats into corporate profits to the point that the Board of Diretors must consult with the CIO on a routine basis to address even modest changes to the solution as the budgetary impacts are so high that it makes ordinary capital expenditures seem trivial.

Software Stability is not only a better way to define Enterprise Requirements, and generate Enterprise Solution Design, but it is the only way technique that I have found that builds adaptability directly into a Software solution.  Through Software Stability methods and techniques, we can envision software solutions that will adapt not only to the structural changes of the marketplace, but also can adapt fully with the evolving nature of the enterprise itself.

“How can this be?” you may ask, “How is it that the software engineering and information technology departments the world over have been doing things wrong all of these years.? This is the wrong question.  To be certain, successful shops have keep a close eye on best practices and developed careful standards.  During nearly 30 years of designing and developing enterprise scale solutions for my clients, I have become acutely aware that each organization that I worked with used different terms to describe identical software artifacts, database objects, and even business concepts that were at their core the same thing.  This awareness caused me to ponder, “How is it possible to build quality enterprise solutions when enterprises cannot even agree on the same names for core business and technology concepts?  To be certain, some deviation in terminology that I observed was not the result of two companies using the same term at the same time, but an evolution of terminology as one best practice was supplanted by another best practice.  This is little more than the wagging of the dog in practice. Best practices evolve over time.  Software stability concepts start from a foundational taxonomy of terms that are enduring.  These terms which do not change over time.  Using these terms a concise taxonomy of Stable Analysis and Design patterns are defined.  This is fundamentally different from ordinary design patterns.  

Current practice in Software engineering, analysis and design owe a debt to Christopher Alexander’s seminal volumes, “A Timeless Way of Building”, “A Pattern Language”, and “The Oregon Experiment”.  Yet our attempts to disrupt the practice of software engineering have been far less bold than Alexander’s stated objective: “The books are intended to provide a complete working alternative to our present ideas about architecture, building and planning – an alternative which will, we hope, gradually replace current ideas and practices.

To Wit, the Gang of Four did not assert that the patterns that they published in their seminal book were the comprehensive list of design patterns.  They merely documented a glossary of patterns that they observed being used repeatedly by highly skilled engineers. Software Stability employs hard and fast definitions of analysis artifacts upon which stable design patterns can be extruded.  Software Stability aspires to achieve a disruption for the ages and an alternative which gradually replaces current ideas and practices.  At its foundation is the premise that “software has no moving parts; therefore it is contrary to reason that it should routinely break or age.   Stable design patterns can be identified through different analytical methods than we use today, by changing our approach to design we can model truly stable software systems and through stable analysis and design patterns we can build software components that are truly stable and enduring, and these artifacts can be employed as the foundation for software solutions that are stable over time and simultaneously adaptable over time at a far lower cost than conventional approaches. Software stability provides a solution to both the Serpent lifecycle of enterprise systems and to the Wag-the-Dog lifecycle of enterprise systems.

LA Lakers Woes.

It's a shame for all Lakers fans not only to witness the Lakers become the second best team in their home town, but largely irrelevant in the current Free Agency scramble.  Sportswriters have criticized Kobe Bryant for his huge ego and lack of willingness to shed some of his stardom and share the light with others.  I categorically disagree.  I don't mean to say that Kobe Bryant's ego isn't bigger than the LA Metropolitan area -- it is indeed.  The problem isn't something that Kobe could have solved by changing his attitude alone.  The problem began several years ago when Kobe signed a $134 Million dollar contract to remain a Laker for the remainder of his career and in doing so pretty much assured the Lakers would fall to obscurity with a contract that would prevent them from reloading in the waining years of his contract.  Even though the Lakers are not afraid to venture into NBA luxury tax territory to spend money on the talent that they need to compete, they must do so carefully or risk years of rebuilding.  True that hindsight is 20/20, but I envisioned this scenario playing out when Kobe's contract was first announced.  That said, I never could have predicted that Kobe would be unable to play hoops for fully 2 seasons with his various season ending injuries, but certainly such risks and the necessary mitigations need to be factored into contractual decisions.  In this respect, Kobe's ego clearly did doom the Lakers.

What passes for journalism on the web?

I am at a loss for what passses for jounalism on the web.  While I may need to shift my attention to other sources.  a great amount of the news that I peruse is found on Yahoo.com.  I have been saddened there to see articles missing very basic facts, such as the date of a reported news event or even the location.

With substandard reporting like that, what's the point in reading, especially if you anticipate that the information will be grossly incomplete.  What is the author thinking?  Perhaps in the rush and commotion to break the story first and generate the small coin that is likely paid to a beat journalist reporting for Yahoo, the facts really don't matter; what matters is getting the headline right, with the necessary level of punch and grab.

In 1839, Edward Bulwer-Lytton wrote the familiar adage, "The pen is mightier than the sword." It appears that the pen could use a sharpening!

A Brief Introduction to Software Stability in the Enterprise

Software stability is an interesting term.  As a software design paradigm, the concept was first proposed by my good friend, Dr. Mohammed Fayad, a distinguished member of the Computer Science faculty at San Jose State University.  A very light introduction to Software Stability can be found on Wikipedia (Software Stability Model) and another introductory article can be found on Dr. Fayad's site at SJSU (Intro to Software Stability) which  in turn will lead the reader to other materials that will help to better understand some of the underpinnings of software stability that are beyond the scope of this blog post.

The key concept posed in the research is: Software deterioration is caused by changes in software, and although change cannot be avoided, it's impact can be minimized. By examining the aspects or characteristics of software engineering that lead to stable software solutions, enterprise IT departments can mitigate the risk associated with change resulting in reduced cost of ownership related to support and maintenance. Furthermore, the expensive IT resources employed to support the IT systems landscape in the organization can be better leveraged to deliver added value to the enterprise rather than being consumed with lower-value maintenance tasks.

While Dr. Fayad and several of his colleagues have published a book and a good number of articles on the subject, it is a near limitless field of study.  For this reason the scope of  this series of blog posts will address those topics relating to software stability in enterprise computing.  While Dr. Fayad and  I would like to see practicing the the comprehensive methodology of software stability throughout all software teams, he and I are both pragmatic and sensible.  We realize that there will be corners of the software professions that will pick up on these concepts. Still, others will adopt similar approaches without realizing that they are employing the tools, patterns and practices laid out by Dr Fayad and other researchers.  After all it is a wonderful, if not confusing thing about software engineering -- researchers and practitioners often have two or three names for the same principle. For example the concept of design patterns is nothing more than a codification of what good developers had been doing for years prior to ever seeing the concept in print. For example, while working in various software development teams before the Gang of Four (GoF) published their famous treatise on Design Patterns, we did  not merely talk about lines of code, but we had consistent names for software artifacts that we created in the course of our work, often these names were reflected in the name of a code modules that participated in specific features of a software product.  Our names did not match the nomenclature of the GoF, but there were striking similarities.  For example, what GoF referred to as a "Factory", we may have termed a Machine, Processor, Compiler or Builder, often borrowing terms from other disciplines both disciplines outside of Software Engineering (Often terms borrowed from the very domains in which our Software Solutions were built to aid in efficiency of automation and of data collection), and inside of the Software and IT spheres as well.

The term "software stability" should be a standard in the vernacular of software practitioners in the enterprise, just as the term "design patterns" is a universally understood term in software development circles.  It is important that it be treated with some consistency when we talk about software quality, reliability, controlling costs and increasing value to the enterprise. This series of blog posts is intended to explain why software stability is a vital discipline in the enterprise.  That said, there are still many who struggle with the concept of software stability.  To characterize this challenge, let me first share a story about my first attempt to convey the value of software stability in corporate America:

When I first mentioned the concept of software stability to a software development director at a fortune 500 company eight or nine years ago, he was actually offended that the word "stability" would even be mentioned in the same breath as software.  His reasoning was that software in the enterprise is constantly fluid, and therefore, we have no business trying to make it stable.  Stable software in his opinion was end-of-life software.  While I understood his concerns, it was clear that his sense of stability meant something different than what I was talking about.  I realized that it can be difficult to get even the most well meaning IT professionals to appreciate the need for software stability.  Even years later, many in the industry are not ready for software stability. Perhaps it is due to the explosion of the "App Store" mentality where software is expected to morph and change all the time -- where would we be without our updates? Perhaps it is due to the broad adoption of agile concepts -- certainly it is intuitive that being agile is the opposite of being stable, right?

Wrong!  Agility is not the antithesis of stability.  The two are complimentary -- if not necessary and integral to success in an ever-evolving software landscape.  Software updates do not imply that the software is inherently unstable.  In fact, it is the stability of software that ensures that a software product is viable over time and remains reliable over numerous updates.  Enterprise software platforms such as SAP, and Oracle's ERP and Database technologies are inherently stable they run reliably and they have been around for decades. These products are continually updated.  Of course, those opposed to the concept of software stability will suggest that SAP and Oracle are not agile companies and they don't offer downloadable apps that are updated on a regular basis, so maybe these are not good examples.  It's a fair concern.  So, what about the IOS and Android platforms? Surely these are agile technologies and downloadable just as the applications that are downloaded onto these platforms.  I rest my case.  IOS and Android OS are agile technologies they are also stable technologies.

But what is it that makes these technologies stable and what is it that enterprise solutions architects and developers and IT managers and executives can learn from these technologies and from the concept of Software Stability?  To a degree it is infrastructure and architecture that contribute to the stability of these technologies, but there is more to it than that.  There are important concepts at play including Enduring Business Themes, Enduring Business Processes, Business Objects and Industrial Objects.  In Enterprise computing,  we need some standards and discipline that allow us to characterize the processes and characteristics of software stability in the enterprise.  We need formal techniques that allow us to measure that stability.  Disciplines such as unit and regression testing help with this but software stability is much further reaching and starts from the principle that quality and adaptability must be designed in to a solution.

The concepts of Enduring Business Themes, Enduring Business Processes, Business  Objects and Industrial Objects are important and I will describe how these concepts ought to be leveraged in the development enterprise software in future blogs on the subject.  It is important to point out that my concept of software stability in the enterprise is even broader than what you might glean from the academic literature on the subject.  

It seems that enterprise software solutions come and go and we in enterprise computing have become accustomed to 5 or 6 year obsolescence cycles where software gets re-written from scratch or replaced by a commercial product which is then jettisoned after another short 5 years, IT professionals do not necessarily need to accept that inevitability and Software Stability is a discipline that can help to add valuable and value-added years to the typical lifespan of software products. Even more important, Software Stability techniques can reduce the cost of ownership of software within the enterprise and allow software teams to be more effective.  In upcoming blog posts on this topic I will outline specifically how Software Stability practices deliver on this promise and I will explain what some of those key practices are. Software Stability should be a primary consideration of decision-makers in enterprise computing, because the cost-savings and value that a stable software solution provides is vital in controlling and intelligently allocating IT spend in the enterprise. Software Stability is an important consideration because stability and sustainability of software solutions does not happen by accident.  In fact, in practice it rarely happens by design.  Software Stability methods are a game-changer in the quest to deliver higher quality solutions with a longer viable lifespan and which yield a greater return on investment (ROI) to the enterprise.