Here is a glimpse into the show an aviator waits for each year…
A trip down aviation history
EAA’s Airventure at Oshkosh, WI for most aviators is a unique experience each year. The event is the same, the venue is the same, most of the stalls are the same. Yet, nothing about AirVenture each year is the anything but the same. This is one of the reason why 700, 000 plus visitors come to Oshkosh, WI each year. I have personally been there every year since 1997 (when I moved to Chicago) with the exception of perhaps a couple years when my work called for trade overseas and I wasn’t in town to make the trip. Other than that, I do my best to ensure that the third week of July each year is blocked off from anything that needs me to travel away from Oshkosh. This year, I went in mid-week for my annual pilgrimage to AirVenture. But by evening I knew I hadn’t had enough. So, I woke up really early on Saturday morning and went back again! It was a scorcher of a day. A heat index of 96 degrees. Really hot. But few things deter aviators or those with an aviation passion from doing the rounds at Oshkosh. I was proud to be one of them.
On this trip though I took a slightly different route around the grounds. They say that the cosmos has nice surprises in store for those who take the unbeaten path… and indeed it had. I struck upon a used parts stall. The inventory of used, discontinued parts was unbelievable. I have been to another such store in Chicago, but to find a store like that in a airshow/convention venue was just a surprise. I couldn’t resist the desire to walk inside. What as meant to a quick 5 min browse, turned into 90 minutes of looking at all of these gauges, fan blades, props, dash mounts, even a few seats from old airplanes. Amongst all of those, my heart got set on two things. One of them was a Gables radio – a NAV unit. The other was very interesting. It was a display cum control unit for a Rockwell Collins Doppler Radar Navigation system. An analog computer! I was just amazed by the very construction of this panel. A piece of aviation history! It go me so interested that I waited to get back home and start searching for what it did or how it worked. What follows below is the result of the research.
The panel was part number 162C-1 of a larger ecosystem that collectively made up the Collins Doppler Radar Navigation System. The part was made in 1959. Upon further research, I found a few different interesting facts. A full description to come in future posts.
Thx, CJ
Aviation Moment
Building a Motion Platform – the basics
For many years now, building a motion platform for a recreational flight simulator has been on my mind. Extending a home-built recreational simulator with a motion seat or motion base is nice science project but is also a meaningful extension to the study of the simulators. Three years ago I had built a small servo-based model of a motion platform with 2 degrees of freedom (2DOF).
Three weekends ago, I started down the path of figuring out a design to make a scale version of a motion platform.
There are several parts to the development of a motion platform that can connect to a PC-based simulation engine. I have had very little experience with any of these steps and so it had to be learning by doing.
The overall set of steps are as follows –
- Determining how to communicate with a real servo or motor or actuator
- Determining whether to use motors, servos or actuators
- Validating the hardware cards that could interface between a PC and those motors or actuators
- Writing code to drive those cards that drive those actuators or motors.
- Powering actuators or motors or servos
- identifying the right actuators or motors or servos that will serve the platform build
- Connecting the actuators to the interface cards and then to the PC
- Writing test code that tests the actuators
- Connecting the game to simulation platform engine
- Connecting the platform engine to hardware driver engine
- Acquiring and transmitting telemetry to the chain above so as to be able to get the game’s motion to reflect realistically on the actuators.
Note that none of the above yet even discusses the build of a platform base or seat. This is just the work that is needed to get the concept validated.
For the simple prototype I chose to go with Progressive Automation for actuators. I also chose to go with MultiMoto Motor/Actuator driver. This card would seamlessly integrate with an Arduino chip. I picked up the LA-14P actuator from Progressive because it had built-in feedback. Needed a power supply and used my 10 Amp, 12V power supply that I use to charge my RC airplane batteries.
Until next time…
CJ
Quick Method Software Estimation and Project Planning
Earlier this week, I conducted a simple and what I believe, was an engaging and effective workshop on estimation and ROM sizing - a critical aspect of proposing software projects. The audience was a group of project managers. Any such invite on the calendar asking for participation in a project management activity is viewed with some skepticism. ‘One more meeting…” is the thought that must have run through the minds of those that were invited to the session. Regardless, they all showed up. The end result was in my opinion a very engaging session. They all participated. We all learnt from the session. This post is to share some of the learnings from the session. What did we set out to do - Essentially, I wanted to communicate the power of separating “Effort' estimation, from 'Elapsed Time' computation; while further separating both of those from ‘Resourcing'. My sole focus was to engage the team in a hands-on activity that would convey the reality around the wide variance of software estimates even when conducted by different individuals in the same room against the same spec. It would tell us us what clients experience when they see proposals created by different members in the same group. With the exercise around "Effort" estimation completed, my intent was to use their estimate and have them perform an "Elapsed Time" computation. After those two steps were completed, we went on to put together a "Resourcing Plan" with the right skills and corresponding capacity. Before we got started, we needed a simple but complete business need. We just picked a sample requirement for this purpose. Outputs from the exercise: There were 15 people in the workshop. We received 15 estimates. In any such exercise, there is bound to be a spread. All that we can strive for is narrow variance. The data gathered is charted below for your reference. The data, even being a small sample, when charted followed a near-normal distribution. That is a good sign. However, the data was also skewed to the left of center, indicating the general bias to estimate lower.
Using these estimates we then moved on to computing Elapsed Time. But before we did this, we needed to set some contextual parameters: A) we adopted the AGILE process model for this task B) we time-locked the Sprints at 2 calendar weeks C) we capacity-locked the Sprints to 80 capacity hours D) this left 'Scope' to be the variable element To get a little more room to compute the Elapsed Time computation, we asked each participant to take their estimates and multiply it by 10. For the example shown below, the PM had his effort at 410 hours.
This computation indicates a 12 calendar week timeline.
Now for the important thing... note that till now, we haven’t spoken about resources at all. And thats for a reason.
The resource staffing matrix or the ’staffing plan’ as it is called, is not relevant till this point.
The important and critical learning here is that the Effort is the effort. It has nothing to do with elapsed time or the staffing plan. There may be some influencers such as team experience levels, productivity, tech stack, architecture construct, programming environment, tools etc., but Effort remains the effort.
Like wise the delivery model has little or nothing to do with Effort. The work remains the same. Whether we deliver via iterations or sprints, Effort does not change. If work breakdown changes, then due to granularity, effort may appear to change but it really hasn’t.
Building out a resource model involved composing a team to have a total capacity of 80 hours per Sprint - aka - over a 2 calendar-week period (remember earlier on, that is the number we locked our Sprints to - 2 calendar weeks).
These 3 steps provide a reliable, repeatable method to arriving at Effort, Elapsed Time and the Staffing Plan. Until next time… CP Jois
Quick Method Software Estimation and Project Planning
Earlier this week, I conducted a simple and what I believe, was an engaging and effective workshop on estimation and ROM sizing - a critical aspect of proposing software projects. The audience was a group of project managers. Any such invite on the calendar asking for participation in a project management activity is viewed with some skepticism. ‘One more meeting…” is the thought that must have run through the minds of those that were invited to the session. Regardless, they all showed up. The end result was in my opinion a very engaging session. They all participated. We all learnt from the session. This post is to share some of the learnings from the session. What did we set out to do - Essentially, I wanted to communicate the power of separating “Effort' estimation, from 'Elapsed Time' computation; while further separating both of those from ‘Resourcing'. My sole focus was to engage the team in a hands-on activity that would convey the reality around the wide variance of software estimates even when conducted by different individuals in the same room against the same spec. It would tell us us what clients experience when they see proposals created by different members in the same group. With the exercise around "Effort" estimation completed, my intent was to use their estimate and have them perform an "Elapsed Time" computation. After those two steps were completed, we went on to put together a "Resourcing Plan" with the right skills and corresponding capacity. Before we got started, we needed a simple but complete business need. We just picked a sample requirement for this purpose. Outputs from the exercise: There were 15 people in the workshop. We received 15 estimates. In any such exercise, there is bound to be a spread. All that we can strive for is narrow variance. The data gathered is charted below for your reference. The data, even being a small sample, when charted followed a near-normal distribution. That is a good sign. However, the data was also skewed to the left of center, indicating the general bias to estimate lower.
Using these estimates we then moved on to computing Elapsed Time. But before we did this, we needed to set some contextual parameters: A) we adopted the AGILE process model for this task B) we time-locked the Sprints at 2 calendar weeks C) we capacity-locked the Sprints to 80 capacity hours D) this left 'Scope' to be the variable element To get a little more room to compute the Elapsed Time computation, we asked each participant to take their estimates and multiply it by 10. For the example shown below, the PM had his effort at 410 hours.
This computation indicates a 12 calendar week timeline. Now for the important thing... note that till now, we haven’t spoken about resources at all. And thats for a reason. The resource staffing matrix or the ’staffing plan’ as it is called, is not relevant till this point. The important and critical learning here is that the Effort is the effort. It has nothing to do with elapsed time or the staffing plan. There may be some influencers such as team experience levels, productivity, tech stack, architecture construct, programming environment, tools etc., but Effort remains the effort. Like wise the delivery model has little or nothing to do with Effort. The work remains the same. Whether we deliver via iterations or sprints, Effort does not change. If work breakdown changes, then due to granularity, effort may appear to change but it really hasn’t. Building out a resource model involved composing a team to have a total capacity of 80 hours per Sprint - aka - over a 2 calendar-week period (remember earlier on, that is the number we locked our Sprints to - 2 calendar weeks).
These 3 steps provide a reliable, repeatable method to arriving at Effort, Elapsed Time and the Staffing Plan. Until next time… CP Jois
Aviation Moment
Wing-tip add-ons have taken on so many different forms. Reducing drag and saving thousands of pounds of fuel.
Here are a few examples below…. 
Winter Afternoon Flight
It’s felt great to get up in the air again after hibernating in sub-zero temperatures for over a month. It was crystal clear day. A few bumps here and there but overall a swell day to fly.
The snow had more or less cleared out after a couple above-zero days last weekend.
Traffic was heavy. Everyone wanted to fly, I guess. The Garmin 530, prompted by ADS-B technology was indicating traffic objects constantly. I wished I could have stayed up in the air for viewing the sunset.
Overflew the field at 2500ft before turning downwind for Runway 20.
The DJI Mavic Air
The DJI Mavic Air is one of many DJI UAV products. The Mavic Air is best known for its portability and serves the high-end hobbyist and serious enthusiast range of users. DJI has implemented some very unique design ideas to make the drone portable.
The Mavic Air folds up for storage, is very well built and looks aesthetic. The Mavic Air weighs just under 1 lb. and is very easy to carry around. The Mavic Air shoots 4K videos at 30 fps and still picture capture is performed at 12 megapixels. This works very well for its intended audience. The Mavic Air has a battery endurance range that results in flight times between 18-21 minutes. Strong winds alter battery endurance ranges. In terms of line of sight range the Mavic Air has a 2.5-mile control range using the remote. The drone comes equipped with internal and supplemental storage, the Mavic Air has 8GB of internal memory. The USB-C port allows for transfer of files. The supplemental microSD slot has support for microSDHC and microSDXC media. For power charging, the remote requires Micro USB and the drone has a USB Type-C port to transfer footage.
The Mavic Air is equipped with GPS and GLONASS satellite positioning. The GPS sensors are accurate and reliably enable automated and semi-automated flight modes. The Mavic Air performs well in steady hovering. Its GPS sensors make the ‘return-to-home’ safety feature very reliable. Location detection enforces no-fly zones and is once again very reliable. For example, the system will alert you to get authorization before flying at an airshow location with a TFR around it. There are a number of warning levels. Some warning levels can be overridden with necessary authorization and there are others that can’t be overridden.
The drone supports QuickShots. These automated camera shots move the drone through the air in a predetermined pattern such as a helix or spherical shot and allow for quick capture of the surrounding. This improves productivity and reduces the amount of manual programming needed to get the footage. Even with forward and rear obstacle detection, QuickShots must be used with care. In the QuickShot modes, the drone flies itself, and there is always a risk of collision.
The Mavic Air will fly at 17.9 miles per hour with obstacle avoidance enabled, or at up to 42.5 miles per hour in Sport mode, a mode in which the obstacle detection system is disabled. With a climb rate of 13 feet per second in Sports mode and 5 feet per second in Positioning mode (both using the Remote Controller), the Mavic Air is found be very useful in most situations.
The maximum service ceiling for the Mavic Air is 3.1 miles above sea level. One of the important considerations with regard to UAVs or drones is their wind resistance capability. The DJI Mavic Air wind limit is 22 miles per hour. Beyond this number, the Mavic Air will generate a warning for high winds. This can be somewhat limiting in certain circumstances. The Mavic Air’s obstacle detection and avoidance system is very much reliable. The Air has forward, backward and downward sensors. The Advanced Pilot Awareness System (APAS) leverages all of these sensors. Coupled with this intelligence, instead of simply hovering in place when it detects an obstacle blocking the drone’s path, the Mavic Air explores the situation and automatically adjusts flight to avoid it, either by flying to the side or rising above it.
Burdziakowski, P. (2018). UAV IN TODAYS PHOTOGRAMMETRY–APPLICATION AREAS AND CHALLENGES. International Multidisciplinary Scientific GeoConference: SGEM: Surveying Geology & mining Ecology Management, 18, 241-248.
DJI Mavic Air. (2019). Retrieved May 5, 2020, from PCMAG website: https://www.pcmag.com/reviews/dji-mavic-air
Fintan Corrigan. (2020, January 13). DJI Mavic Air Features Review, Specifications and FAQs Answered. Retrieved May 5, 2020, from DroneZon website: https://www.dronezon.com/drone-reviews/dji-mavic-air-review-features-specifications-faqs-answered/
Yousef, M., Iqbal, F., & Hussain, M. (2020, April). Drone Forensics: A Detailed Analysis of Emerging DJI Models. In 2020 11th International Conference on Information and Communication Systems (ICICS) (pp. 066-071). IEEE.
Why AGILE fails to be agile?
The term ‘agile’ is much used today in many different contexts – so used that its bordering on overuse or misuse. The software industry is perhaps the one that uses it the most – so much so that it coined an entirely new process model known as AGILE hoping to jumpstart a new revolution in software engineering. While there has been a lot of talk around it, this revolution has barely provided the uptick in software project success it was meant to.
Why?
There are many reason for this. One of the reasons is that while labels have changed, basic behavioral aspects have hardly changed. Software engineers don’t do much different today, software managers hardly understand the nuances between process models/methodologies. Even more importantly, customers cant seem to change their modalities as participants in the process. Transformative change requires change at all levels, in every stakeholder role. For example, AGILE requires that customers/clients become participants in the daily activities of an AGILE effort. This calls for deep commitment and necessary time adjustments. While easy to state, this isn easy to achieve. Funding models have to change. The term ‘project’ and AGILE don’t go together. AGILE efforts are on going efforts, burning down a backlog of requirements. Projects have fixed scope, time and budget – the triad. AGILE efforts – as per the very AGILE manifesto – are meant to take on change late in the process. The typical ‘Project’ attempts to control scope and rigidly guard its execution. Looked at from a high level, these are counter to each other.
The majority of software engineers hardly understand these nuances. The typical software manager struggled to deal with traditional project execution, let alone have to deal with brand new terminology and safeguards. The very definition of a requirements changed with time. From writing 100s of pages of software requirements, the ‘Iterative’ process cycle asks for use-cases in an Actor-Ability syntax. On the other hand, AGILE demands User Stories. Speak to the average software developer and it becomes apparent that the nuances are barely even understood. The situation is analogous to the time when object oriented programming models came along but it took a long time before the industry truly wrote any real object oriented code. Even today, it isn’t unusual to see engineers writing long segments of procedural code while using advanced object oriented programming languages. Software is still a nascent industry. Success is still a matter of striving till it gets done. The ‘soft’ nature of the outcome makes it very hard to measure. Traditional practices have yet to stabilize. Complexity has been on the rise. In fact inter-operable systems and cooperating systems have become the norm.
One of the fundamental goals of AGILE was to get more features out, quicker. Getting a quick Sprint 0 done has become an obsession – most AGILE projects don’t care to build solid foundations. This concept of a MVP may be very lucrative however when observed closely, most MVP start off wanting to be something and end up being barely one-tenth of that vision. I have performed many due diligence exercises and one observation is common – most AGILE sprints are more about cleaning up the mess left behind by the previous sprint and less about feature roll outs. Hardly are there teams that truly measure that basic goal of “getting more features out, quicker”
For AGILE to truly delivery on its promise, core behavior must change. Until then, it shall remain a fancy label. Core behavior change begins by educating teams (software engineers and customer) to understand the basic tenets of AGILE – starting with the manifesto, the process itself, and the definition of an outcome in AGILE.
Until next time…
CPJ
Aviation Moment
A winter storm just went though. It’s begin to clear up. A busy airport recovers its operations…
Aviation Moment
Here is another aviation moment.
747-8 over the North Atlantic. Those GENx engines are rated to produce 66500 pounds of thrust each (Boeing).
The Journey Begins
Thanks for joining me!
Good company in a journey makes the way seem shorter. — Izaak Walton
Technology Portfolio Choices
Technology portfolios grow out of control rapidly. More so in today’s environment than before. Additions to and deletions from portfolios are not casual or trivial activities. Unfortunately, time pressures on technology projects turn them into casual decisions.
Recently I was helping a team decide between a newly acquired technology and the use of native legacy technology. All facts indicated that the new acquisition, while more sophisticated technology, had a track record of delaying projects. There was clear evidence that the team was having a hard time finding people with skills in the new tech. Despite that the team had persisted for 8 months, without making any progress.
Indeed, its hard to disband a new foundational technology. However, as technologists, we must always keep the facts in view and allow data to speak the story. All facts indicated that we were being slowed down the technology rather gaining any momentum. The right decision was to disband the choice and move forward. Thats what we finally concluded.
Always remember, let the facts guide the decision. Its never too late to remedy a situation.
CP
Requirements Engineering
Everything in the world (almost everything) starts with a need. Likewise with software engineering… it begins with requirements. However, with time, despite the various process models, lifecycle descriptions and artifact templates, the ‘good requirements’ conundrum has remained an elusive goal. Over 3 decades of my career, not much has changed, other than the amount of time spent in the industry debating this subject and/or finding a way to short-cut the process.
Even today (in fact, lesser today than ever before!), software professionals cant distinguish between process models and associated artifacts. Ask a software engineer today what process model his organization uses and my bet is that most will say they don’t know. Many others yet, will look at you as though you asked them the azimuth angle to the moon. If there is this much disregard for the process models in use, it is best not to ask what artifacts go with which process model. What I mean is that process models were set up for a purpose. They demanded certain roles and allowed the production of certain deliverables. For example, the Waterfall model used the software requirement specifications as its requirements artifact. Unified Process (UP) introduced and used the concept of ‘Use Cases’. Most methods within the Agile umbrella leverage the construct of User Stories. These were not just made up on the fly. The construct and templates for each of these took a certain meaning.
Its one problem not to have any process at all. It can cause some pain. However, its worse to have people mixing and matching process models and process artifacts at random. It causes chaos. In a certain instance not too long ago, during a routine assessment, i came across a situation, where the team spoke of ‘Agile’ all the time, but was using an “SRS” (the software requirement specification) as the requirements artifact. The SRS was 384 pages long written 7 months prior. This is not uncommon. In fact, its becoming increasingly common. There is no practical way for any effort to use this SRS and be truly agile in their work.
The industry has even tolerated and perpetuated the confusion between business analyst and a requirements engineer. Lets just conclude this minute – A business analyst and a requirements engineer are two different roles. They do very different things. They produce two very different outputs. To use one for the other can only to problems. Far too often, information technology departments have called for and used the BA for requirements collection. Defining ‘need’ and engineering good software requirements are two VERY different outcomes. It worked for several years because the construct of the SRS. The SRS typically grew into a fiction novel anyway – one that not many read – at least, not the programmer that wrote some code anyway. The SRS hid the differences between well engineered atomic requirements and a long story book.
That is no more the case. UP and use cases demand succinct engineering. They are meant to be atomic in nature. They absolutely need to be engineered if one were to be looking for a useful requirements artifact.
In a time, where the velocity of change is far outpacing our ability to innovate, its time to pay more a little more respect to requirements, and truly engineer them – especially if an organization wants to remain relevant.
CP Jois