If, For and While

"That's not my job"

noreply@blogger.com (Keith Franklin) — Wed, 16 Sep 2020 17:56:00 +0000

As an individual, I am a person always looking to change things quickly. The mundanity of repeating the same things over and over again gets me agitated to question the efficiency of the activity. With this naive outlook, and fueled by Pink Floyd's album "Welcome to the machine" I am trying to write this blog post about the changes I've seen. Over the years I've seen some changes that happen in an organization and this blog is more of a commentary on the things that I've seen. Without question, this blogpost has a major TL;DR warning.

Life in a corporate office might seem a little kafkaesque. Kafkaesque, A term associated with Frans Kafka generally is used to describe unnecessarily complicated and frustrating experiences, like being forced to navigate labyrinths of bureaucracy. The sort of complex, unclear processes in which no one individual ever really has a comprehensive grasp of the system or what is going on.

In massive companies that are well established, they are driven by SOP's - Standard operating procedure - after SOP. These companies are so entrenched in bureaucracy it takes eons before a decision is even taken. In my opinion, this is the main reason these companies lookout for vendors to get the job done, with the other factor of cost. With vendors, we get a rapid disruption of the process that existed. Usually, the vendors turn out to be smaller organizations with fewer levels of approvals. But this also acts like a self-terminating loop, as these smaller organizations are also subjected to growth with the amount of time they are in the market. As they grow they bring in multiple layers to the organization constantly sifting through every decision.

Bureaucracy is not all bad, if done right it creates a strong structure that ushers in a sense of equality among everyone involved in the system. It adds predictability, with the right set of checks and balances we can control the outcome of the process, as humanly possible at least. with all the roles and responsibilities defined we get a centralized power dynamic in the organization, we also get a well-defined chain of command.

The key thing with all the red tape is that if it is not done right it adversely affects the motive with which it was put in place. generally, the SOP that was put in place may be too regressive and there is a high chance that the process might have worked in the past but with time being as volatile as it is the process might just be too outdated. With drawn-out SOP it creates an ecosystem that suffocates creative minds. For creative minds to thrive they need a liberalistic atmosphere.

Compartmentalization is a common path taken to create scalability in terms of decision making and the structuring of organizations. In the blog Break Through Your Mental Bureaucracy - Ron Ashkenas talks about how compartmentalization is a form of “mental bureaucracy”. Companies compartmentalize into blocks and predominantly the blocks used are segmented into marketing, development, HR, and finance.

With a compartmentalized work environment, the teams involved start to have a diminished outlook on the deliverables and often have a game of finger-pointing with block constantly resonating the statement " that is not part of my job". Different blocks are only concerned about their own propositions and as an outcome, nobody takes a decision when it does not concern their base. Teams oftentimes don't see the big picture as they are more focused on their own activities laid out by their respective blocks. It becomes an organization defined only by the KPI's they have to complete.

In closing, I've observed creativity always takes a blow when we try to bring in a set of rules. Creativity is essential for human beings let alone organization, for without creativity we would all just be doing the same boring thing. A good explanation of creativity is, "everyone knows the rules to a game, let's say like

football. It is creativity that gives you the Kompany or David silva of the game. If they all had just followed the rules and not been creative we would've had a boring game to watch". The same applies to corporate lifestyles, if everyone in the organization is trying to stick to their own objectives and not look at the larger view of the organization the extent of growth becomes non-existent.

Murmuration: A view into Artificial life.

noreply@blogger.com (Keith Franklin) — Fri, 14 Aug 2020 21:13:00 +0000

Murmuration refers to the phenomenon that results when hundreds, sometimes thousands, of starlights(starlings) fly in swooping, intricately coordinated patterns through the sky. My introduction to the word, murmuration, was by the Jazz trio, GoGo penguins. Murmuration is the 5th piece they perform in one of their live performances: link. It is one of the most enthralling pieces of music I've heard. I implore you to check them out: https://gogopenguin.bandcamp.com/.

When we observe these starlings fly we see a pattern that stands out. And when there's a pattern involved there is a strong possibility an algorithm exists to explain it and implement a computer simulation which helps me to segue into Boids algorithm.

Boids algorithm is an artificial life program, developed by Craig Reynolds. It simulates the flocking behavior of birds. Boid is a shortened version of Bird-oid, which refers to the bird-like object. Boids are an example of emergent behavior,i.e. the algorithm works because individual agents stick to a set of simple rules. Boids are driven by three rules.

Separation: fly away to avoid a collision.
Alignment: steer toward the average heading of nearest boids.
Cohesion: move toward the average position of the nearest boids.

