Everything is Script -- A Philosophical Interpretation of Software System

 

The word 'script', I know it from days I started practicing Shell script.  My understanding for script then it was -- a small set of instructions in a file or piped through in a command.  

Prior to this, I had heard VBScript.  But, I did not use VBScript.

The bash script that I wrote did not span beyond 50 lines, then.

This was my first encounter with word 'script' and how I dealt with set of instructions grouped in a file and called it script.

The Ambiguity -- Script or Code?

I have this conversation in myself for a long time ow -- What is Scripting Language and Programming Language?

Technically, there are reasons why the two are seen as different paradigms in building and running the software systems.

That said, Python serves as Programming Language and also as a Scripting Language.  I learn JavaScript also falls into the same perspective.

In short, this is what I understand for script -- technically compilation exist but I do need to do it explicitly, can run using interpreter, quick and useful in automation of tasks.  

Today's programming languages can also work like scripting languages.  I see this is one of the key reason for the ambiguity.

Then what's the difference and advantage of scripting over programming?

• I understand, the scripting languages leverages the speed of writing and automation.
• Whereas, the programming languages leverages performance, structure and scaling of systems with better control for processing, memory, storage, exchange and communication.

Mental Model -- To Ease My Understanding

Scripting

• Say, the instant coffee that I prepare with Bru or Nescafe sachet and milk.
• Though there is a kind of compilation, that is, mixing of coffee powder and milk, it is not evident to viewer, who is making it, and the coffee sipper.
• That was fast making an instant coffee!

Programming

• Me preparing the coffee by boiling the milk and then add coffee powder.  Boil it for few minutes. Then filter and sip it.
• This is not as a instant coffee.
• It had different layers [explicit compilation] to go through before feeling the aroma of coffee and sipping it.

This mental model helps me to get and feel the coffee.  But, the taste and aroma of coffee got from these two approaches are different.  

The second way of preparing coffee gives me a control on how the coffee has to taste, feel and serve just to me or for the crowd.  I see this is a paradigm of programming language in a perspective.

Philosophical Perspective -- Everything is Script

Caution: This section is not confusing; it needs imagination and interpretation to see it.

I have been into this debate with myself.  One of me says, why the word 'script' is not so right for context.  While the another in me says, why the word 'script' is so right -- this person have had a upper hand so far in the debate.

Why I feel it so right?

• Philosophically, whatever I do it is a script.
• In that case, a software version deployed itself is a script.
• Why?
• A software system is a bunch of such coordinating scripts.
• Each script has a structure, organization, specific seams and responsibilities assigned to it.
• These scripts undergoes changes consistently to keep it contemporary!
• The word contemporary weighs and augments the notion of 'script' in the software.

I see, the script is always in the state of development unless the system turn to be static and requires no change.  But what it is static?  Is there anything static?  That's philosophical you see!  From the point view of computer science if it can be deleted any time and restored is that static?

Today's software system keep evolving to meet the need of business and scaling.  That way each deployed software version looks to me as a script doing a specific job to constitute the idea of software as a service.  This script sees the consistent development and maintenance to serve.  Do you see this philosophical and mental model of me?  

Seeing each component of the software system as a script  is philosophical.  Technically it make sense to me for interpreting it this way.  But, when communicating to people I cannot present it this way.  Why?  If I do so, it confuses people who follow the distinction between programming and scripting languages.  

I understand this confusion here is for not seeing there is a philosophy to the technical aspect too, and just consuming the technical as binary.  Is that wrong?  No!  That is also a way of consuming what I understand and what I just need  -- it serves the purpose well.

When the script [software components philosophically] undergoes a change, the system composing of such being developed scripts can still co-exist together.  Here is where that person in me asks -- Why should I remove the notion 'script' from my vocabulary, practice, interpretation and usage?  This question hits me bang hard to my head!

To end this philosophical transitions for now,  I pulled this blog post from draft and rephrased the above section a bit after responding to Shrini Kularni's LinkedIn post.  The link to LinkedIn post is in the comment.  I see, Shrini is right in his interpretation and the from perspective he is talking.

I know, I have sounded with not the common philosophical interpretation.  It makes relevant to me in my imagination, interpretation, visualization and modeling.

Every code has a script within it -- a set of instructions to do a task.  How I see the code and the scripts within the code is my imagination.  If there are scripts within a code, then the code is a script in a way -- the script with capability of language used to build a resilient software system and to automate a business's services and tasks. 

