software engineer

The maturity of a game changing technology is reflected by the non-academic clarity of how it is characterized and transitioned to the society to which it applies. – J. Durant

I consider myself very lucky that I was given the chance to work with computers at a very young age (1967) and at a time when the concept of automation was more a novelty than a pervasive reality.  It was also quite by coincidence that it was working on a project  (Ford Grant Project/BASIC compiler construction) at an institution (Dartmouth) that was a short distance from my hometown in New Hampshire.  At the time I was fascinated by what could be done with automation and how it could be used as a tool and not as a treat to society.  But I think back to some of the words that came from my mouth, as a babe of technology, and wonder whether they have had some play in all of this.  One example was while working with a bit of machine code I grew frustrated by the never ending barrage of diagnostic error conditions.  I made statements to my mentors (Drs. Kemeny and Kurtz), “if the machine is so smart to tell me I have a problem why isn’t it smart enough to correct itself?”.  While naive it certainly is within the realm of what we envision AI to do and not require the use of time nor intervention to resolve.

Today, some 40 years later, I am no less fascinated by the potential of technology.  At the same time I am also utterly disappointed with the lack of consideration given to transitioning society for its acceptance.   During the course of my life I learned that the best ideas often fail as a result of inept ability to #transition markets (also known to some as market conversion).  Even the humble personal computer had its moments until manufacturers demystified the technology and produced an affordably simplistic paradigm.

A Bit of History

Artificial intelligence (AI) had some early roots at Dartmouth in 1956.  The basis of academic research surrounding the use of computers to perform tasks lead scientists on a pursuit of assimilating thinking (or what we now refer to as learning machines).  Since that time there has been the ebb and tide of AI exploration.  My first exploits (1970s) were with a simple personal computer based package produced by Visi Corp. called ‘VisiExpert’.  It was a rule based solution that would allow you to create lists of conditions and correlate them to one or more rule bases (or in this particular case a simple set of tables).  The example that the package came with was the pairing of wines with cheeses.  I’m sure we could have done something similar with microbreweries and draft choices, or with employment roles and applicants.  The product never got much acclaim not because of its merits but because society was still trying to get their grasp around spreadsheets and word process solutions (databases would come later as they contributed to mailing and label list processing and table feeding for spreadsheet analytic review).  We saw a reappearance of AI in the form of Ada, a high-level Pascal derivative that introduced the concept of ‘object oriented’.  For some the provided a stepping off point from linear programming paradigms and created the potential for reference-able containers (or objects in terms of 1980s nomenclature).  But was this really AI or was it that the reference-able elements created the impression that conditions could invoke established constructs?

Since this time we have seen several what has been referred to ‘AI winters’.  In simple terms these were cooling off periods cause by economics, introduction failures and the reduction in academic and industrial research.  In the corners however there have been those individuals who sustained the course and continued to chip away at the rough hewn work of their predecessors.

Why Now?

There has been allot of topically provocations that have brought AI back to the forefront.  Utilization of big data, robotics advancement from mechanical to intellectual and demand caused by shortfalls in talent resources.   So while society laments about the concerns over loss of jobs and potential infringement on confidentiality the real culprits are in fact self-inflicted.   As I quoted at the onset, the conceptual framework that reflects the interrelationships of technologies (robotics, AI, analytics/data) remains loosely defined and fraught with personal opinion based prejudice.  It isn’t without coincidence that the few models that exist have yet to be proven in either an industrial or an academic research setting. so  how far would you lay trust unless you are also in an exploratory mode?

Let me get to the point on the two concerns voiced by the person on the street.  One – job loss (YES) but this will be replaced not just by people to care and feed AI but also those who will be engaged in different, yet to be defined jobs.  Concern two – confidentiality (YES) but fear not that its a matter of sharing by others but simply a sharing based on the need to know.  Not this sounds a bit like you need to grant permission.  But in today’s world the act of engagement is an act of implied permission.  We must cast away 20th century thinking if we wish to exploit 21st century services.  I recently read a comedic piece posted by Phil Fersht, CEO and Chief Architect of HfS Research involving a phone order being placed for pizza delivery.  It is as follows:

– Hello! Gordon’s pizza?
– No sir it’s Google’s pizza.
– So it’s a wrong number?
– No sir, Google bought it.
– OK. Take my order please .. – Well sir, you want the usual? – The usual? You know me? – According to our caller ID, in the last 12 times, you ordered pizza with cheeses, sausage, thick crust
– OK! This is it
– May I suggest to you this time ricotta, arugula with dry tomato?
– No, I hate vegetables
– But your cholesterol is not good
– How do you know?
– Through the subscribers guide. We have the result of your blood tests for the last 7 years
– Okay, but I do not want this pizza, I already take medicine
– You have not taken the medicine regularly, 4 months ago, you only purchased a box with 30 tablets at Drugsale Network
– I bought more from another drugstore
– It’s not showing on your credit card
– I paid in cash
– But you did not withdraw that much cash according to your bank statement
– I have other source of cash
– This is not showing as per you last Tax form unless you got it from undeclared income source
-WHAT THE HELL? Enough! I’m sick of Google, Facebook, twitter, WhatsApp. I’m going to an Island without internet,where there is no cell phone line and no one to spy on me
– I understand sir, but you need to renew your passport as it has expired 5 weeks ago..

Although totally comedic it remains plausible.  But again my question repeats itself, is this really AI or is it simply a form of what is also being touted by the label of DevOps (Development Operations)?

More Work Required

Aside from the need for framework clarity there also is the question of transitioning of society to embrace the emergent AI paradigm.  People aren’t looking to be sold on the merits or wowed by simple examples.  What societies need certainty about is the clarity of the vision and how control can be maintained.  Images of runaway robots, inaccuracies, false actions and other elements of mistrust abound.  These represent apprehensions created from shortcomings that exist today without AI that can only be elevated with the deployment of a data driven, rule based solution.  Certainty must be earned and shown.

I also believe, in the field of many-many things that need to be done to promote and empower AI, that we need to be looking at things very differently.  If something is done in a certain way do we still need to do that?  Do we need to ask the question if we already have the information or do we need to do it differently or do we need to do it at all?  This isn’t just pertinent to AI but can be equally asked for robotics or even advance analytical applications.  Do we need to perform a six loop analytical calculation or is sufficient for us to simply be alerted and observe a present condition in anticipation of a potential outcome?  It’s these sorts of question but more importantly the thinking mind set that will put advanced technologies like AI into the realm of usable/plausible.


Of course until finality.   I believe we need AI, not because I’m a technologist that is fascinated by potential but because I am concerned.  I’m not concerned about job losses or confidentiality they have exist, will continue to exist and that is just the way it is.  If you are concerned about job losses you can escape it with being self-employed, you can lose that too with the stroke of a governmental pen or the lack of personal attention to the care and feeding of an enterprise.  You can’t avoid the loss in confidentiality by believing you can lock it away, life in the 21st century is a transparent box whether you want to believe it or not.  If you want total confidentiality then become a hermit but even the hermit has someone who will have your fingerprint.  AI like robotics and analytics has a place to create an opportunity for thinking.  Whether this is focused upon innovation, optimizing, creating or simple recreating the ability to put to task routine parts of our life should be embraced.  Those that chose not to embrace will be destine to a emerging nation paradox where brute force in numbers will overlook efficiency though work augmentation by mechanization.   You can chose to break up concrete with a workforce of thousands or employ a machine that will convert it all to rubble in a matter of hours.  The decision is ours and ours alone.

Yes there will be a next.  ‘The next’ will explore the clear thinking necessary to create a outcome based AI and not a crafted emulation of what we think is human though and logic processes.  A look into the rough constructs necessary to transition from legacy intellect (automation and non-automated systems) to the next forms of creating a durable AI learning machine paradigm.

Till then keep thinking and dreaming (unconventionally).


We hear allot about design…..

  • Simplicity of the design,
  • Durability of design,
  • Beautiful design,
  • Failure in design, and
  • Blah-Blah-Blah design.

