Protocol oriented programming

Protocol oriented programming(POP) is a paradigm that has come into the limelight with the advent of Swift. Different languages over different periods have had some flavor of POP in them, but there are some traits unique in the POP central to Swift, which gives them a measurable advantage over OOP. That is not to say that OOP is flawed and or POP is the knight in the shining armor. POP simply extends OOP with a few new additions that help in writing better code ergo, better systems

Contents

a. Existing system example

b. Problem with Inheritance

c. Enter protocols

d. Protocol Extensions

e. Protocols & Value types

---

1. Existing system example

Let’s take a simple example to see how OOP and POP work on the same problem. Consider that we are contracted to build a vehicle that can be driven. The requirement is we will be asked to build many vehicles that will have different colors, number of wheels, different engine capacity, etc. Coming from the OOP world, the core of the solution would be something like this

Everything works fine. SmallCar, RaceCar both can be driven. They also can have their unique traits.(noOfSeats(), nitroBoosterCapacity() etc). No paradigm maps the real world as efficiently as OOP, and hence we can apply principles of real-world like inheritance in object modeling. That’s the beauty of it.

However, the real world is far from perfect, and that seeps into its derivative like OOP. Consider the same example above. The customer has now contracted you to build the ability to have wipers for the existing category of vehicles. So now Vehicle can be modified to have the ability to wipe

Courtesy, inheritance, all the categories of vehicles created hitherto can wipe its screen. RaceCar or SmallCar can simply call wipe() and startDriving() safely in the rains! The customer is now happy and since you are so awesome in building systems he now asks for introducing a new class of vehicle, A two-wheeler known as a motorcycle. The first reaction would be to subclass Motorcycle from Vehicle. In this case, Vehicle would not be useful. Why? Semantically a motorcycle is a vehicle so we should be able to use the Vehicle class. But the problem is if a Motorcycle inherits from Vehicle it would also inherit the ability to wipe(). Needless and absurd as well! So if we don’t extend Motorcycle from Vehicle, all the complex logic and business rules which are available through Vehicle namely in startDriving() will not be available to a Motorcycle. We could simply argue that ignore the ability to wipe() in a Motorcycle, but that’s knowingly introducing an association in the system which is not required. So what’s wrong with our design?

OOPs, OOP has done it again!

A subclass may not need all the features from its parent class. A child who has a rich, alcoholic father will happily choose to inherit his wealth but would keep his distance from his father's drinking vice(hopefully!). Similarly, a subclass may not require all the traits of its superclass. Since most of the languages do not support multiple inheritances we cannot break the superclass features into multiple smaller classes and have the subclasses inherit from the required ones.

OOP does not do a great job when it comes to this.

2. Problem with Inheritance

Inheritance is a great mechanism to reuse code and build software, but it is not particularly great when it comes to a selective association. The class that gets inherited is imbibed in the DNA of the subclass whether it likes it or not. It’s like a mobile data plan which comes with a host of great features that you are interested in but also with a few meh! features which you would have rather not wanted if sold individually. But since it’s part of the package you can’t escape it.

3. Enter protocols

Protocols have been in existence since OOP itself and it offers another way of designing and modeling classes. Let’s consider the above example of vehicles and how we could design the same using protocols

As we can see, with protocols we have been able to break the dependency enforced by Inheritance on the class Motorcycle when it inherited Vehicle. Now any new category of Vehicle which does not require wipers won’t be burdened with the same. It simply does not conform to it. Don’t need it, don’t ask for it and so not burdened with it! For e.g. a scooter. The protocol used in Swift generally is implemented as an abstraction (virtual class, interface so on and so forth) in many other languages. Nothing really new there. Readers would have noticed here that the need to define the logic of driving is now on the concrete class which implements Vehicle i.e both RaceCar and SmallCar now has to define how to startDriving(). This can lead to the repetition of code and logic. Besides if protocols have been available in many other languages what’s so special about POP in Swift? The answer is Protocol extensions.

