In our (software) industry, “Assumptions” is common word and used extensively in all proposal documents.
In this blog, I would like to quote two anecdote from my life
Assumptions are important
12 years back, When I wrote my first proposal response document, My Lead introduced this word “assumptions”. Then supervisors were strict, blunt and straight forward. I got earful of shouts on that day during his review of proposal. They taught me many good lessons.
Environment related assumptions were missed out by me. I assumed that all the different environmental setups would be available. Also my plan did not include architects approval. Then my Lead explained, unless you make those assumptions in writing, this would not be known to others. Timeline assumptions were proved vital later because ARC board of client team took considerable time to approve the design document. Because this specific condition was written we could get rid of bad named of delayed delivery.
Though making assumptions and documenting them seems to be rudimentary task, it is very critical part of proposal document. Then onward, I used to make very clear assumptions.
Assumptions may mislead , validate them before you make more assumptions based on previous once !!
My second incident was bit different, which says making ground assumptions and moving ahead is also not right way. These assumptions need to be verified under conditions and modified accordingly. Let me narrate the story.
My team was working on an application that uses indoor location which designed based on pozyx . This blue line in picture shows the path of the tracking.
After through analysis, my team set the system, but we could not get accurate positioning.
The error was trivial one, placing the anchors vertically made it working. Though the rule no : 3 of the documentation said “anchors vertically with the antenna at the top”. First assumption of antenna position will not impact the results cost us two weeks of work
(just FYI, how pozyx works : It uses UWB -ultra wide band frequency waves. The most commonly used method of positioning uses basic geometry to estimate the position. By measuring the distance to a number of anchors with a known position it is possible to obtain your own position. If we measure a certain distance, then we know we will be in a circle of that radius around the anchor. If we make distance measurements with 3 anchors we see that our position is uniquely determined by the intersection of the three circles. This method is called trilatteration (or multilatteration if more than 3 anchors are used).
After getting the results, we found that results are too scattered, the path need to be smooth. Removing noise data and make a smooth curve by applying filters, there are two methods were analyzed. Lowess and Savgol
In order to do this smoothing at real time, design is revised to include Raspberry PI in the basket.
Thus we have five components in our architecture. Raspberry pi –> Algorithm –>network transfer –> MQTT –> the UI
When the values were not received constantly, there were delays. We thought the delay is primarily due to network.
Next bottleneck could be raspberry pi which is having low processing power than PC.
Later when we took log of timestamp, it is found that network is fine and raspberry processor is good enough, The real delay was from smoothing algorithm which chokes the data and it processes data sequentially, thus delay is increased. Then we moved to Savgol algorithm which is fast but less smoothing effect.
After getting the data , while plotting the data it is found that straight line is shown as inclined. We assumed relative positioning does not matter as all our initial testing was done always on circular path. Straight line as per our eyes is not the straight for Pozyx. It plots data in relative positioning of anchors. We applied trigonometric corrections to get straight line.
Three initial assumptions made by us
Network was the primary choking block in case of delays
Positioning of anchor does not impact result (antenna will work in any direction)
If plotting works for circle, it will work for all other shapes as well.
But later, all three assumptions were proved to be wrong.
It is important to make assumptions while architecting and designing the solutions, but it is equally important to validate those assumptions at constant intervals.
It is not right to assume wrong assumptions.
Comment your assumptions which proved wrong later.