by on

During our college days (2001) when Bluetooth was in its early stages the Bluetooth SIG (Special interest group) tied up with IEEE and announced a Bluetooth based theme for CSIDC (Computer science international design competition) with good perks like Bluetooth adapters, Windows XP and Visual studio licenses for participants and good prizes. One of our friends read about this and three of us put up a proposal with our ideas and we got through the initial round. We had a lot of ideas with us to implement a prototype, it is at this point a software company which was run by one of the alumni came over to help us in planning.

Our initial plan was to implement quickly and try it out on the users for feedback. hurry-up-2785528_640
This was for a generic identification device that can be configured to use for payments, tolls for cars, parking etc. The idea was that Bluetooth devices can hold a lot of data and gives the users the flexibility to create as many profiles as they want.

checklist-1643784_640One of the seniors in the company invited us to their place, in our first meeting itself we were stumped when we saw the mountain from which the waterfall process flowed. We were slapped with a software requirements specification document template which would have taken a few weeks to fill for the amount of ideas we had. It also had various parameters to rate the requirements like return on investment etc. I could never forget the feeling that we had on that day, we dropped our idea altogether and went on to find something which had requirements perfectly documented.

By the time we finished the first cut of the project and submitted we were only half emotiguy-1654859_640happy that we did finish something. We ended up converting EEG wirelessly and transmit through Bluetooth which was not a novel idea at all. The Waterfall process killed the idea, the fire and above all nothing useful came out of a defined process. Someone else who had submitted a similar generic id device entered the top 10 and ended up winning something. Some events leave a lasting impression on your life, this one was so strong that I had never accepted to work in waterfall development ever even though that was the only one very active around the time I graduated.

Any process followed for the sake of following it will surely kill a lot of things

by on

swiss_cheese_model_of_accident_causation

I often get into a debate with people about the type and the extent of testing that has to be done for software. One of the key arguments I hear is that developers should focus on creating only the happy path and leave the rest to the testers to find or have SDETs write extensive automated tests while developers can skip unit tests and focus only on writing useful code.

I have used the swiss cheese model to explain to people about the need for layered coverage instead of concentrating all the effort onto one layer. I first heard this term while watching an air crash investigation episode in nat geo. The narrator explains that though there are millions of parts in commercial airliners, the chance of getting into an accident is far lesser than motorcycles.

How an aircraft with millions of parts is able to get back on to the sky within a few hours after landing from a long trip? The answer lies in layered testing. The pilot has a pre-flight checklist, the ground staff do a routine check for visible damages, the maintenance crew notice the hours of usage and do preventive maintenance, there is a strong network of weather monitoring and routing, ATCs manned with trained staff and modern radars, aircrafts fitted with collision avoidance systems, a long series of protocols for ground and sky movements etc.

It is the same across many engineering and medical disciplines. The risk of something slipping through all the layers of test is very rare and if it happens then it is immediately plugged. In software engineering it is a combination of static checks, unit tests, integration tests, automated ui tests, heuristics & exploratory tests, performance tests etc. No one type of test can be removed altogether and replaced by another. We need the layers to move fast and yet deliver what is required.

Image courtesy: Davidmack, Swiss cheese model of accident causation, CC BY-SA 3.0

by on

I went to a restaurant for a buffet which was a bit crowded. I thought the service at some of the live counters will be slow but was surprised that the people at the counters were able to serve large number of customers in a short span of time, especially the salad counters.

fruit-2305192_640

I was curious so visited one of the salad counters to see how was it possible for them to serve that many people at once. It was shocking to see that in the name of speed the person at the counter was cutting fruits in such a way that about half of them got thrown away along with the skin and the seeds. If this person had maximized the fruit content then it would have taken 4-5 times the amount of time taken now on fast cuts.

It is very clear that the restaurant can afford to waste as much of half of the food because they still gained from servicing a lot more people than operating efficiently. It was optimized for time not cost.

This is something people don’t understand while choosing tradeoffs, people often choose both cost and speed as key without giving a second thought that both cannot go hand in hand. If the same set of people had to do things much quicker and at a larger scale there has to be expenditures in tools, training and also some change in processes where there will be huge wastes before optimization kicks in. This is what happens in software development teams, often there is a tight budget and an impending doom if something does not happen; leading teams to easy burnouts.

I did not include the word quality here as it is non negotiable, you can do things quick and cheap but with a poor quality of work like serving the fruits with seeds still intact or skins not peeled well. That is not work done, there is no work without quality; eventually it drives away customers.

Next time when you have a debate about speed consider moving the cost sliders.