4. Protocol Extensions

The cornerstone for POP is protocol extension. Swift (v2.0 onwards) allows a protocol to have a generic behavior that can be overridden as well. This generic behavior allows every implementation to “inherit” this by default. If they don’t like the generic behavior, well, simple, change it i.e., override it.

For e.g. the above example can now be written as

This is exactly like inheritance with the extra association of startWiper() now broken down to a need basis. Every implementation of Vehicle now has the complex startDriving() logic available by default i.e it has “inherited” the same from the protocol. Plus motorcycle does not have any association with Wipers. Thus protocol extensions help implementation to have the ability to “inherit” from a protocol and keep the dependency to an atomic level. i.e A protocol should contain only those contracts which an implementation or concrete object has to implement. Otherwise, it exhibits a fat interface problem. For e.g., Vehicle was a fat interface because it contained startWiper() which was not required for all subclasses.

5. Protocols & Value types

Swift advocates using value types over reference types wherever applicable. The use cases, benefits of both are well documented and won’t be covered here in this post. Value types like struct, enum can extend Protocols as well thus extending the benefits of designing using Protocols to even value types. This is one of the main reasons why Apple evangelizes using protocols over classes.

Bottom Line

POP extends OOP to provide another level of abstraction which helps a developer to write better code and design reusable components. Everything has its place under the sun and OOP is certainly not to be totally replaced with POP. Only where required. The decision to use POP or OOP can be context-specific

6 point design guide for Generation Z

The current generation or demography is known by many names iGeneration, Gen Wii, etc. In mainstream media, they are widely known as Generation Z, the one following Gen Y(surprise!) or millennials. Like the demography which preceded Gen Z, i.e. Gen Y, Gen X, etc., Gen Z has its unique traits, preferences, likes and dislikes, and behavioral patterns.

The millennials(Gen Y) were the first to consume digital products the way we see them today. With the advent of the Internet, the millennials adapted to services, tastes, sharing, brands favored, buying preferences, etc over the Internet in a digital platform. Whether it be booking movie tickets, ordering lunch, filing taxes, etc. digitalization is how the millennials made their lives easier.

The behavior of Gen Z

For Gen Z, the digital world is what is.

But For Gen Z, the Internet & the digital world was not about making lives easier. The digital world and its products were not luxury. They were born into this digital world where the Internet was a necessity. Experimenting and expressing with social channels & the digital world is how Gen Z communicates. As opposed to the traditional model of sales like brick and mortar setup, mom and pop stores, this is a generation that prefers buying online and learning about brands online.

How does Gen Z deal with brands

All most all brands and businesses eventually had to migrate to this digital platform to stay relevant since the purchasing power and ability of this demography is staggering. The traditional methods for branding, advertising, and sales have entirely turned on its head in the digital world. The pace of change in the digital world is fast, and brands have to adapt to keep themselves competitive. Physical channels of sales are superseded by digital channels. Methods of advertisement like flyers, print, television are rejected over likes & comments & reviews & feedback by existing users over social media. A “like” which a friend gives to a product is worth more than a plastic smile driven endorsement by a Taylor Swift or a Justin Bieber.

According to consulting firm Altitude, this new generation will account for 40% of consumers by 2020.

How to design for Gen Z

Before Gen Z, technology was used in society, but it was never as imbibed in everyday life as it is today. Consumption of services and goods was predominantly through offline modes. But thanks to technology, things have changed.

• Constant information
• Fluid
• Engagement
• Content
• Honest, fact-filled stories
• Options

1. Constant information

Gen Zers have grown up with constant connectivity. This is a generation that knew “swiping,” pinching, “liking,” zooming before they could walk. They search online for information that they need rather than relying on someone or something be it for education, entertainment or anything. A brand that wants to be appealing to this generation needs to have a presence that serves information about itself to Gen Zers all the time. Patience is not a virtue for this generation since there are too many things vying to catch their attention over multiple mediums. If your brand can’t provide information about itself when they require it, you are history. Designers thus need to realize that constant availability of information is not a “good to have,” but rather a “prerequisite” for the Gen Zer's attention. Build a design that is accessible all the time.