What the heck is all of this stuff about design?  Thousands if not tens of thousands of books have discussed, formulated and promoted design as the key to outcomes.   But as we see the buck stops at the talk and often goes no where beyond that stage.  Why is this happening?


Myth #1 – Design is not a Title

Sure you may have the word in your position but design is not reserved to one person or one group.  Everyone does some sort of design.  Design is not a task but an interconnected set of events that compositely give us a sense of doability, complexity and direction in which to advance the development of a product or solution.  I’m sure that most have sat in meetings in which business units will sketch out what they are doing and what they would like to have happen… this is design.  Albeit possibly not to the formal liking of the purists it is none the less design, don’t make fun of it!  Even the administrative assistant who is arranging that all important luncheon meeting is doing so by design.  Some possibly from experience and habit and in some cases by a sketch of things to do and organized into some paradigm that they (or others) can utilize.  So design is not reserved just for those titled but everyone is a designer unto their own rights.  If we think back to our childhood, the moment we observed things and later picked up a crayon, pencil or pen our goal was to design something.  Maybe it was a big red barn, a portrait of our family (in stick figure form along with fido) or maybe it was a more ambitious project to form shapes that lead us to the creation of letters.  All of this is design.


Myth #2 – Design is Necessary

I prefer to think of design as not being necessary but merely the natural bi-product of thinking.  The human mind cannot process chaos, it strives to have order and seeks out some place where past experiences have had similarities.  The freeing of process to seek a base of information is essential but in doing so we need something that gives us certainty about so so many questions.  Some look for solutions, others question the importance and some even wonder whether we have got some reasonable level of completeness.  To answer these and many other questions we look for help and to achieve this we look to formed methods and techniques.  Experienced individuals will have their own preferences and even some custom made methods that they rely upon to acquire design awareness.  I have relied on tools such as Unified Modeling Language (UML) (structural, behavioral and interactive models) to exercise the multifaceted features of an application project but my design toolbox isn’t limited to this one approach.  Such techniques as high impact inspections, test driven design (TDD) and rapid story creation have been equally valuable and gratifying. These all are beginnings leading to a design vision.  It very well can be and often is more than one, and this is okay.  Multiple options give us flexibility and alternatives which we are most often going to need during the course of a project.  In the case of Agile projects if we look at the arrangement of stories into families, usually surrounding the notion of work to be performed we have a design that can be lifted from it.  In the more classical context of waterfall or v-model methods we are more apt to conceive design as a bi-product of understanding and embracing design.  Both the same yet achieved in difference ways (and possible with prejudice different expected value to be achieved from each of the approaches).


Myth #3 Design Is Magical

This is where it gets a bit dicey…. is design something you do regardless of sound engineering principals being applied or not?  Those who are proponents of building and exploring (which is by definition research) really do so without a design.  I would, from practical experience, say yes.  Its not that its not important or necessary its because the process being used is intended and focused on doability and the possibilities that can be exploited, nothing more. For this reason this sort of work is intended to lead to knowledge, which in classical terms is a defined requirements vision, to which the formalization for completeness can be exercised.  Unless we intend never to do anything more with it, including repair work, then design is not needed.  However, most will reverse engineer a design from what is produced to not only create a positive maintenance atmosphere but also to definitively answer the question about whether the endless possibilities of the research has been reached.  For others design ‘anything’ are used as guides to form work and task lists of things to be constructed to achieve the desire outcome.  This includes a definitive understanding of how the piece parts will work in harmony or contention, based on the desire of the design outcome (and requirement visions).  The creative aspect of design takes place as the result of formation and the convergence with specific technologies be it hardware, software or idiom (SaaS, Cloud, Big Data, etc.).  Its this exercise that we start to seeing balancing, or the absence of, occurring.  We hear the term dependencies to reflect the level of cohesive and interdependencies that exist in design.  There are reasons for tight cohesiveness, often centered around constraints (memory, bandwidth…) but sometimes its caused by gross negligence and poor practices.  Design management cannot be taken lightly, it required purposeful and dedicated attention to insure that all is made right.


