Posts

Konsulko Group: The Year in Review 2021

Thanks to our customers, our partners and our dedicated team of engineers, 2021 was a very successful year for Konsulko Group. 

We’ve been chosen to work on important projects in consumer electronics, automotive, medical devices, agriculture, mining, finance, and autonomous vehicles. Our engineers helped our clients, new and old, build outstanding commercial products with Embedded Linux, Yocto Project and OpenEmbedded, as well as deploying Over-the-Air (OTA) software updating.

Partnerships

“Konsulko is a recommended and trusted partner for helping Mender customers and prospects succeed in the Embedded Linux space. They have an excellent team of professionals who will deliver on time and as agreed.”

Thomas Ryd, CEO, mender.io

We continued our strong relationships with mender.io, and with the Linux Foundation and Automotive Grade Linux (AGL). 

We also launched a new partnership with PHYTEC at the Embedded Linux Conference (ELC) in Seattle. Konsulko is providing support and development for PHYTEC customers using their Systems on Modules (SOMs) and Yocto Project Linux distribution.

Conferences

As in previous years, Konsulko engineers were active participants (often virtually) in conferences and developer gatherings, making presentations at ELC and Yocto Project Summits, and writing technical papers on Yocto Project, security, and OTA. We hope for a time in the not-too-distant future when it makes sense for developers from all over the world to gather again face-to-face to share ideas. 

Contributions

As many of our engineers have been working (and playing) with Open Source Software (OSS) for over 20 years, Konsulko Group is proud of our continuing commitment to contribute to the community. Last month we were happy to hear that Konsulko is #3 in contributions to Yocto Project “Non Core,” just behind industry giants ARM and Fujitsu, and ahead of every other software or hardware company.

This was even before we welcomed OSS veteran Tim Orling to the team in December. Tim was recently Core OS Architect and Yocto Project Architect for Intel Corporation, and serves as a maintainer of meta-python and many recipes in openembedded-core. He has authored hundreds of applied patches for openembedded-core and meta-openembedded. 

Doing business with Konsulko Group

As a team we have found that the best way to work with our customers and prospective customers is to provide a high level of transparency about our business processes. This year, we’ve published blogs on scoping the effort required to successfully complete a customer project, and another describing our two models of engagement

  • Konsulko Continuous Time Engagement™ for dedicated engineering resources
  • Konsulko OnDemand Time Engagement™ for high level consulting, on-demand support, and specific tasks within a larger project.

We hope you have found these useful, and we look forward to working with you in 2022.

The black magic of scoping the effort in software projects

The software industry is notorious for missed schedules and project budgets that end up being double, triple or even higher than original estimates. One of the first managers I worked for, early in my career, joked that when an engineer gives you an estimate, you should double it and then move to the next unit of measure. In his mind, a two weeks estimate thus became four months. This was obviously an exaggeration, but it does point to the magnitude of the problem.

Three reasons for missing an estimate

There are multiple sources for missed estimates. First, there’s the shear complexity of scoping the effort of large projects. 

Second, engineers often think “dev done / it sort of works” as the end point when estimating the time it will take them. 

Lastly, there is the explicit or implicit pressure most engineers feel to come up with an estimate that will be palatable to upper management. The problem is even greater, I believe, if you consider the long hours engineers put in every day, plus many weekends and sometimes even holidays, in order to attempt to make the impossible schedules they’ve signed up for.

Missing schedules and blowing up budgets is not a luxury a professional services company has. Roughly 85%-90% of our projects end up under budget, and even the few that end up over budget are for reasons outside of our control. While there is no precise formula to use to properly scope the effort, I’ll share just a few notes that developers in our space may find useful.

Make sure you make the right assumptions

Your estimates are based on assumptions: 

  • working hardware (no glitches with the components or the PCB itself), 
  • deliverables owed to you by the customer, 
  • documentation that you might not be able to obtain easily and the customer will have to get it for you (due to strict NDAs, for example), 
  • any possible software deliverables by the customer to you, and so on. 

Start by listing your assumptions and make it known that if any of them prove wrong, additional time and budget will likely be required.

Look at specific tasks in the project and lean on past experience when you can

Break down the project into manageable tasks that you think you can estimate but lean back on past experiences with similar projects. One example that developers in the embedded Linux space will recognize is uplifting a BSP from a certain kernel version to the latest stable (same hardware, no new board spins to deal with). It’s easy to look at the list of, say, 10 device drivers that “should just work” and estimate that each one will take a day or two only, and 90% of the time you’ll probably be wrong. 

What we know from experience is that when doing similar work, it took on average, for example, one week per driver. Some may take a few hours; but others will take two weeks, and you don’t know which ones ahead of time. Don’t let the customer pick your estimates apart. Group this effort into a single task, “Uplifting the following device drivers:” and provide only a single estimate for the task.

Take a high level view

If you can’t break down the project into small tasks or perhaps it’s hard or impossible to estimate them, then step back and take a very high level view, or use a mix of approaches. 

We recently completed a project that included, among other tasks, bring-up of brand new hardware and writing some new, rather complex, Linux device drivers from scratch. The drivers we estimated separately, based on prior experience with these types of drivers and the corresponding Linux subsystem. As always, we listed our assumptions. 

The hardware bring-up, on the other hand, is impossible to estimate with precision. Instead, we used completely different high level heuristics once again based on 20+ years of industry experience: looking at past projects of similar complexity, how much time the customer took to go from first board spin to production, how much time we needed to get our work done, how much time the customer required for support and so on. 

Using such heuristics, we came up with an estimate for bringing up the hardware through the first spin (there is always a respin of new boards) and the writing the new drivers. We beat that estimate by a couple of weeks. 

Consider making the estimate Phase 0 of the project

Sometimes you just don’t know until you start working on the project and you’re two or four or more weeks into it. If that’s the case, make that a Phase 0 with the deliverable being a well defined and fleshed out effort estimate and project schedule, one that you can sign up for with a higher degree of confidence. 

These are a few of the ways we look at estimating a software project. As you can see, it’s not “black magic” after all but a multi-faceted approach to accurately scoping the effort. Contact us to learn more and prepare an estimate for your project.