2. Fluid

Gen Zers use social media to share thoughts, ideas, and views. Geographical distances, gender specifics, location-based preferences are no longer applicable when it comes to a Gen Zers lifestyle. What is vogue in one corner of the world, is also a must-have in another part of the world. Traditional preferences based on different parameters are irrelevant to this generation. Gen Zers identify themselves as fluid when it comes to favorites, identity, likes, and dislikes. Designers need to rethink traditional concepts of branding based on geography, gender, and other variables.

3. How to engage with Gen Z

Traditional forms of marketing, like print media, television are one way. A potential customer is informed via text, songs, stories, etc. about a product, and that’s it. The way a user places his trust in the product is by trying it and then rejecting or accepting it. With the Gen Zers, feedback for a brand is available for a potential user even before he/she uses the product thanks to social media and other online channels. A review by a family user is considered more useful than a superstar who endorses the brand. Hence the designers have to continually engage with the Gen Zer and get their feedback.

• What is it about this product they like?
• What can be made better?

What should be removed? How can this be shipped faster? It’s mandatory to engage the Gen Zer in all of this. This reinforces their trust in the brand.

4. Content

Since branding is primarily done on digital channels, pixel-perfect designs are a no brainer. Relevant content with bright, bold colors, designs, and icons that convey the brand’s purpose should be used. Slow, lagging, delayed experiences will be swiftly rejected. Mobile-specific content catering to different sizes and screens are a must as well. In this age of information overload, the content should be loud enough to call out Gen Zer's attention while maintaining relevance.

5. Honest, fact-filled stories

Inthis digital age, when nothing is hidden from anybody, and everything is available online, brands have to be authentic and honest. Gen Zers can immediately determine when they hear corporate lies. They value honesty and reliability over everything since they were born in an age of recession, religious turmoils, terrorism, fake news, etc. This makes them value authenticity and honesty and reliability. Brands and designers have to appeal to the Gen Zer with an unmasked front. Designers have to showcase real-world use cases to connect with the sentiments of Gen Zers.

6. Options

Spoil them for choice. Period. Globalization has indeed arrived. What is locally produced is available everywhere and vice versa. Gen Zers are sticklers for what they want and like, considering their propensity for stability. Hence if your brand does not give them multiple options, it will be rejected. Options catering to their fluid interests should be made available.

Parting shot

Gen Z, in short, is a digital generation. This generation seeks, disseminates, share, express, observe, objects, likes, dislike in the digital world. Designers have to rethink traditional values, methods, techniques of branding to fit into the mobile, tablet world which is the primary mode of consumption in the digital world.

What is a Serverless Architecture

Todefine serverless architecture (SA hereafter), consider what it’s not. SA does not mean the absence of physical infrastructure or machine. SA actually is a term that is from the Enterprises standpoint.

Putting up a backend infrastructure involves time and continuous maintenance. Setting up physical machines or virtual devices, installing applications, versioning, provisioning, scaling, load balancing, fail-safe mechanism, access restrictions..the list is endless. Backend as Service(BaaS) or cloud computing, in general, alleviates much of this task by doing the heavy lifting and hence, unsurprisingly, its popularity in software development. But there exists no silver bullet for any problem.

BaaS/Cloud comes with its own challenges. Imagine a service running on any popular BaaS platform which handles ’N’ number of requests every ’M’ minutes. Let’s assume this results in CPU usage of 5 %. With this rate if you compare the time the service is processing over a period of 24 hours, then a week, month and so on… the cost of usage is extremely inefficient. Enter Function as a Service(FaaS) or Serverless architectures.

FaaS or SA enables an Enterprise to run “on need basis” server components which are

• Ephemeral
• Stateless
• Auto scalable

1. Ephemeral

