Why all the Hype of AI These Days is annoying – written by ChatGTP

Artificial Intelligence (AI) has undoubtedly become a buzzword in today’s world, with countless individuals and businesses hailing it as a revolutionary technology that will change the world as we know it. However, with all the hype surrounding AI, it’s easy to forget that it’s still a developing technology with many limitations and challenges. Unfortunately, many individuals and businesses have taken it upon themselves to evangelize AI as a solution to every problem, which can be incredibly annoying.

First and foremost, it’s important to acknowledge that AI is an incredibly powerful technology that has already made significant strides in many fields. From healthcare to finance to education, AI has the potential to improve countless industries and change the way we live our lives. However, this doesn’t mean that it’s a one-size-fits-all solution to every problem.

One of the biggest issues with over-evangelizing AI is that it can create unrealistic expectations. When people hear about all the amazing things that AI can do, they may assume that it’s a magic solution that can solve any problem. However, the reality is that AI is limited by the data it’s trained on and the algorithms it uses. This means that it may not always be the best solution for every problem, and it’s important to have realistic expectations.

Another issue with over-evangelizing AI is that it can create fear and mistrust. When people hear about AI being used to automate jobs or make decisions that were once made by humans, they may worry about the implications of this technology. If businesses and individuals over-emphasize the benefits of AI without acknowledging the potential risks and challenges, it can create a sense of unease and mistrust around the technology.

Additionally, over-evangelizing AI can lead to a lack of investment in other important technologies. While AI is certainly a powerful tool, it’s not the only technology that can make a difference. By focusing too much on AI, we may overlook other important technologies that could also have a significant impact.

Finally, over-evangelizing AI can be incredibly annoying for those who work in the industry. Many AI researchers and engineers are passionate about their work and want to see it make a difference in the world. However, when the technology is over-hyped and oversold, it can feel like the hard work and dedication of these individuals is being trivialized.

In conclusion, while AI is certainly a powerful technology with the potential to change the world, it’s important to avoid over-evangelizing it. By acknowledging its limitations and challenges, and investing in other important technologies, we can ensure that we’re using the best tools for the job. Furthermore, we can avoid creating unrealistic expectations, fear, and mistrust around AI, and instead work towards a more balanced and realistic view of this exciting technology.

Written by ChatGPT


This has been such a hard year for all of us. I thought this year, more than any, it was important to put together a gratitude list – you know – with Thanksgiving being on Thursday. Here is mine:

1. My daughter is one of the most important people in my life. She was a surprise to me because they told us she would be a boy and I really wanted a girl. I was elated when they said she was a girl (and asked that they check again because he could just be “hung like his father”). She has been the biggest blessing in the world to me. It’s been really fun to watch this totally tiny person grow into a smart, responsible person.

2. Everyone knows how much I adore my wife. I often talk about how lucky I am for tripping on things. I would have never guessed that I would be lucky enough to meet her and she would actually like me. It was just random luck that I am very grateful for.

3. Our boys. They are both such incredible people and so different from each other. It adds variety to the family. They are both amazing and I love them a ton.

4. My brother. When we were kids I was such a jerk to him. It was only because I knew he was brilliant and I was jealous. He is one of the most brilliant and loving people I have ever met – and I cherish every conversation I get to have with him.

5. My friends. I didn’t know how many I had. This year has connected me with people I knew in first grade – and for whatever reason we never connected. It’s amazing to me how 40 or 50 years can go by and you just connect with people. There are a few of you that I have kept in contact with over the years (Nick and Dina) but I found a lot of people this year that I didn’t even know they knew who I was and they have been just amazing to me – and I hope I’ve returned it.

6. I was really lucky and tripped on some amazing people to work with. What we were doing was serious but they made it fun. I wasn’t good at a lot of things and was lucky enough to find people I loved that filled the gaps that I had. I am eternally grateful to each and every one of you. It’s one thing to “work with someone”. It’s another thing to can’t live without them being there. The latter were the people I had the opportunity to work with.

7. Finally – Joey. He frustrates me to no end – but I am so glad I got him. I was obsessed with him from the first time I saw him. I had such a strong opposition to dogs due to various reasons but he has made my life so much more tolerable.

He is one of the best friends you could ever trip over. He is my Snoopy.

#1 – Daughter and Dad working.
#7 – Joey

Spiritual Belief Survey

