Toxic Technology Behavior

Over my career I observed this behavior in more than one company; the only difference between one company to another is how prevalent this behavior is. Its a cancer that slowly spreads in the company kicking out all the none toxic behavior until the entire organization seizes and productivity drops to zero.

 

  1. Always create a dependency on someone else.
  2. Always leave an open action item pending on someone else.
  3. Make sure to include as many people into the project as possible. i.e. Generally speaking if a project includes more than 10 people it comes to a stand still.
  4. Raise open ended questions to external parties with little or no background on the project on hand. ex: looping in security team/compliance.
  5. Make sure that the last email in the chain is not addressed to you.

The main directive here is to make sure that the project is always late, because of other people of course, and is not delivered. The product of an undelivered project can not be assessed and the more critical it becomes with delay the importance of the people handling it increases.

The worst thing about this toxic behavior is how the number of people practicing it seems to increase exponentially, with the good employees either turning or simply leaving the organization.

Digital Telecoms Explained

mechanicalturk

Digital is the new frontier in the telecom industry with digital transformation projects becoming a commonality among telcos, but what exactly is a digital telecom ?

A good starting would be defining what is NOT a digital telecom, A telecom that requires direct interaction between customers and its employees can not be classified as a digital telecom.

A telecom that requires direct interaction between the user and its employees can not be classified as a digital telecom.

A digital telco is a telco that allows customers to enjoy the service without having to think or deal with the telco itself. In the digital world a service provider biggest differentiator is being invisible. Digital telcos don’t try to improve the quality of their call centers they eliminate them all together.

Call centers have no place in the digital services era. The services offered to the customer should be built from the ground up to cater for self-service, customers shouldn’t need anybody to help them complete certain tasks, CallCenters were created in a time when the technology fell short from achieving true customer autonomy certain tasks were simply too hard to automate and thus required that human touch.

creativeadvertisements10

Too hard to automate? have someone do it

Technology has gone a long way since these days and digital experiences are now possible and accessible. A good example of a digital experience is gmail, it requires little effort from the user with minimal friction with the service provider, gmail users rarely if ever require any support from Google, there is little a user can’t do online using few clicks.

Digital telcos are typically cheaper to run and operate as most of the operational expenses are minimized or even eliminated, this allows for cheaper rates and affording a higher customer acquisition cost (as in pampering potential customers). Digitizing the user end experience can be conducted by focusing on the following fronts:

  1. Online :
    • No interaction with employees should be required, Everything should be available online.
    • The sale process should be offered online with most of the sales happening through the online channel.
  2. Mobile :
    • Customers should be able to fulfill all of their needs using their devices, no task should be too hard or too complicated to be conducted using the customer’s mobile device. This requires building everything from the ground up with that in mind, customer’s should be able to see his account information, buy services, even terminate his line using his device.
    • The entire experience should be contained within a single application, even when the customer transitions to a web-shop this should be done transparently and offering a consistent look and feel.
  3. Digital Store :
    • Since most of the sales is targeted to be conducted online the digital store should be in the center of the customer experience.
    • Drawing from the accumulated knowledge by eCommerce sites such as amazon and ebay to offer the customer a truly tailed experience based on his usage history and segmentation.
  4. Social:
    • Social networks can be seen as a platform rather than websites, value can be derived by building on top of them.
    • Social promos can be created (such as Member Get Member promos) to motivate users to organically share their experience with the product.

A good example of a digital telco is the company I’m currently engaged with, feel free to check out the experience we are offering http://www.Jawwy.sa

Delivery PipeLine Approach (CoD)

Usually there are many projects waiting in the delivery queue, in most cases the HiPPO method is what determines their relative priority and thus the order they are implemented in. Pet projects take precedence on potentially more important changes, with no consideration to the financial impact especially given how illusive it is to measure the financial impact of unrealised projects.

cartoon-hippo-clipart-1

HiPPO

According to the Lean Enterprise, the biggest two risks to any IT projects are: Projects getting cancelled halfway through and Delivered projects to be shelved and never used. Based on my experience both are quite common, perhaps because of the aforementioned project prioritisation methods.

The Cost of Delay method (CoD) is an analytical approach that can help prioritise projects based on a measurable metric that can be understood by business. Simple, perhaps simplistic even yet it is much more scientific than the HiPPO approach.

CoD works as follows (and I’m using an example from the Lean Enterprise book), first each project is assigned a cost of delay value, for instance Project A which is a compliance project would entail a penalty of $250k per week of none compliance. Project B introduces a new sales method which is expected to bring in $100k per week. There are three options: A is implemented first, B implemented first, A&B are implemented concurrently.

 

Screen Shot 2016-08-27 at 9.34.53 PM

Scenario 1: If A is implemented first , the cost of delay incurred by delaying B is $200k.

Scenario 2: If B is implemented first, the cost of delaying A is $250k.

Scenario 3: If A&B are concurrently implemented with the resources split between them, the cost of delay is $350K

Based on this the decision is easy, implementing A first has a lower CoD hence it is the best choice to go for. An objective rational decision that doesn’t rely on personal preferences of product owners.

Real life scenarios are more complicated, as calculating the CoD for a project often includes many factors some of which are not foreseeable, Furthermore the CoD is often not constant over time and risk might increase overtime with increase in sales. Even more interesting projects are often not independent and delaying one project might result in a chain of events incurring unpredictable costs.