A Serverless Architecture essentially comprises of functions that run for a short duration and are triggered or invoked by an event either as a common HTTP request or time-bound (Timer). When such a request rises the FaaS platform kicks in, initializes (if not already) and the function is executed. Once the execution is done the system is closed till the next execution. Hence unlike conventional BaaS “always-on” setup, we have a “not always on” serverless architecture. Please note this process would vary from provider to provider

2. Stateless

SA is best suited for stateless executions. Since the server provisioning and infrastructure is now managed by the cloud provider, there is no guarantee that the state maintained by the previous invocation of the service will be retained. This does not mean that FaaS does not support stateful operations, but just states that any state needs to be handled outside of the FaaS instance. A very good example of a state full operation which is Serverless is uploading to S3 via AWS Lambda.

3. Autoscaling

The benefits of SA are huge when it comes to scaling. Horizontal scaling is automatic and handled by the underlying platform. If the incoming traffic is high on a particular point of time multiple instances of the FaaS is invoked. If there is a lull in the traffic the instances are automatically reduced. The platform even handles the underlying resource management and allocations

Implementation/Deployment

FaaS functions can be implemented across a wide variety of languages and they do not require coding to any specific framework or any library. For eg all major providers support languages like JS, Go, etc The code/function is written and is simply uploaded. With services like AWS lambda, the code can be written in the AWS console itself. There is zero configuration required. For small to mid-sized organizations like product startup, this is a significant thing

Pros

1. FaaS is extremely economical when compared to an existing cloud infrastructure as we saw in the earlier example. The cost of running a FaaS setup is simply based on how often and how long it’s used.
2. Since scaling is automatic and reliable, enterprises do not have to worry about the economy of provisioning new server instances or removing unused ones. Everything is provided by the service provider
3. With the economies of scale taken care of, enterprises or developers can focus on building better solutions. Moreover reduced costs enables enterprises to innovate and test newer products with shorter development cycles

Cons

1. FaaS is completely dependent on the service provider and hence issues on the providers end like an outage, downtime, maintenance, security will have a significant impact on the Enterprises service
2. Since FaaS is essentially a stateless server, the onus for maintaining the state falls on the client. This can result in repetition of logic and data across multiple clients
3. FaaS is essentially a temporal entity. Google Cloud Functions for example times out after one minute(can be extended also). AWS Lambda functions are for five minutes. Unlike an “always-on” instance of BaaS, FaaS run only for a short duration

Conclusion

Serverless architecture is simply a paradigm where the responsibility of setting up, scaling, provisioning server-side systems is delegated to another entity. It offers cost benefits, leaner development time which can have a cascading effect of benefits for an enterprise. At the same time, it simply cannot replace all the existing systems which are built on a different architecture model. What can be implemented as FaaS is context-dependent

Scrum vs Kanban

