Upgrading my desktop machine


I myself and my tech guru Nirmal assembled a machine back in 2009. It is a Core2 duo E7500, Gigabyte G41, 2GB RAM, Intel on board X4500 graphics, 7200rpm 500GB Seagate HDD and normal ATX case. Even though I hated that big case, it was running win7 32 bit fine. Recently I upgraded the machine to Windows 10 64 bit. And the machine started to show its age. It was sluggish, YouTube can play only 480P and visual studio was crawling. My first option was to sell this machine off and buy a new one (It has served me 8+ years without any major problem). Assembling a machine is always done for a need. In my case when I assembled the machine I wanted it to run for a long time. So I just removed the thought about selling it and started to search for the root cause for the sluggishness. After some measurement I found out the root cause was the graphics card. Windows 7 gave it a rating of 1. In addition to this 2GB has become quite less for a Windows 10 64 bit.

I went in search of a graphics card that can replace my onboard card. I didn’t want to buy a graphics card for gaming. I found a zotac nvidia 210 card for 1200Rs and additional 2GB of DDR2 RAM for 745Rs. To my surprise I also found an Intel xeon quad core L5420 with 12MB cache for 800Rs (a core 2 quad Q9650 costs close to 8000 Rs). Even though the xeon was for Socket 771 with a little bit of hack it can be used inside a socket 775 motherboard. I upgraded the processor, RAM and the graphics card. The processor gave big boost in the performance and also reduced the power consumption from 65W to 50W. The graphics card takes care of the media playback and graphics well. The additional RAM gave extra breathing space for the Windows 10 64 bit. The machine is running fast enough and youtube is back to 1080p.

The moral of the story is, a big ATX case and all that assembly might look ugly, but when it comes to upgrading and saving our hard earned money there is no match. Cashify gave an estimate of 1000Rs for my machine and building a similar machine would have cost me somewhere around 20K. I think with this small upgrade of 2745 Rs I saved some 15K (building a new machine from scratch). I hope the machine serves me some more years.


First IOT home project – Bus announcement system

Recently my daughter’s school came up with some fancy application called falcon parent. It basically provides tracking of the school bus and the student’s commute information. The application is quite good. It provides

  • Live tracking of the bus location on a map
  • Send alert once it is near to the boarding point
  • Send alert about the student boarding and alighting

Initially I check the app and alert my family members when the bus is nearby. Engineers in general have a common trait, they come up with the most complicated solution so that they need not do the simple thing (basically laziness). In my case I wanted to automate my work (alerting the family regarding the bus). All solutions (journey) start simple.

Simple Solution

I have tasker for android(the app I don’t regret paying for) & NotificationListener plugin. I did the following

  1. Intercept the notification from falcon app in my phone.
  2. Use Google TTS and speak out the notification.


Simple thing worked fine. But it works in my phone and if I leave early to office the alert was of no use to me and my family. Actually during an official interview presentation my phone spoke “Fathima boarded the bus” in full volume.


It works only in my phone

I thought the solution should work independent of my phone. Then I remembered my sister’s galaxy note that I spoiled (tried to replace the glass and burnt the display). No one was using it. Everything works but the display was unusable (became black & white). I thought just move the solution to that phone and it works independently. But past always haunt the present solution. It had android 4.1 and notification intercept is not supported. Either I have to root or find another alternative. At last PushBullet came to my rescue. It can intercept pushbullet message and trigger an action in tasker based on a trigger word. The solution became

  1. Intercept the notification from falcon app in my phone.
  2. Send a message to galaxy note via push bullet.
  3. Based on a trigger word the galaxy note will trigger an action.
  4. The action use Google TTS and speak out the notification.

Usability study

I thought everything was fine. I kept pestering my mother, wife & sister regarding the feedback. They said it was ok. But the Google tts announcement was like our railway station announcements. People just understood that the system is trying to tell something and ignored it most of the time. After doing some study and breaking my head, I found that we can identify known music easily even with lot of noise. Now I tweaked the solution like

  1. Intercept the notification from falcon app in my phone.
  2. Send a message to galaxy note via push bullet.
  3. Based on a trigger word the galaxy note will trigger an action.
  4. The action use Google TTS and speak out the notification.
  5. Based on the type of notification play a known music(for eg airtel ad, bond theme music, MI theme music, bus honk)

Sustaining the solution

I thought all is fine the system is working fine. Now on hearing the bus honk my kids hurry and go down to catch the bus. After couple of days I checked and found that the phone switched off due to low charge. Initially I thought of keeping the phone always connected to the power (battery might go off soon) or to save the battery I have to charge it manually. But like I said earlier the laziness kicked in again. I wanted a solution that will charge automatically and also save the battery. Again I had a Kankun sp3 smart plug lying around for some time without any use. That came to my rescue. I did the following to charge the phone

  1. Connect the smart switch to wifi with a static IP.
  2. Installed a REST api inside the smart switch (Thanks to Hackaday) .
  3. Connect the phone charger to smart switch.
  4. Tasker switches the charger ON (using the REST api) when the battery level is <50%.
  5. Tasker switches the charger OFF (using the REST api) when the battery level is 99%.