I have a really good friend of mine that sent me an email a long time ago.    He was asking people about spirituality and their opinions on it.    As an atheist, I was honored to be included in the list of people to participate.   I tripped on my response today (I saved it) and thought it would be interesting to share.  I think the questions were really insightful.   Hopefully the answers I gave were as well …

It seems relevant today.

How would you characterize your spiritual beliefs?

I do not have any spiritual beliefs.

Do you personally believe there is such a thing as truth? Please explain why you believe what you do.

I think that “truth” is subjective.    Each person has their own beliefs that they perceive as “truth”.   Just browse Facebook for evidence 🙂

Let’s say someone tells you they believe their sacred text represents truth. What do you think about such a person and their assertion?

My personal belief is that people feel better if they feel they know the “truth”.  Life is uncertain and the belief that you have the “truth” gives you something to anchor your life on.    I personally, do not believe in “sacred texts”.   There are too many of them.   Charles Manson viewed the White Album as a sacred text, and we all know how that turned out 🙂

If there’s one thing you wish Christians would understand, what would it be?

My answer to this is not specific to Christians, but to all religions really.     Every religion is a variation of the same theme.   A metaphor that at its core has the same structure with all of the others.     I would love it if people could take a step back and see the similarities in belief systems and how they are translated for different people, rather than just rejecting other religions because the details are different.

Joseph Campbell did a documentary called “A Hero’s Journey” in which he outlined the basic structure of all myths / religions.   One quote that I really liked was the following:

“God is a metaphor for a mystery that absolutely transcends all human categories of thought, even the categories of being and non-being. Those are categories of thought. I mean it’s as simple as that. So it depends on how much you want to think about it. Whether it’s doing you any good. Whether it is putting you in touch with the mystery that’s the ground of your own being. If it isn’t, well, it’s a lie. So half the people in the world are religious people who think that their metaphors are facts. Those are what we call theists. The other half are people who know that the metaphors are not facts. And so, they’re lies. Those are the atheists.”

I think there needs to be an understanding that each person needs their own “metaphor” to ground themselves and that metaphor may be different for different people.    Thats the problem that I have with “truth”.   The perception of “truth” causes separation.


This is Shandi. She’s a new addition to our family.

The story of Shandi goes back about 28 years. Shandi was what I wanted my daughter’s name to be. I was totally overruled, but we settled on Kelsi (with an ‘i’). I have no idea why I had the obsession with the name. It came from a 1980 KISS song from the Unmasked album. The name always stuck with me.

When I met my wife, she had a beautiful and smart dog named Nikita – after the Elton John song. We had to put her down years ago – it was heartbreaking for all of us.   We didn’t want to go through that again.

Years pass, and my wife wants to get a dog. I say it’s ok if I get “naming rights”. She agrees and we find this beautiful little dog at a shelter that we fell in love with immediately.

The name Shandi has been a family joke forever, because I was so stuck on it. I won this time and was able to text my daughter, after all this time, the following:

“After 28 years, I finally got my Shandi”.

Addendum:   I got “Elizabeth” too, also a KISS song.    I steered away from Christine.

Development Methodologies and Jeet Kune Do

[ This post was written in June of 2006 and never finished.    After 2,000 words I didn’t know how to end it.    It still seems relevant today though with all this DevOps stuff going on – I found it while browsing old drafts ]

I was reading an article over on ittoolbox.com called Universal Development Process and it got me thinking about how ineffective most software development methodologies are and why they limit the creativity and productivity of teams.

Over the last year and a half or so, I’ve spent a lot of time in a fairly large company talking about innovation. The dictionary defines innovation as “the act of introducing something new”. I can’t remember where I read it, but I found a better definition of innovation somewhere that more accurately expresses what it is. This definition states that innovation is rarely something new, but is actually a “new application of existing ideas from one industry or problem area to a new industry or problem area”.

In this article, I am attempting to apply existing ideas from the philosophy of Bruce Lee’s Jeet-Kune-Do to the problem area of software development. Hopefully, you find some value in the exercise. I find a lot of value in thinking about it.


Development methodologies have been around for as long as I can remember. Each new “fad” promises better results and more productivity for teams using them. Personally, I have never been a part of a team that has implemented “a methodology” that did not run into problems that they could solve within the context of the methodology.

Unfortunately, managers and business users within a software organization are always looking for a “silver bullet” that will take what is ultimately a creative process and turn it into production-like processes that are repeatable and predictable. The basic assumption from these groups is that software development should be like making cars. The problem with this assumption is that each software project is different — and more importantly, each development team is different and unique in and of itself.