Scrum is a project management framework based on the principles of agile methodology (https://agilemanifesto.org/) which emphasizes small production cycles over short sprints of 2–3 weeks. Since its an agile methodology It also stresses on feedback-driven incremental changes incorporated throughout.

Scrum is widely used in the software development process, but the principles of scrum are industry agnostic. It can be applied to any process or domain or business vertical.

“Agility is principally about mindset, not practices.”
― Jim Highsmith, Agile Project Management: Creating Innovative Products

Backlog

At the heart of a scrum is a project backlog. A project backlog is a well-authored list of tasks generally known as “Stories.” Stories are measured, or story pointed with some metric. E.g., 1,3,5,8,13 or 5 hours, 10 hours. As a rule of thumb, a project backlog should have sufficient tasks/stories to last at least two sprints. A business analyst or product owner prepares project backlogs in close collaboration with the customer during a periodic event known as Sprint planning. Representatives from the engineering, designing, quality are also involved in providing inputs on feasibility, cost, and time factors.

Sprints

Sprints are the actual production cycle or development cycle. Usually, sprints run for 2 weeks. At the start of a sprint, the project manager/ product owner includes stories or tasks from the project backlog. The development/engineering team works on the same for the duration of the sprint. Teams determine beforehand what constitutes the completion of a task. Usually, a task is complete once it’s tested and verified by the QA or customer. The end of a sprint features a new addition to the state of the existing product. At the end of the sprint, the primary stakeholder reviews the product and gives feedback. This feedback is used as an input for the next set of backlogs. This iterative cycle of

planning->develop->test->review->planning

forms the backbone of the scrum framework. A project manager often doubles as a scrum master who conducts the day-to-day sprint meetings; known as a Standup.

Standup

Standups are conducted on a day to day basis and are strictly time-bound. The goal of standup is for the team members to give a status update on a day to day basis. Members give an update on

“What they did yesterday?”

“What they will do today?”

“What are the challenges for the same if any.”

As the name suggests, standups are conducted standing up to put the focus on short time frames for providing updates

Retrospective

Scrum encourages a team to be self-motivated and drives continuous improvement. A “Sprint retrospective” is held to deliberate on the work accomplished in the previous sprint. The focus is on learning from past mistakes, improve efficiency, and share findings, which helps the team to improve and increase productivity.

Kanban

“In the beginning, it’s advisable to focus on the flow of your work and the idea that your work actually has a “shape.”
― Jim Benson, Personal Kanban: Mapping Work | Navigating Life

Kanban is a project management framework based on the principles of agile methodology with particular focus on the visualization of production flows. Kanban aims to improve productivity and reduce delays in the value chain by continuous monitoring, feedback and reduced waiting across the workflow.

Like its famous cousin “Scrum,” Kanban can be used across any domain or workflow. Any existing workflow can be expressed or represented using the Kanban board. There is no need to modify a workflow to include Kanban. An elementary Kanban board can be created with three lanes; “Todo,” “In progress,” “Done.” Depending on the workflow, these lanes can be more or less.

Visualization

Kanban places emphasis on visualization of workflows. On the kanban board, a workflow or its derivative is expressed in a naturally flowing order from left to right. For e.g., In the software development process, the workflow would be expressed with lanes as such

||Backlog|| — ||Progress|| — ||For review|| — ||For test|| -||For deploy||

Each task is expressed with cards, or color-coordinated. For e.g., In-progress tasks are expressed with green stickers or green colors. In-review tasks are expressed in Red color or red stickers. The tasks are moved to the adjacent lane, once it’s completed. Unlike a sprint, Kanban is not time-bound. Once a task is completed, it’s simply removed from the board.

By visualizing a workflow in such a manner, teams can obtain vital information about the work output. Useful metrics regarding the time taken to complete a task, where is a task getting held up, what is the dependency of one task over the other can be easily found out.

Kanban was first designed for the production lines of Toyota with emphasis on unused inventory. The Kanban board gives instant clarity to the team if a task is sitting idle on a lane for a long time. To overcome this, Kanban allows setting a limit on the input such that tasks are not lying idle in a lane because of the unavailability of any resource. This is generally known as W-I-P limit (Work in progress)

Typical benefits of Agile development methodology

1. A clearer view of process flow which helps in identifying bottlenecks
2. Flexibility in execution by incorporating smaller incremental goals as opposed to a monolithic, one-time development
3. Focus on continuous delivery by producing a subset of working software which is added to the existing product
4. Better tracking of issues and tasks
5. Continuous feedback leading to Increased productivity
6. Allows for change at any stage of the project development
7. Focus on the user all the time; their feedback & input

The primary goal of Kanban and Scrum is pretty similar, i.e., help organizations reduce execution time, optimize resource utilization, improve productivity & provide insights to measure. Both Kanban & Scrum are models of agile execution. Kanban focusses on specific aspects of the production process, whereas scrum is an entire framework for development. Kanban strives to present a clear picture of the workflow, while scrum defines process, steps & routines for workflow execution. It’s not uncommon to find Kanban being incorporated in a scrum process