Myth #4 Design Is a One Size Fits All Proposition

Will the concept is rational, at least in so far as the initial deployment, subsequent activities that involve changes and modifications results in an erosion to design.  This produces some interesting challenges for such paradigms as the software reuse factory, refactoring and agile driven modularity.  So how can this be overcome if at all?  Since it is a foregone conclusion that our lives will not remain static we have to assume change.  We might even have a pretty good idea as to where it will take place, when it is like to occur and to what extent it can be expected.  If we have even the slightest idea about any of these things we can insult our general design in two possible ways.  The first is by utilizing a plug-n-play approach where pieces can be exchanged in an out of the solution set.  The second more difficult approach  involves design retrofitting, the act of redesign taking place as changes occur.  In order to sustain durable and reliable design one must have software support to provide us with real time dynamic vision  into the solutionset.  Using this information is like having a dashboard that permits us to address the impact of change as to the target design it is being made against.  Not all design is evil.  In fact it can be a welcomed relief for legacy applications and those in which design was really never a strong point from inception (e.g. may be caused by rapid response driven deployment or first time out solutions).

imagesMyth #5  Design Mastery Can Be Taught

There are some things that you simply can’t teach without experiencing it.  It takes practice, failure, listening, observing and mentored guidance to become not just the ‘titled’ individual but one that clearly understands and has mastered design.  Disciplines such as structural and civil engineers mandate not just schooling but also board examinations and a period of internship.  Yet in information technology certifications are a matter of choice and not one of mandate.  Some might argue that the risks are different, but are they?  Maybe the most compelling reason for experience is the result of converting intellectual visualization into an habitual endearment to the means of achieving designs that work.  We sometimes make the mistake of thinking about the end and not about the means of achieving it.  In the immortal words of Steve Jobs, “Design is not just what it looks like and feels like.  Design is how it works.”.   Maybe this is why Steve Jobs worked so so well with his long time friend Steve Wozniak.



Engineering (from Latin ingenium, meaning “cleverness” and ingeniare, meaning “to contrive, devise”) is the application of scientificeconomic, social, and practical knowledge in order to design, build, maintain, and improve structures, machines, devices, systems, materials and processes. It may encompass using insights to conceive, model and scale an appropriate solution to a problem or objective.  (source: Wikipedia)

As humans we are apt to try and fool ourselves into believing that we aren’t perfect but we can be if we follow a ritualist approach to things.  We do this in order to convert what might be haphazard into a prescriptive, methodical and cohesive way.  One might ask why this is wrong?  In fact it is quite well intentioned and in most cases a quite appropriate thing to do.  Since the beginning of engineering like activities we have worked as skilled, talented artisans.  As the popularity and durability of the profession became established a need flourished to put formality (in written and pictorial form) to it.  But did we do it right or did we simply scribe forth what we had done and overlooked some of the more important aspects such as the ‘skilled craft’ element that only a select few can do?