Boids algorithm has a vague similarity to human behavior as well. Gustave Le Bon, in his book "The Crowd: A study of the popular mind" explains crowd psychology and why people behave differently in groups. In the book, Le Bon highlights three causes as to why an individual behaves differently when they are a part of a crowd in contrast to when they are alone. These three causalities are:

Anonymity: An individual loses the fear of the consequences, they lose their moral responsibility, temporarily feeling invincible. This is a major operator in the behavioral understanding of mobs.
Contagion: In a crowd, Le Bon believed that every act is contagious. When we look at the dot com(.com) bubble or any major financial crisis, everyone that was part of the system was lead to buy something just because someone else was buying. The idea that buying or investing in a dot com venture was valuable was promoted as a contagion and not as an analytical understanding of the markets.
Suggestibility: Individuals enter into a hypnotic state of mind mesmerized by a charismatic leader.

Herd mentality and mob mentality are observation of social psychology that mirror properties of the boids algorithm of working as a collective. The psychological study explores the idea that people can be influenced by their peers to adopt certain behavioral traits. As humans, we default to thinking that a collective might know something that as individuals we wouldn't know. Mob mentality might give away negative connotations to the idea of a collective but it is not all bad, there is a possibility of collective intelligence - something that stokes collaborations and collective effort. A great example of collaborative effort is the open-source software ecosystem.

The parallels between human behavior and the Boids algorithm give us an insight into how life-like boids algorithm is. By observing the patterns of a murmuration we have created an artificial life simulation, with autonomous entities that behave independently conforming to certain rules.

In times of uncertainity we always default to a collective.

------------------------------------------------------------------------------------------------------------

The Code.

When I took a stab at the algorithm, I wanted to give complete autonomy to the boids by providing or simulating awareness of each boid to their surroundings. I didn't want to explore unsupervised learning to create the simulation, I think it would be an overkill. If I can create a truly autonomous boid then I can go a little further and introduce some cognitive dissonance, that's the plan at least.

Link to Code: https://github.com/Keith3895/boids-js

link to the demo: https://keith3895.github.io/boids-js/

The Dawn of programers

noreply@blogger.com (Keith Franklin) — Wed, 29 Jul 2020 13:15:00 +0000

A programmer, also most associated with their new moniker a coder, is a person who writes or creates computer software. The definition of the word code is " a system of words, letters, figures or symbols used to represent others especially for the purpose of secrecy". It is fascinating how programming came to be associated with this word, "code".

In 1936, Alan Turing first describe a simple abstraction of a computational device. In 1940, "The Bombe", an electro-mechanical device was used to decipher the German Enigma-machine. In 1945, Turing went on and envisioned that

We shall need a great number mathematician of ability.

because

there will be probabliy be a good deal of work of this kind to be done.

With the evolution of technology, we moved on from electro-magnets to punch cards to transistors. In 1971, Dennis Ritchie and Ken Thompson at bell labs came up with a new programming language 'C', and a new operating system UNIX. There were a whole bunch of programming languages that I've skipped but 'C' changed the programming world. UNIX was the origin story for many of the operating systems we have today- Linux, Mac OS, Android, all these operating systems are based on the principles and architecture of UNIX. Around the same time, we had Apple and Steve Jobs disrupting and innovating in a primarily mainframe market then. Apple also is known to bring in designs and innovations that shape the market. They did it with the macintosh and most recently with the iPhone, creating a new market of application development.

We are in an age where companies are transitioning and trying to cater to this new consumer market. CIO's of these companies are driving "digital transformation" initiatives backed with massive budgets. This has given an inroad to Application development platforms. Before going into development platforms lets understand the actual origins of the application development platform.

Every industry has tools for their trade. The construction industry tools had rudimentary tools before they moved to power tools. Similarly, in computers, the code was written or rather punched on to punched cards, and then they moved onto text editors. With Graphical User Interfaces(GUI) improving, Integrated Development Environment (IDE) was introduced to help developers to keep all their resources organized, debug, and run their programs from a single tool. Application Development platforms are an extension of IDE's. As the name aptly conveys, the application development platform is a computer program that helps in developing software/applications on different devices.

Application Development Platform has a massive ecosystem of its own. In this ecosystem, we have Low-code development platforms or even No-code development platform. A Low-code development platform is a software that facilitates application development with a GUI implementation of a drag and drop user experience and this is a shift from the traditional hand-coded approach to development. In the eco-system, thanks to aggressive marketing, we have Buzz words just floating around. they are basically the same thing just a fancy way of saying the same thing. some of these buzzwords are - HPAPAAS, MXDP, RAD also LCDP(Low-code development platforms), and NCDP(No-code development platform).