Will I use the word script or code?  That depends on vocabulary, understanding and interpretation of people with whom I'm communicating.  I prefer code.  

If you are in between the debate and thinking of code or script, then, how this sound -- the code in the script file or the script code.

The Awareness Words On Growth And Promotion

 

I wish, I had seniors who said me about growth and promotions when I began my software testing career.  Could be my seniors did not know how important it is to share this with juniors who have started their career.  

Nevertheless, I want to share it here.  So that, it can be the words of awareness.  

These words of awareness related to promotions and growth is not limited to below sharing.  It is more and beyond.

The below are quick reminders to myself.  It can serve you as well.

• The good work delivered does not mean good money and benefits.
• The promotion and growth is not all about the good work done and delivered.
• It is about my identity, professional identity, visibility, communication, persuasion, influencing, the kind of problems I'm solving, the value and money I bring to the business.
• Me skilled in the tech stacks and capable to build, test and deliver is not the only priority factors for the growth, promotion and benefits, each time.
• The 1:1's and meeting with stakeholders should have a goal and way to evaluate the same periodically and consistently.
• It should be quantifiable and visible in the business.
• A manager's job is not to worry about my growth and promotions.
• A manager's job is to ensure the delivery is going good and meeting the business goals.
• A manager's job is to solve and enable the business on priority, most of the times.
• A manager can be of help in my growth and promotion to a certain role maybe until the senior engineer role.
• Beyond that, it is me and how I'm seen by my peers for what I'm and what I do.
• A manager is not responsible for my learning and upskilling.
• It is my responsibility and accountability.
• The manager might forget me after a release.
• She or he will remember me
• When I'm needed in the meeting.
• When a data is needed from me.
• When someone else need data of me.
• It is me who has to keep the manager engaged with my value and impacts delivered.
• The data has to be presented.
• The data should be quantifiable.
• The one whose work bring money to business and the one who sits in the role for making decisions that brings money to business, get identified and promoted usually.
• In other way, how close is my work to bring the money and impact to business and its growth?
• This is a preliminary equation which one has to have and solve before going to ask promotion, growth and benefits in a business place.
• How to keep myself here while I deliver an excellent work and value to the business?
• If you see, in a way this is politics.
• The office politics is not bad!  Everything runs on politics.
• It is the people and management dynamics, and that is how a system functions inherently.  This is my observation and interpretation.
• One should be able to play her or his role in the office politics.
• If ignored or keeping oneself away from the office politics, it projects one as muted with a label tagged -- he or she can be updated later and the job will get done and no need to be here.
• One's office politics is her or his identity, visibility, positioning and influencing

The manager is in the organization not to promote her or his team members.

• But, to ensure the business goals are being met.  
• Taking care of her or his team members in a defined scope is one of the responsibilities for a manager; it is not the only responsibility and not the number one priority responsibility.

Business goals do not have my promotions and growth as their priority goals.  It should be my goals.

Yet, the managers go and fight in a closed room for her or his team members growth, hike and promotion until a role.  You see, not all get promoted in a cycle.  That challenging is the advocacy in that closed room, tables and meetings for the managers.  Give the quantified data to your manager.

Underestimating self and letting that to be used by others in the floor can be lethal to the growth.  

To end here, my growth, hike, promotion and the benefits I need to get is my advocacy and visibility for first.  The manager and peers can be a catalyst here.

What Test Engineers Forgot By Saying "Out Of The Box"?

When I started my testing career, I read the lines which said, think Out of the Box.  My then manager said the team to think and work, out of the box.  

I see testers practicing, working, testing and automating by saying, out of the box.

Wait! When said boxes, what comes to one's mind is Black Box, White Box and Grey Box.  But, I tell you, there exists no such boxes.  These boxes are imaginary; it was termed probably to give an analogy, to see and know the ways to test the product's code and infrastructure.

I do not tie myself to these imaginary boxes, but, it is a useful analogy.  After all, when said Out of the Box, which box are we referring to?

And, what is that I'm missing by saying and doing out of the box?

What Have we Forgotten?

While me talking and saying *out of the box*, I'm not letting myself to think Inside The Box, for first.

If I cannot know what is *inside the box*, how will I know what is outside the box?

If I cannot see, think and explore for what is *inside the box*, how will I know what is outside the box?

I see, we have forgotten "Inside The Box" by saying and hearing "Out of The Box" for decades.