I’m sure some of you have read ‘How to’ books, how often can you apply what is being written and have it turn out like it was intended to?  Skill, talent and even mental conditions are of immeasurable importance to the outcome whether we follow guiding instructions or not.  We often marvel at those individuals who can use (or not use) a guide and still overcome challenges and may even further improve upon what is being done.   The true purposes behind these pragmatic and detailed engineering frameworks is to institutionalize behavior in the context of the masses.  It is a foregone conclusion that the ‘masses’ must do something with it other than blindly use it.  People need to consume, explore, develop experience with and institutionalize it within the sphere of technical abilities.  It isn’t about adaptation but embellishment.  We hear time and time again that it “will depend” or “it may not fit all circumstances” and my reply is simply “rubbish”.  The framework of engineering is universal and if sound it will bear tentacles applicable to the situations and circumstances for which it is being applied.  An example is the comparison of traditional software development methods (waterfall, RUP, RAD, JAD, iterative, conical, V-Model…) against agility (Scrum, Xp, Crystal…).  They all have three components; a stimuli, construction and confirmation.  Whether the stimuli is created in an ah hoc fashion by inexperienced and unskilled individuals is irrelevant.  What we do with this source and the participants involve is a totally different matter however.  Its only when it start entry into the engineered construction cycle that we make choices about the raw materials.  If substandard or inadequate we know that it needs transformation to a level acceptable for advancement.  As professionals we are obligated to exercise prudent care, not reckless acceptance.  NO Engineering method will ever overcome environmental conditions that are unacceptable.  If one leaves these matters to chance or luck then its not engineering its what we would call ‘game theory’ and the last time I knew there was no mention of such facts in the annals of ‘best practice’.  The ploying of engineering practices to construct make best sense when in harmony with the intellect and experience level of its participants.  Even though there might be a better engineering approach to a problem one can never overlook the readiness of the people involved.  Too much, too dramatic and a steep uphill learning curve that has been contaminated by past failures is not a right setting for revolutionary change.  Let me be a little more to the point, it might be just what is needed however all of the other things (in the negative) that have gone wrong will only make this attempt ripe for failure by way of it being used as an excuse.

The art of engineering takes the pieces, places them inside of a vision (aka a design driven outcome) and is crafted and bonded together.  This is, as we all know, in the most simplistic and idealistic sense.  What really takes place is allot of effort driven by experience, compensated and grown through collaborative efforts, and willingness for open transparency as to what is taking place.  If it becomes an exercise in politics and hidden agendas the engineering initiative has failed from the onset.  This is about producing results and not about a total fixation on happiness.  Both can occur but not at the expense of the other.

This gives you a bit of a sense for engineering in its most primal sense.  Its pragmatic, yet flexible, intent on knowledge equality among the masses and a means to achieve sound/safe/reliable results.  An engineering method is only as good as the authors, for they are human.

ImageI think back to a course I took in college simply called “Introduction to Systems”.  With great expectations I imagined a program that would take some 5 years of field experience and round out my understanding about the topic and add some contextual perspective to my exposure.  It seems that my quote that “expectations is the road to disappointment” is quite true.  What I ended up with was a more global thinking on how various systems interplay.  My post class opinion was that it was a big waste of time, energy and value.  Some 30 years later I now understand, appreciate, apply and have drawn my own perspectives on the topic.

All activities whether involving technology, business or human existence is surround and involves systems.  Some are manual, others are fully or partially automated.  They are share one common element and that is precision (tolerable level mainstream management while succumbing to non-mainstream exclusion).  How we detect, treat, control and manage the exceptions plays a significant role in future system maturing.

What Do YOU Want?

ImageThe key word is “Requirements” but in using such a simple self-defining word we introduce risk.  We have a tendency to think in singular terms and fail to consider the multitude of other contributors to the specific “system” solution that sits on our project to-do table.  This system is often the melding of technology and manual participants.  It’s present state the culmination of years of change, some to address new opportunities and external mandates and others addressing delivery issues (often thought of as errors or bugs).

Each and everyday we are need of change.   These systems we have concocted involve various stake holders and constituents.  Many think that we have a single person, often the funding source or primary users, and that is all it takes to produce system solutions.  Far be it to consider other stakeholders who may be responsible for adjoining/interconnection systems.  Far be it that we overlook that there are solution providers, such as information technology or service contract company (aka outsourcer), who is likewise needing to be taken into consideration.  The real issue behind requirements issues include a failure to,

  • Include and address other involved parties,
  • Have sufficient regular experience (when you have this you need help),
  • Use means and models to lower omission risk,
  • Employ ‘clear thinking/green field’ approach (our rush to solutions places us asking what we had only with a bit of a face lift),
  • Think in the long term but define in the near term requirements that are impervious to change not the whipping post to common conditions,
  • Understand what is needed, what is nice to have and what is simply a big wish, and
  • Understand the importance of roles in defining what you what.

I’m NOT a Big Fan