Fortunately for these groups, there are other groups of people that create and market “methodologies” that purport to create this productionized process for software development. The idea in most of these implementations are that there are specific things one can do to control the creative process of software development and make it predictable and repeatable.

These complete tool sets are marketed and bought by big businesses and forced on the development teams in order to help them be more productive. More times than not, teams feel limited by the tools, and options that are outside the process cannot be considered within the context of a software process.

Through much of my adult life, I have always enjoyed the writing of Bruce Lee. Over the years I have compared his ideas around “classical forms” of martial arts to the idea of software development and “methodologies”. This article is meant to draw some correlations and spur some thought among the IT managers in the industry to perhaps look at software development a little differently, as a creative, fluid process rather than something completely structured and rigid.

I’d like to take a few topics and talk about how Bruce approached them in the formation of Jeet-Kune-Do, and how these ideas could possibly translate into the “art” of software development and why individual software development methodologies, or styles, may not, in and of themselves, deliver the expected results that were marketed.

The Limited Vocabulary of Methodologies

When there is freedom from mechanical conditioning, there is simplicity. The classical man is just a bundle of routine, ideas and tradition. If you follow the classical pattern, you are understanding the routine, the tradition, the shadow — you are not understanding yourself.

— Bruce Lee

Bruce was constantly frustrated with the “static” nature of martial arts styles. His argument, in a nutshell, was that a specific style taught you a specific way of doing things and that with the limited vocabulary dictated by a particular style, you only had a set number of responses to what is normally a dynamic, ever changing, and most likely random chain of events based on the moment.

Perhaps Bruce could say it better:

Too much horsing around with unrealistic stances and classic forms and rituals is just too artificial and mechanical, and doesn’t really prepare the student for actual combat. A guy could get clobbered while getting into this classical mess. Classical methods like these, which I consider a form of paralysis, only solidify and constrain what was once fluid. Their practitioners are merely blindly rehearsing routines and stunts that will lead nowhere.

I believe that the only way to teach anyone proper self-defence is to approach each individual personally. Each one of us is different and each one of us should be taught the correct form. By correct form I mean the most useful techniques the person is inclined toward. Find his ability and then develop these techniques. I don’t think it is important whether a side kick is performed with the heel higher than the toes, as long as the fundamental principle is not violated. Most classical martial arts training is a mere imitative repetition – a product – and individuality is lost.

When one has reached maturity in the art, one will have a formless form. It is like ice dissolving in water. When one has no form, one can be all forms; when one has no style, he can fit in with any style.

— Bruce Lee

“Classical” methodologies have the same effect as Bruce felt “classicial styles” had. Talk to any team (better yet, ask the management team) and you will find that they develop software by “using RUP”, “being an XP team”, or “using SCRUM” rather than using a set of tools to develop software. The assumption by those above the team in implementing the methodology is that if you aren’t doing whats prescribed, your doing it wrong.

Unfortunately, when using a particular set of tools described as “the way”, one often winds up in situations in which they did not expect and have to find within the methodology the right solution to use, rather than doing what works to get the problem out of the way and get the project moving again. There is also a much greater chance that the team is put into a situation in which some “expert” will tell them that they “did it wrong” because they didn’t do it in accordance with the selected methodology. I’ve seen so much time wasted to figure out the “right” way to do something when everyone already knew what needed to be done, they just had to find a way that it would “fit” into the “official” structure of the team or organization.

The overarching structure of a particular methodology limits the possibilities a team has to act in a way that isn’t in accordance with the structure.

Notice that the stiffest tree is most easily cracked, while the bamboo or willow survives by bending with the wind.

— Bruce Lee

I believe that each development “methodology” is a collection of tools that could be valuable within a particular context. I do not believe that they are all or nothing. It is essential that you, as Bruce would say, “absorb what is useful, discard the rest, and add what is uniquely your own”.

Learning the Basic Tools Enough to Improvise

Within software development, we have a set of tools that we use in order to get our work done. Be it source control, languages, refactoring, test first development, etc, there are intricacies of the tools that we need to know in order to be able to improvise when situations arise that we are not expecting. Rarely, if ever, can we stick to one way of doing things on a project, so unencumbered knowledge of the basic tools are essential.

Again, Bruce addresses this within the philosophy of Jeet-Kune-Do:

I refer to my hands, feet and body as the tools of the trade. The hands and feet must be sharpened and improved daily to be efficient.

It is true that the mental aspect of kung-fu is the desired end; however, to achieve this end, technical skill must come first.

The techniques, though they play an important role in the early stage, should not be too restrictive, complex or mechanical. If we cling to them, we will become bound by their limitation. Remember, you are expressing the technique, and not doing Technique number two, Stance three, Section four?

Practice all movements slow and fast, soft and hard; the effectiveness of Jeet Kune-Do depends on split-second timing and reflexive action, which can be achieved only through repetitious practice.

When performing the movements, always use your imagination. Picture your adversary attacking, and use Jeet Kune-Do techniques in response to this imagined attack. As these techniques become more innate, new meaning will begin to emerge and better techniques can be formulated.

— Bruce Lee

Most of the time when implementing a “methodology”, more focus is put on the structure of the project than learning the tools around the methodology enough to be able to improvise. I like to focus my teams on becoming intimate with the basic tools that they need in order to work effectively.

Perhaps a practical example would help. We implemented Subversion as our version control tool in May of 2004, the day it went to version 1.0 – I would have had a hard time justifying a beta tool to the “enterprise architects“. During the transition to Subversion, I made the rule for the group that no GUI’s would be used with source control. Thats right, no Tortoise SVN, no Rapid SVN, nothing. The team was only allowed to use the command line tool. There was some “resistance” to this idea and to this day I’m not sure that I’ve ever really been able to communicate effectively why I made this rule. It all boils down to the ability to improvise.

I believe that in order to improvise, you have to have intimate knowledge of the tools at your disposal. This intimate knowledge of the capabilities of the core tool would enable each individual team member to aggregate a body of knowledge, internalize it, and be able to improvise when the unexpected occurred. This is one of the reasons why, as I’ve pointed out to my team members a number of times, that I have spent countless hours over my career retyping commands and / or code fragments rather than cutting and pasting – and why I still use emacs rather than the latest cool IDE. When it all comes down to it, repetition is the mother of skill. I believe that this is what Bruce was talking about in the above quote.

For our team, a GUI tool would have tied them to a fixed set of capabilities limited by someone elses interpretation of how the tool worked, rather than the true form of the tool and its capabilities.

Over time, I felt that this intimate knowledge of how the tool worked would enable the team members to generalize the concepts enough that they would be able to find new ways of doing things – that “new meaning will begin to emerge and better techniques can be formulated”. How the team used the tool was up to them, but I wanted them to use the tool in the purest form in order to learn it rather than a filtered version of it.

All or Nothing

When people talk about fighting schools they say that Kung Fu, or Karate, or this other style is the best. That is silly, and the problem becomes that the fighting style then becomes set in stone with no growth, and no adaptation, because what works well with me might not work for you.

— Bruce Lee

I was in a training class recently in which the instructor said “If you are not doing Pair Programming, you are not agile”. His assertion was that you have to use all the tools in the XP “methodology” in order to call yourself an agile team — that you cannot pick and choose the tools that work for the individual teams, but have to take the set as it is and use all parts.

I don’t necessarily agree. Pair programming works in many instances, but I have a hard time believing that this is the only way to do knowledge transfer and to create solid software. If it were, there wouldn’t be such successful distributed teams such as the Subversion Project or many of the different Linux teams (or the kernel team itself). Communication can be heightened without having people sitting next to each other watching or being watched by someone else. Bottom line is, depending on the individual, some might not be comfortable with this tool, and I think thats OK.

Its sad. Management teams overall want production line type processes to create software. They want to be able to predict schedules and everything that could possibly go wrong up front – and they want their predictions to be accurate. While most methodologies do not promise “precognition”, the interpretation by management teams most of the time is that precognition comes with the methodology they are buying. After all, why would they be doing something with a name if they are, more than likely, not going to better off in these areas by doing so?

[ This is where I ended.   After 2000 words I guess I was tired ]

Business Value vs. Customer Value

I read an article on the Accurev blog yesterday entitled Three Surprises in Software Development in 2012 that got me thinking. Specifically, it was this quote from the article:

“For every organization that is killing it with Agile, there are five (my agilesta friends say ten) organizations that are limping along, delivering buggy code to their customers, late, and missing committed functionality.  And often all three.”