What's inside the box which you are testing?  Does it have just functionality, though the functionality is the heart beat of a system?  Okay, have I explored the functionality in all possible dimensions?

Almost everything in the box is associated with functionality.

When I'm not said to test for what is inside the box, I will be lost with Out of The Box.  Do you?

If I explore Inside The Box, fore sure, it will help me to go beyond functionality.  What all I can do inside the box?  What all I can evaluate inside the box and how?  That is, I think of performance, security, usability, observability, traceability, monitoring, and you label next.  All these are associated directly with the functionality.

All the boxes in software testing are imaginary.
We have forgot to see and explore Inside the Box.

Inside the Box, helps you to identify and observe,

• Why these exists?
• Why these are interconnected?
• How these are interconnected?
• How are they communicating?
• What are they communicating?
• To whom they are communicating?
• When are they communicating?
• When they fail to communicate?
• How fast and reliably they can communicate?
• The programming, code, protocols, tech stacks, libraries, money, ports, cables, people, etc.
• What they are holding and where, how and why, when?
• And, more ...

As you go Inside the Box, this space grows in multi dimension.  You will realize what is out of the box and what is inside the box.  You will consistently tune yourself to fit in any imaginary boxes with your tests.  From there on, you will explore, test, automate and talk to all the imaginary boxes and system[s] you are interacting with.

If I cannot see what is within, how can I see what is outside?

The Reality, Pain, and Cost

This is my observation.

• When I ignore Inside the Box, I will continue to talk with more focus on vocabulary, terminologies, schools, process, advocating on one aspect of the discipline and think this is craft and craftsmanship.  
• I will be stuck here and pass on the same to upcoming generation of software test engineers and practice.  
• This is the reality and painful part. 

Is talking and working on vocabulary, terminologies, schools, craft, craftsmanship and advocating that one aspect is testing, wrong?  

• No, it is not wrong.  
• But getting lost here indefinitely is beyond wrong.  
• The cost of this is huge to the craft as a practice and to the software test engineering discipline.
• As a result, the upcoming test engineers and generation will pick whose voice, approach and content is more opted.
• If observed, this is not the case with programming and programmers.
• I see, the programmers challenge most times and everyone who pushes or sells the thoughts. 
• Why? I see, they are trying to learn and understand from inside the box for first.

Unfortunately the smart people who are with role and title of influencers, thought leaders, keynote speakers, seniors, directors, VPs, ambassadors, and advocators of a thought and schools are lost here.  My question to them and me is, why not we explore Inside the Box?  Why just confined for propagating the philosophies and one's ideas alone ignoring what is Inside the Box?  The philosophy is a need; I do not say we should not ignore it.  Philosophy alone do not pay one's bills and fill the stomachs.  I wish, I had learned this lesson in the start of my career.  The business is a philosophy by itself and it will make use of or ignore any other philosophies as and when needed.  I hope and wish, the test engineers will interpret this.

I see this is one of the key reasons why the software testing as a discipline and practice we did not gain the recognition and importance as programming the product and solution.  Though we work closely with the product code and the test code, we miss our craft and names being called out.  This is reality and painful.

To end here, if I'm not seeing and thinking for what is Inside the Box, how will I excel in Out of the Box?

There Is No Flaky Test! Then, What Is Flaky?

In general, I understand, the flake means brittle and inconsistent or uneven.  Like the flakes one will have as food.

I'm not a native English.  It took me years to understand and correlate between the words 'flake' and 'flakiness'.

Test and Flakiness

There are no Flaky Tests.  A test is not flaky anytime.

The responses of a system to a test can be flaky.  That is, the response is not deterministic and inconsistent to one's expectation and understanding.  

In other words, the responses of the system is unreliable to the same action, data, state and other parameters.

This is not a philosophy of testing or test.  In my opinion, it is a misunderstanding that is accepted and passed on in the software engineering.

A test is not flaky; the response of a system is flaky.

Are there no flakiness when testing for services?  It exists!  That is, the inconsistent behavior of a service for the same set of data, state and other parameters. What is inconsistent in context of a service's response?

Flakiness is not bounded to just GUI  It can be with any UI [User Interface].  And, an API is an another user interface which opens up to the bunch of services.

To end, 

• It is not Flaky Test.
• It is a flaky response of a system which a test is letting you and me to experience.
• What is a flakiness to one who is testing for security and performance?
• Flakiness is not confined to the UI response or a functional response of a system.

You decide how you should be seeing a test in your suite and label the response of the system you are testing.