CoD is not perfect yet it is provides an economical, analytical way to prioritise projects within a complex pipeline.

 

 

 

Downloading Torrents Remotely

I’ve set up a home server and wanting a simple straight forward way to download torrents remotely I relied on an old hack I’ve heard about but never attempted. You can configure transmission the torrents client to pick up torrents files from a certain directory, sharing this directory on google drive means that you can drop torrent files for transmission to download for you at home.

Screen Shot 2016-03-15 at 4.21.56 PM.png

The problem is you can’t really monitor the progress of the torrents and some of these torrent files may not even start. So I decided to write a small shell script that monitors two events and updates me through push bullet, the first event being the torrent download start (creation of a *.part file) the second event is the completion of the download (new file in the downloads directory).

The script works as follows:

Screen Shot 2016-03-15 at 4.15.30 PM.png

 
#!/bin/bash
partsLocation=<DOWNLOADS LOCATION HERE>
completeLocation=<COMPLETE LOCATION HERE>
logLocation=./TorrentsMonitor.log
pushBulletAPI=<PBAPI KEY HERE>

for i in $(find $partsLocation -name "*.part" -maxdepth 1|sed -e "s/ /_/g");
do 
echo "Handling File"
echo $i;
echo "----------------------"

#apply check here if file exists
countOfParts=$(cat parts.log|grep $i|wc -l)
echo $countOfParts
if [ $countOfParts -gt 0 ]
then 
echo "already listed"
else 
echo "new file, adding to parts.log"
echo $i >> parts.log
curl -u $pushBulletAPI: https://api.pushbullet.com/v2/pushes -d type=note -d title="Tor Started" -d body="Download started for file $i"
fi
done

#-------------------------
#scan for complete files
#-----------------------------

for i in $(find $completeLocation ! -name '*.part' ! -name '*.log' ! -name "*.sh*" ! -name "." -maxdepth 1|sed -e "s/ /_/g");
do 
echo "Handling File"
echo $i;
echo "----------------------"
#apply check here if file exists
countOfComplete=$(cat complete.log|grep $i|wc -l)
echo $countOfComplete
if [ $countOfComplete -gt 0 ]
then 
echo "already listed"
else 
echo "new file, adding to complete.log"
echo $i >> complete.log

curl -u $pushBulletAPI: https://api.pushbullet.com/v2/pushes -d type=note -d title="Tor Completed" -d body="Download Completed for file $i"
fi
done

Deploying A Mobile APP in an Enterprise Environment

The use of mobile application on consumer grade devices is increasing in popularity as more and more companies are using customised apps on mobile devices for field purposes instead of using a purpose built device. Example of such an implementation can range from Biometrics Scanning, Merchandise Delivery or even Taxi Dispatching.

BlogImage_E-ioT.2

Certain risks are associated with this approach since unlike web applications each user is responsible for managing and updating his version, just like the pre web-apps days back when people used desktop applications, These risks include:

  1. Using an obsolete version of the app that is no longer compatible with the backend.
  2. Using a version of the app that include a critical security issue.
  3. Incorrect business process due to the use of an older version of the app.
  4. Using a none official version of the app using the same backend, thus bypassing any front end validations.

There are certain guidelines that can be followed to control the inherent risk, I’m going to list some of them here as a guideline

I. Upgrade Enforcement 

For critical upgrades that renders the previous versions obsolete, for instance changing the business process or introducing a critical security enhancement. The best practice is to break the backends backward compatibility.

Breaking the backend backward compatibility can be done by adding an app version check with every request, including the app version in every request is easy and has a negligible cost on both data and processing yet is very useful when needed. The server response should include an error code that would trigger a “You Must Upgrade Now” message.

II. Upgrade Notification

For less critical updates push notifications can be used to suggest an upgrade to the customer, a more aggressive approach  (for android) would be to handle the push to fire the play store on the application’s URI. The frequency of these notifications can reflect how important this update is.

III. Application Verification

To restrict against none official apps the api should include a verification token, there are many ways to implement this, one of the easiest way would be encrypting one of the fields (timestamp for instance) and sending both the encrypted as well as the none encrypted versions. The backend would then verify the version of the app by comparing the decrypted field against the plain text one, if they do not match the response should indicate that.

There are many ways to implement this, the encrypted field approach happens to be the easiest way to do it.

IV. Root Check/Emulator Check

Rooted phones can offer a malicious user the means to manipulate the backend calls, while keeping the verification field. A root check can be conducted on the device every time an activity is started. Emulators are easy to uncover as well.

V. Malicious Usage checks

Just in case all of your checks fail, backend should conduct even a rudimentary malicious behaviour check, blocking devices that exhibit none expected behaviour.

VI. Connectivity Issues

Even with the advances in cellular service coverage 3G/4G service remains spotty especially in rural areas. There are few ways to mitigate this depending on the nature of the requirements. If no online/sync operations are required you can implement a simple request cashing service, in which server side requests are cashed to be retried when connectivity is available.

VII. Usage Patterns Analytics (for android)

Creating usage heat maps is important when it comes to determining how the people are actually using the applications and whether certain features should be augmented or removed due to lack of usage. Luckily google analytics can be integrated to track usage or activity launches, it can even be used to track individual controls actions.

 

I hope this post was helpful I’m planning to write another post soon on how to conduct unit, QA and scale tests on enterprise apps.