ImageCall me different but I get turned over by thinking that one size fits all.  Whether it be a horizontal solution (usually driven by functions such as accounting, finance, procurement…) or vertical discipline (pharmaceutical, manufacturing, commerce, logistics…) you can try to make that size 10 foot fit into that size 8 shoe but it will be painful and will often require modifications that will be clearly visible.  Not to mention it will be felt throughout the life of the system solution.  We all know that we seldom see systems go away.  If anything they endure the test of time, albeit often ungracefully, and there often times that it would have far better if we cut our loses and moved on.  Some while back I wrote about the durability of applications which follow a very similar life pattern to individuals.  They progress from conception to elder years with all of the stages and characteristics of humans.  Some reach old age, into senility while the organization remains committed to keeping it on life support.  When this occurs a red flag needs to be raised because we are placing business values at risk.  These will often include customer service, efficiency, accuracy, timeliness and the all important increase in service costs.  So why do we keep the albatross afloat when its terminal?  Simply… the belief that a system is perpetual.  I can’t think of many things in life that last forever, when used, without a need for replacement.  The few often were engineered with change in mind and permitted element replacement will retaining the design.  It should be pointed out that from a general system perspective that design endures time much better than implementation (aka detail design).

Let Me Revert

ImageGetting what YOU want is a personal issue.  It makes use of your education, experience, exposure to those non-mainstream occurrences, understanding of risk and constituent systems and most importantly free/clear thinking without prejudice to the ‘how’ (unless absolutely necessary).

I’m not a big fan of written, book form, requirements.  They are difficult to use, analyze, maintain and are highly inflexible.  At the same time they will be required for a vast variety of purposes (internal control, future maintenance, training, study/analysis, etc.).  I am a big fan of facilitated story boarding.  This involves a series of facilitated free thinking sessions each geared to eek out requirements.  In complex and/or broad system situations there will be a need for multiple group meetings (culminating in a combined familiarization and closure meeting) and the use of tools such as ‘focus sessions’ and preparatory reverse engineering input.  Don’t overlook open issues as a part of these solutioning sessions, Issues point to unresolved matters and areas where complexity (sometimes ‘rightness’ comes into question).

You can achieve quality requirement generation results in 10 hours.  This is hard to believe for many since it is often a journey that is much much longer, seems to never quite settle down and becomes a nightmare to maintain.  Behavior is often linked to group debate and contention, ever changing ‘rightness’ in terms of needs and value, and the general inability to digest a substantial specification (let alone measure coherency and completeness).  The use of story boards make visible requirements, needs and thoughts.  One needs to avoid subjecting them to critical evaluation until they are considered complete enough to proceed further.  At that point discussions can take place, risk and effort can be considered, merits can be examined and delivery scheduling and be undertaken.  We want to make absolutely sure that we don’t start shooting down someone else’s ideas until we have get all of our thoughts out on the table.  Furthermore the needs are based on merit and not based on whether someone has a bigger stake or not.  What might seem trivial to you may be absolutely needed by the other party… be responsible enough to consider this factor.


ImageObviously there are allot of other things to consider when dealing with requirements (or needs).  Trace-ability, test-ability, segmenting epics/sagas, estimating effort, engineering a total solution (whether a piece or the whole) and maintaining control over change.  Change is our enemy if we fail to manage it but at the same time change can keep our business in the game.

A solution is the end to a vision and not the glory of accomplishment.  System solutions is about achieving goals that are important and doing so in a complete solution fashion (without one sided prejudice).

ImageI once heard a person say “there is no such thing as a best practices”.   As I pondered this quote and reflected back on years of work experience I found the statement to be quite true indeed.  The “best” in anything is based upon the context (situation) to which the qualification is being given.   Any of you that has an addition to something, whether it be candy, coffee or some other vices, should realize that what is “best” isn’t always right when it comes to uncontrolled and wrongly inspired pursuits.