Now the automated solution is part of our day to day activities. The system just works now. May be some surprise might come in future. Cheers.


Subtle things in SCRUM – 3 Testing teams

This is another aspect that we discovered over a period of time. At the start once we decided to follow scrum, we took each of the team, trained the team regarding scrum & team lead were trained to be a scrum master. Then one fine day we decided that everyone (dev & test) will follow scrum. A typical scrum team is self organizing. Team members pick up the task from the sprint backlog and burn them during the sprint. Each team works for the success of the sprint and adds a shippable increment to the component. And at the SOS (scrum of scrums) level all teams add a shippable increment to the product. This is the ideal situation that every one of us expected.

The reality was something different. At the end of the sprint we added an increment but it was not shippable. The bugs were found after the sprint delivery. The moment we had substantial number of bugs it cannot be called as a shippable increment. After some brainstorming we found the root cause. We took the conventional team setup and converted them to scrum teams. So we had development teams and testing teams. The development teams concentrated on adding new features. The testing teams took the last sprint delivery and tested the software. The target for the development team was to add more and more features. And the target for the testing team was to find all the bugs. Since the testing happened in the next sprint a sprint delivery became a shippable increment only after spending 2 sprints. We wanted to shorten this to a single sprint.

The solution we followed was to merge the testing and development teams together. Now a typical team contained a set of developers and testers. During the sprint the development and testing happened in parallel. Teams ensured that the bugs were resolved within the sprint. Those bugs which cannot be solved in the same sprint were scheduled in the following sprint. Now over a period of time the increment we added in a sprint became shippable increment. The lesson we learned was “development & testing goes hand in hand & scrum teams are cross functional”.


Talk to the real customer and listen carefully…

As an architect one has to interact with different stakeholders. An architect interacts with developer, tester, requirement engineer (our internal customer), fellow architect, designer and the real customer. Out of all this interaction, I feel the interaction with the real customer always fascinates me a lot. I will share one such instance here. In the recent times I visit a hospital regularly for my kid’s vaccination. The regular pattern is like we call the hospital and book an appointment. The appointment itself doesn’t contain a time slot or any waiting list number (token number). After this we need to physically visit the hospital, pay the consultation fees and get a waiting list number. Then we wait for our turn. This waiting is a painful one for all the visitors. The hospital has a nice IT system that helps them in patient management, billing, consultant management and employee management. Being a software solution provider I thought this is great opportunity. Add a module that can provide automated online appointment management (web based/mobile based). The visitors need not waste their precious time and still gets to meet the consultant on time.

I got a chance to meet the hospital head and mentioned this solution. Also I elaborated how easy it is to add such a module. He listened carefully and then uttered the following

“I know it is easy to add online appointment management to our system. But in our locality people still judge the popularity of a hospital by the amount of crowd waiting for consultation. If I reduce the crowd by introducing such a system, then it will bring down the popularity of the hospital. So having a manual appointment management system is a conscious business decision.”

I learned the reason and thanked him for the clarification. As I stated in the beginning interacting with a real customer is always fascinating.

Software Architect & Big Picture

In this post I am going to cover an important responsibility of a software architect. A software architect should know and own the big picture. The big picture is a collection of important decisions, if broken has a system wide impact. Often software teams come up with the following arguments for not having an architect

  • Architects don’t code. They are costly resource.
  • We need the architects at the start of the project then we don’t need them.
  • Architect just write power points and don’t understand the details.

But in reality a software architect is not a role with all the details. This role works with all the abstraction of abstractions. A software architect is responsible for ensuring that all the quality attributes are achieved. For a simple small project a software architect may not be needed. But the moment project becomes huge and complex the team needs someone to take up the role of software architect. To do this a software architect needs to know and own the big picture. The component teams often make lot of local design decisions. A software architect should be able to identify decisions that might have an impact on the big picture. And if a local decision will break this big picture then it’s the architect’s job to communicate and do a course correction. Ok enough of abstract talk. Let me give a real world example.

I used to visit one of my friends who run a cell phone repair shop. One day a customer came to the shop with lot of anger. He mentioned that the helper broke his mobile and the camera is not working any more. My friend inspected the phone and found the memory card was filled up. There is no space left for storing a new picture. He explained this to the customer. But the customer mentioned that the camera was working until he gave the phone for servicing. Now my friend enquired the helper regarding the service he performed. The helper mentioned that as a part of service the customer asked for some songs to be loaded to the phone. The helper filled up the memory card with songs. Now my friend said to the helper that the memory card is a shared resource. At least 30% of it should be left empty. This is a basic rule of servicing. The helper freed up this space, learned the lesson and gave the mobile back to the customer. Customer mentioned “I normally don’t give my phone to your helpers directly. Next time I will give my phone for servicing only during your presence”.