One of the large challenges I see when moving people to agile are the ideas and concepts around “business value” and “customer value”. The term “business value” is usually used synonymously with “revenue” – how much money can we make if we do this thing that we are planning to do. Usually, this number is what gets a project resourced and approved for further development.

In an agile shop, we want to focus on “Customer Value”. “Customer Value” is considered something your customer is willing to pay for. Something they will find valuable, not something you find valuable.

During the adoption of agile practices, one of the first things that needs to be done is the reframe of how people think about the work they are doing from “Business value” (revenue) to “Customer Value”. Building something your customer is willing to pay for. Thinking of it this way, “revenue” becomes a measurement of success, a “side effect” of providing value. This mindset changes the way you think about your product development and the things you do to service customers.

Lean defines three types of work that usually occur in a process:

  • Work that provides value that the customer would pay directly for (Value Add Work)
  • Work that does not provide direct value to the customer (Non-Value Add Work)
  • Work that does not provide direct value to the customer, but is necessary in order to provide value they would pay for (Non-value Add, But Necessary)

Value add work, as mentioned above, is usually characterized as “something your customer is willing to pay for”, while non-value add is the direct opposite. A recent article I read uses blood tests as an example. Customers are willing to pay for the results, not the processes that they have to be subjected to in order to get the results (registration, paperwork, etc).

Once you identify the value add work the objective is to eliminate as much of the non-value add work as possible. You will not be able to eliminate all of it – which is why there is a bucket for “non-value add, but necessary”. Some things, like paperwork and medical history collection are necessary – your customer just doesn’t want to be exposed to it – or would not directly pay you to do it.

One of the trickiest parts of this classification is figuring out the difference between “non-value add, but necessary” and the other two. Many organizations feel that the things they do as part of their process are all “value-add” (why else would they be doing them?), while others try to eliminate anything that the customer is not willing to directly pay for (like testing or quality procedures).

Once we understand the different types of work, we have to go back to the difference between business and customer value.

There is a huge difference between something “your customer is willing to pay for” and revenue. The former is a statement of value from the customer perspective, the latter is a result of doing those things that the customer finds value in.

If you are viewing “business value” as revenue as an organization, you will make shortcuts in quality in order to hit the market or customers as quickly as possible – in most cases exposing quality defects that will effect the customer experience in a negative way. You will “ramp up resources” because the more people you have on the project the quicker you can get it done and usually you will short cycle things like testing, or code reviews because they aren’t serving the purpose of getting the product out so that people will use it.

Even worse, you will give up creative control of your product and add things based on requests of your highest paying customers – rather than think through the experience and do the things that provide your customers real value that they would pay for.

Revenue as the goal of doing something is the classic “Innovators Dilemma”. Companies continue trying to move up market by addressing their larger paying customers while diluting their product – as small upstarts develop products or processes that actually provide value – even though its not as much – at a smaller price tag. I think this “Innovators Dilemma” concept is what Steve Jobs was talking about in his biography by Walter Isaacson, when he said this:

“I have my own theory about why decline happens at companies like IBM or Microsoft. The company does a great job, innovates and becomes a monopoly or close to it in some field, and then the quality of the product becomes less important. The company starts valuing the great salesmen, because they’re the ones who can move the needle on revenues, not the product engineers and designers. So the salespeople end up running the company. John Akers at IBM was a smart, eloquent, fantastic salesperson, but he didn’t know anything about product. The same thing happened at Xerox. When the sales guys run the company, the product guys don’t matter so much, and a lot of them just turn off. It happened at Apple when Sculley came in, which was my fault, and it happened when Ballmer took over at Microsoft. Apple was lucky and it rebounded, but I don’t think anything will change at Microsoft as long as Ballmer is running it.”

Isaacson, Walter (2011-10-24). Steve Jobs (pp. 568-569). Simon & Schuster, Inc.

The goal of a product or service should be providing value to your customers, something they are willing to pay for. Revenue then becomes a side-effect – a measure of success. It becomes confirmation that you are doing the right things.

I don’t believe an organization can implement Agile successfully until this change in thinking occurs. The wrong motivators absolutely effect behavior – and most of the behaviors Agile and / or Lean try to implement is focusing on value first, providing quality software in small increments, and being able to respond to change quicker. The more you are focused on an end for you and not your customers, the more you are moving away from these values.

This doesn’t mean that revenue isn’t important – every company needs it. It means that if you are doing the right things, in the right order, it will follow and keep you going as a company.