Some while ago I was dealing with a customer who was on a quest for excellence in software engineering.  They were throwing all of their efforts towards this pursuit.  Hiring some of the most talented people, utilizing state of the art technologies, and crafting some of the top methods in the industry.  One would think that they would be on a course for smooth sailing.  But to the contrary they were in utter chaos, motivation was at a low, and remedial solutions with feverishly being employed to counteract this downward spiral.  Off in the corner of this company a small group of engineers was merrily off crafting solutions, they weren’t perfect or entirely by the book but they were achieving the results that were asked for by the user (aka project sponsor).  At first glance one would say it was the people, others were quick to say that the burden of process was what was holding others back… and that the wayward direction of this team showed it wasn’t needed, while others were simply discounting luck as a means by which achievements were being made.  We were asked to try and sort this all out and to help them in achieving their pursuit.  What we discovered is not uncharacteristic of client/buyer companies and companies that deliver software solutions as a service… the goal doesn’t match the need.  What does this mean??  If we think of solutions, software or otherwise, we have certain expectations about its risk and durability.  If I buy a cheap watch I expect that it will last a certain amount of time, beyond that its a blessing to get more.  But if I buy an expensive timepiece I expect a whole lot more in terms of durability, longevity and event features.   I have to say that today we are overwhelmed with commodities that are embellished upon to draw market attention but because they are producing cheap watches the excess is not a virtue but is in fact a fatal inhibitor.  If that cheap watch comes with a temperature sensor and a flash light and both either fail to work or only for a limited time it then becomes a sore spot for criticism.  The long term effect is to push for a more simplistic solution and not with with excess perceived value (what some might refer to as Gold Plating).

In the software engineering context we have been a bit misguided by our pursuits.  Rather than to use these aspirations as a measure to advance, improve and afford economic value we have them as stick to drive behavior.  Unfortunately we have seen time and time again that it has driven us to exact polar opposite… its created chaos, confusion and a loss of direction.  In the case of our client company they had wonderful ambitions.  At the sametime these ambitions got in the way of addressing what level of excellence was prudent for the types of solutions being developed.  To user/sponsors who were looking for appropriate and reliable support, they were getting excesses that provided little value, higher maintenance and operational costs, and were fraught with issues.  What should have been an environment to achieve this had become in an of itself the culprit.  Our first question wasn’t about tools, techniques or people it was about the goal.   Was a top tier best practice and the formation of a center of excellence right for the type and complexity of the solutions being crafted?  In the context of a CMMi model, were you aspiring and working to deliver level 5 solutions in a level 3 context??

Today, 2013, we are inundated by companies, who profess their excellence in how they have set the stage for solution engineering.  But in setting that stage the cataclysmic result show a much different situation taking place.  No, these people are not hell bent on creating chaos, they are driven by excellence.  However this unrelenting pursuit is in juxtaposition to what is needed.

The correction can be painful.  It seldom requires a wholesale reversion to earlier practices, rather it requires a righting of the course.  It requires a modification of goals, of practices and even team compositions.  The utilization of software service engineering companies will require a reappraisal to insure that they are operating at the ‘right’ level, and not simply at a level where excellence cannot be achieved (despite all the pragmatism that may be touted).  Some would wish to believe that this will require an objective third party, which it may depending on internal politics, but it simple needs someone (usually a group) to undertake the work of reshaping, re-crafting and redirecting the initiative.  It isn’t always a lengthy effort, but one that requires meticulous attention to the fine details and the effect of change.  The time that can be substantial is in transitioning, redeployment, monitoring and advisory.  But this is a cost of learning, whether its by mistake or by redirection.

So at the end of engagement we were asked what the cost would be for putting things back in good order?  We had worked the numbers and arrived at a cost for the revamping project and put it up on the white board. The client said, “wow I thought it would have been more”, to which we responded it would have been if you stayed on the wrong path.  You would have put at risk everything, not just the software/IT operation but the business as well.  These are matters that cannot be implemented on the basis of popularity, common practice or casual analysis… they require heartfelt and earnest consideration that weights the benefits against reality and not based on wishful dreaming.   Make your best practices and your centers of excellence appropriate to your world.  Stretching a bit is okay as long as its within your attainable grasp.   These measures will contribute to your business, be responsive to needs, and serve as a foundation for the forward growth of the delivery enterprise.