In this story the helper was focusing on one aspect “Loading the music to the phone”. He decided to fill the entire memory card with music to delight the customer. But he was not aware of the implication it might have on the other subsystem (camera operations). And he broke the rule of leaving 30% space free. In real life software projects each of the component team is thinking about its component and makes such local design decisions without knowing its implications on the other subsystems. And they may break an architectural decision. Here my friend is like the software architect and the helper is like the component designer. A software architect needs to communicate with his fellow designers on a regular basis and ensure that the architectural decisions are not broken. But during the course of software architecture and design lot of such mistakes are bound to happen. During all these times a software architect should patiently course correct his fellow designers and ensure that his big picture remains valid.

The customer in the end mentioned that he wants someone to own the big picture in a subtle way. In real life software projects too we need someone to know and own the big picture throughout the project.


Internet of Things, Black Magic and Humans

In the recent times I read a lot about IoT(internet of things). And the way they are going to improve our lives in so many ways. For example the story goes like

  • By the time you reach home the thermostat will start the AC or the heater and setup a pleasant temperature
  • The new age LED lights are connected to internet and switch on/off based on your location pattern
  • The fridge finds out, there is no milk and adds a to-do entry to your to-do list to get the milk
  • There will be sensors everywhere. Based on the data they will decide and act intelligently

Yes. All of this is well and good. But among all this intelligent set of things there is a dump thing mixed in. It is none other than the HUMAN. At times I feel scary how this billion of IoT is going to handle the human. I will quote one of my own examples here.

  • At our home we have 2 iPods a nano(8GB) and a touch(32 GB)
  • My father used the nano while I used the touch

I load the songs into the iPod using the following routine (Because of the difference in the iPod memory size)

  • Remove all the songs from iTunes
  • Connect the iPod to the PC
  • Add the songs based on the need into iTunes
  • Run the iTunes sync
  • Disconnect the iPod

Sometime back I was travelling to USA for a long term. As a part of the travel preparation I made sure I loaded my entire music library into my iPod touch. One check list item done and ticked. My father requested me to load some of his personal favorites into his iPod nano. I did my regular routine and gave the iPod back to him. He thanked me and verified all his songs were loaded. I felt happy that in between the travel preparation, I could get this small job done.

I packed my bags and reached USA. After a week I thought of listening to some of my favorite music. I took my iPod touch, charged it and connected my headphones to it.


I hear some old song that was my father’s favorite. I thought maybe I added that by mistake. I shake the iPod for a shuffle. Again another old song. After lot of shake I found my entire music is missing and is filled with my father’s collection. I am wondering what has happened? I didn’t touch my iPod after the last sync. I clearly loaded all the songs myself. That was the first step in the travel preparation. I was wondering what sort of black magic has happened?

Then I found out, I turned on itunes wifi sync by mistake sometime back. So when I was loading the songs to my father’s iPod, my iPod touch found that out, intelligently wiped all the songs from its library and loaded all my father’s songs into it over wifi automatically. From the iPod touch point of view this is perfectly fine and intelligent doing all this in the background. But the outcome was a disaster from my point of view.

The problem is humans have a tendency to forget things. Until now it was my PC, internet and the so called Smartphone that has to deal with this situation. Now I am not sure how this billion IoT is going to handle this situation.


Subtle things in SCRUM – 2 Burnout

In continuation to my last post, Here is another subtle thing that I learned by practicing scrum.

The success of a SCRUM team depends on the effective sprint execution. Our typical sprint execution is like

  • We have a sprint backlog. This is prepared as a result of sprint planning
  • Each team member takes a task and starts working on it
  • Each day in the daily stand up meeting the team member reports the amount of time needed to complete the task (it is like estimating the task daily based on the latest knowledge)
  • Once completed pickup the next task based on priority

But during the retrospective meetings the team members complained about burn out. The following were the comments

  • This methodology is too taxing
  • I have no time for any other work other than the project
  • In case of waterfall we had pressure at the end but here in scrum we have constant pressure all the time

Over the time the team’s productivity also came down a bit. After some analysis we found the problem. It was “Allocating all our time for the project during sprint planning ( 8hrs/day )”. In addition to that during the planning phase we tried putting in as many hours as possible. And during the sprint we tried to meet those numbers.

The problem was solved in 2 parts. One was from the project management side. The other was from our own.

  • From the project management side they too felt this burnout and made a small change. Instead of planning for 8 hours a day, we were asked to plan only for 6 hours a day. The remaining 2 hours went for all the non project activities.
  • From our side we made sure that the team brings in all time burners to table (training, vacation, holidays, supporting other teams, reading, learning etc.,).

Now the team had a constant load and we started to make predictable deliveries. In addition to this we never got the feeling of being under constant pressure and burnout. Again it’s a small correction but we learned it only during the practice.