If you also share the same expression as the meme, fret not, we will talk about these outlandish abbreviations. HPAPAAS, High productivity application development platform as a service, is an Enterprise Application Development Platform that has a delivery and deployment mechanism like LCDP but not the same. It is also provisioned as a service. (you can read about HPA-PAAS at this link: https://www.neutrinos.co/what-is-hpapaas/)(you can also check out my post about *AAS explained). MXDP, Multi-Experience Development Platform, is a platform that encapsulates - design, development testing, managing, and analyzing. At least that is what Gartner has to say about MXDP. Personally, I think its another marketing ploy to sell an Application Development Platform.

Over the past few decades, we've seen technology evolve and the demands for programmers grow. A field originally intended and designed by mathematicians is now open to diverse demography. The Idea of a citizen developer just extends the scope a little more. A citizen developer is a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT. When we look at the strides statistical learning and artificial intelligence is taking there is a lot of positive development to come. The bottom line is that The need for individuals to know "coding" will keep growing.

Understanding TDD - Part 2 - Adopting TDD

noreply@blogger.com (Keith Franklin) — Mon, 20 Jul 2020 14:42:00 +0000

In part 1 of this series, we explored the fundamentals of Test Driven Development. After wrapping our heads around the principles and understanding the origins of TDD we will now look into applying TDD.

Understanding TDD - Part 1 - "What is TDD?"

Adoption of TDD.

Test-Drive Development is effective and it works. There’s a catch though. Not all teams can jump right into it and start following the processes defined by Test-Drive Development(TDD). It is not easy to Convert your teams working in traditional programming processes trying to figure out the arcane code they have written. The challenge doesn’t just stop at the teams, convincing management about the change in approach in application development is another hurdle all by itself. Understanding Test-Driven Development is not the same as Integration testing is paramount to the adoption of Test-Driven Development (TDD).

Every time you talk to a team-lead they will usually bring up the point that they are already in the middle of their development it is an impossible task for them to just jump ship and start practicing TDD. The change isn’t about shifting to a Test-driven approach right away. The team can always start to write tests and run the tests manually if the team doesn’t have the privilege or the capacity to automate the tests. By defining and running tests manually the team could still cover their bases in terms of unit testing their code.

When you talk to a traditional developer or an uninitiated in the ways of TDD, they will question you about “why they should make the shift?”, “Why worry about the overhead?”. The most direct approach to answer the question is to show how TDD visibly improves the quality and the standard of code.

The Challenge

A majority of software or application development is done to cater to a competitive market. Execs invariably promise a short timeline, to compete with the other players in their specific domains. This thought process metastasizes and the development teams have tunnel vision to deliver products, applications in our case, as fast as possible. The teams focus on a speedy approach to maintain the status quo always corrupts the process and always leads to jugaads(Hacks) as productionable solutions.

Another challenge is the mindset of the development team. Traditional developers have to adopt a completely different approach to what they were used to. The code that is written with the traditional approach in mind is most often not testable. This is why teams don't test their code.

Change is hard because people overestimate the value of what they have and underestimate the value of what they may gain by giving that up. – James Belasco and Ralph Stayer.

The Change

It might seem like Converting the team to adopt TDD is never going to happen… It can, but change takes time. Certain prerequisites need to be fulfilled to make it to the finish line.

The proverbial first step would be to cleanse yourself of all sin! Get the team to start writing CLEAN CODE. It might seem like it’s a rudimentary part of the development process. But still, a majority of developers don’t focus on writing clean code. With clean code, we must focus on the code to be testable. Initially, this is going to be difficult but getting the team to make code testable would be a major milestone. In the JavaScript ecosystem, a linting tool will be a good place to start from a source code management point of view.

The Focus Should be on writing good test cases first instead of prioritizing on the CI/CD aspects or the automation aspects of the application design. Most team leads try to focus on getting a 100% score on their code coverage. A 100% score does not warrant that the test cases have covered all the possible positive and negative unit test scenarios.

Familiarizing the team with the testing framework that is going to be used. Almost all testing frameworks have the same core concepts of:

Assertions
Expects (expectations)
“describe” and “it” keywords.

Getting the team to be well versed in the testing frameworks helps in honing the skills of the developer to think more on the lines of automating test cases.

When transforming the development team to start TDD it would be wise to start with pair programming. When developers work in pairs it adds to new perspectives into how to write quality tests. One approach to getting your team to practice TDD more efficiently is to covert/train one developer at a time. Yes, it will be time-consuming. Yes, it would stretch the timeline of switching completely to TDD. You could speed the process up like a chain reaction but you will have to start with a handful of developers first. You would have to ‘indoctrinate’ the developers one at a time. the virtue Patient is key!

The Pursuit Of Clean Code

noreply@blogger.com (Keith Franklin) — Mon, 13 Jul 2020 14:15:00 +0000

There are different ways to interpret the meaning of clean code. The idea of clean code is a subjective concept and every developer has their own interpretation of it.

Clean code is code that is easy to understand and easy to change"

When we say "easy to understand" what does it really translate to? Easy to understand can be easy to read, it can be easy to understand the flow of the code, easy to understand sequence events. Easy to understand can also quantify to the ease to understand the purpose and function of the methods and variables defined or declared. Easy to change can be interpreted as easy to extend and refactor, and it is easy to fix bugs. Easy to understand can be anything! it's up to the readers interpretation.

When we write code it is generally in as higher-order language. This implies that we intend the code to be understood by other developers or other people. A higher-level language is not directly interpreted by the computer. A high-level language is compiled or interpreted into an assembly level language or a binary. The reason high-level languages exist is that they are easier to read, write, and maintain.

Programming is the art of telling another human what one wants the computer to do.

- Donald Knuth

Clean code is not just writing code that is good or easy on the eye. Efficiency in the execution of the code is also a vital aspect of composing clean code. Efficiency can be correlated to the time it takes to execute a block of code. an example of bad and inefficient code would be:

function IsNumeric(sText) {
    var ValidChars = "0123456789.";
    var IsNumber = true;
    var Char;
    for (i = 0; i < sText.length && IsNumber == true; i++) {
        Char = sText.charAt(i);
        if (ValidChars.indexOf(Char) == -1) {
            IsNumber = false;
        }
    }
    return IsNumber;
}

This can be written with a simple implementation of isNAN().

Over the past few years, I have made some observations that guided me in the path to writing clean legible code.

Rules for naming

select descriptive and unambiguous names.

use pronounceable names.

Magic numbers.

use the correct case.

camel case

snake case

kabab case

pascal case.. and many more.
Each type of casing of text implies a specific meaning to the code.

Function rules

keep the functions small.

do one thing and one thing only!

verbs as function names. Because functions always perform an action it makes sense to name them with verbs.

Comments Rule

don't add obvious comments.

try to express your intent in the comments. don't explain unrelated facts about the requirement.

use comments to highlight warnings.

try to express yourself in code and not in comments. Most programming languages are high-level languages, meant for humans to understand.

So Why do we strive to write clean code? cant we just go with code that just works? there are many reasons for writing clean code:

Easier onboarding of team members. If you are working with rotating teams, a common outcome for most development teams within the pandemic. It is best if it takes less time to onboard new team members.

Easier debugging. When it is easy to read and understand the codebase it is easy to pinpoint the segment of the code where the error or bug is occurring.

better utilization of developer's time. The developer reading the code is not trying to figure out how the code works but is either implementing new features or refactoring the code.

Another aspect that comes up every time there is a discussion of clean/bad code is complexity. The causes of complexity are not always directly attributed to bad code, in much the same way that bad code is not always the direct result of bad or even poorly skilled developers. even senior developers write complex, difficult to understand code. Many believe that complexity is caused by two things: Dependencies and lack of clarity.

Dependencies can be both external modules/packages and developers who wrote some parts of code. If there is an excessive dependency on an external module the team is forced to write code as dictated by that module.

the other form of dependency is what I call "Key Person dependency". This is when there is an over-reliance on one developer to write and maintain most parts of the codebase. Both forms of dependencies are caused by a given piece of code that cannot be understood and modified in isolation: the code relates in some way to other code and the other code must be considered and/or modified if the given code is changed.

The bottom line is that writing clean code has visible benefits. It improves the standard of code which directly affects the maintainability of the software or applications. The complexity of a codebase is heavily driven by dependencies and incremental changes, both in the team and in features. The development teams must spend quality time to write clean code. At its core, clean code is about eliminating complexities and improving the readability of the codebase.

conway's game of life. - code

noreply@blogger.com (Keith Franklin) — Tue, 07 Jul 2020 14:45:00 +0000

Rules of the Game:

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbors, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

Any live cell with fewer than two live neighbors dies as if caused by under-population.
Any live cell with two or three live neighbors lives on to the next generation.
Any live cell with more than three live neighbors dies, as if by overcrowding.
Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.

The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.

We start by creating a HTML boiler plate with an empty canvas in the the body tag.
after the html we add a script tag and initialize the canvas and some global variables along with some utility fucntions.:
Next, we creat a Class which is representative of a cell in the universe of the game.
We define a draw member function to draw a grid of a cell. We will also define a fill member function which will add a fill to the grid to signify a live cell. Other member variables would be the position and dimensions of the cell.

we will define a method to draw the universe:
we will define a pure function to apply the rules of the game and a method to calculate the next generation.
You will notice in the pure function there is a line lifeCount = lifeCount > 0 ? lifeCount - 1 : 0; we reduce the count because the calculation is inclusive of the current cell.

to close the development on the game we'll add some event handlers to make the game a little interactive:
and then you will have the final result: https://keith3895.github.io/conways-game-of-life/index.html

the code is on github: https://github.com/Keith3895/conways-game-of-life/blob/master/

Understanding TDD - Part 1 - “What is TDD?”

noreply@blogger.com (Keith Franklin) — Wed, 01 Jul 2020 03:30:00 +0000

Understanding TDD

This post is written with the intent to help understand the concepts around TDD and help in the adaptation of the TDD approach in the development process. The intended targets are developers, Team leads, and managers. The idea behind creating this was to explain the background of TDD. This first part covers the origins of TDD and the basic principles that define development with TDD.

-------------------------------------------------------------------------------------------------------------------------------------------------------------

What is TDD?

Test-driven Development abbreviated to TDD, is an Approach to problem-solving or application/software development when unit tests are written prior to writing code. Before jumping in headfirst into Test-driven Development (TDD) let’s look back at the background of how TDD came to be.

History of TDD

"Generally, the modern “rediscovery” of TDD is attributed to Kent Beck, who is also known as the creator of Extreme Programming. Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software and higher quality of life for the development team." The general characteristics of Extreme Programming (XP) described in extreme programming are.

Extreme Programming (XP) was created in response to problem domains whose requirements change.
XP is set up for small groups of programmers.
The XP team includes not only the developers but the managers and customers as well, all working together elbow to elbow.
Another requirement is testability. You must be able to create automated unit and functional tests.
The last thing on the list is productivity.

XP gave a broad framework on which TDD would become a Development practice used to drive quality code.

The Agile Mindset of development teams.

The Agile Manifesto is tantamount to a “declaration of independence” for Agile Software development. Many offshoots the agile system are extreme programming, scrum, pair programming, refactoring, and many more. The agile manifesto is also important in the development of TDD as many of the principles of the manifesto are key drivers in TDD. Some of the direct correlations of the principles are:

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”. As we write Tests for every block of code any faults to any specific part of the software will be flagged.
“Working software is the primary measure of progress.”
“Simplicity--the art of maximizing the amount of work not done--is essential.”. To facilitate testable blocks the code is designed to be simple.

Let's Look at The Traditional Process

Traditional development process.

The traditional development standard follows a broken process that is meant to fail over the long run. The major flaw in the traditional process is when a new change is brought in, it can be in the form of a bug-fix or a feature enhancement there is bound to be a change in the pre-existing code. Factoring in the human element of the developer, gaps in the unit testing can arise due to human error. This brings us to the infamous statement: “Fixing one bug causes (N) new bugs”. This constant back and forth between the different members of the team cause the team to question their own competence and approaches to problem-solving, negatively affecting the team's morale.

The TDD Process

The General flow chart of the TDD process is:

TDD Process

Derek Barber, in his blog, defines the TDD process/cycle to have 4 main steps:

Write a test
Make it run.
Change the code to make it right i.e. Refactor.
Repeat process.

In TDD, a test is added and tested with the code produced. The code is reworked until all the tests are passed. Additional features are added one by one in an incremental process. Additional tests are added to the testbed as and when needed. In the traditional way, all the implementation is completed and then test cases are designed. The code is run through all the tests and is reworked until desired functionality is achieved.

Some clarifications about TDD:

TDD is neither about "Testing" nor about "Design". It is a development process. the focus is on developing good quality and clean code.
TDD does not mean "write some of the tests, then build a system that passes the tests.” The idea is to write tests that quantify the action the block of code is intended to do.
TDD does not mean "do lots of Testing." TDD is heavily reliant on good test cases (quality) and not on the number of test cases(quantity).

TDD is a process about Development. It is about writing quality unit tests that guarantee the quality of the code that is being tested. The purpose of the entire development process is to reduce the manual overhead of rechecking everything. In subsequent posts, we'll look at some of the hurdles to adopting TDD as a process.