Tag Archive for: pete popov

The black magic of scoping the effort in software projects

/in /by

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.

CEO Pete Popov looks back on 2020

/in /by

As we approach the end of December, it’s time to review a year that we will certainly remember for the rest of our lives. It hasn’t been easy, but all of us at Konsulko Group are still working hard, supporting the open source community and helping our customers build forward-looking products.

Even at the start of 2020, we knew this year would be different. The coronavirus was the talk of CES in January with some companies pulling out at the last minute, and everyone wondering what the global business climate would be in the months ahead.

By the time FOSDEM rolled around a few weeks later, it was clear the virus would disrupt commerce worldwide, and by the end of February, we had to cut short our presence at Embedded World because of new travel restrictions.

Then the world locked down completely. Since at Konsulko Group we all work remotely by design, we didn’t have to adjust our way of developing software, but as it did for everyone, we had to significantly change our face-to-face participation in embedded Linux, Yocto Project and other community events.

We taught ourselves to use video editing tools, and gave “virtual” presentations from our desks at the Embedded Linux Conference North America and Yocto Project Dev Day at the end of June, the virtual Automotive Grade Linux All Member Meeting in mid July, Linaro Connect in September, Virtual ELCE and Yocto Project Virtual Summit Europe at the end of October, and participated in the virtual Automotive Linux Summit the first of December.

In December, we also presented an AGL Webinar, Getting Started with AGL using Raspberry Pi.

Early in the year, we announced that we had become a Mender Authorized Referral Partner, and that important alliance has provided dividends to both Konsulko Group and our customers as the year progressed.

Konsulko engineers continued our series of technical blogs…

Helping Yocto Project work with Python 3

Getting Started with RAUC on Raspberry Pi

How Mender works

Using Rust with Yocto Project

Building a DIY SOHO router, 18 months later

…and we posted six new videos of our presentations:

Building Containers with OpenEmbedded

Highly Scalable Yocto Project Build Automation

Security Hardening with OpenEmbedded / Yocto Project

Open Source License Compliance with Yocto Project

Demo: Using Rust with Yocto Project

Software Update Solutions for Yocto and OpenEmbedded

Still, we have all been touched by the physical and emotional toll of COVID-19. Two of our engineers have endured a bout with the virus (and thankfully recovered). Some of us have family, friends or acquaintances who have become seriously ill or even passed away. We can only hope the post-pandemic world is now in sight.

In the long run, the challenges that 2020 have brought us closer together in many ways, and hopefully taught us valuable lessons that will make us stronger in a better new year.

Globally Employable Engineers

/in /by

In 2004, we founded Embedded Alley Solutions, and many things we did for the next five years simply felt intuitive. We were, after all, embedded Linux engineers with little business, customer relationship management and human resources experience.

Intuition served us well. We were doing agile-style software development long before it became mainstream, and soon it seemed like everyone knew our name. Our ability to communicate internally was second to none, using nothing more than emails and irc, creating a close knit team that felt as though everyone is in the same office, although the team was highly distributed.

Our recruiting practice was not so much about hiring as it was about building and fostering relationships with top talent around the world until the time was right for both parties to make the move. Outside the US, we tried to find the best open source talent around the world, rather than building an “outsourcing center.” We grew the company with that stellar talent and were acquired in 2009.

In the years that followed, every now and then I would read advice in an article or business book, written by some acknowledged industry expert, and think “That’s right! That’s exactly what we were doing at EA!” It was interesting and amusing to find out from others that what we had done on the business side helped make Embedded Alley so successful. I note only the business aspects here because the engineering talent we had was hard to match.     

At Konsulko Group, I find myself having many of the same discussions with customers as we did back then, and I lean on that experience. One recurring discussion we had at EA was about our “offshore engineers,” as customers would often refer to engineers who resided outside the US. Embedded Alley had a small office in Europe, as well as single employees working from a home office all over the world. We always told customers that, no, we do not have a two-tier outsourcing strategy and these were not “offshore” developers. We simply searched for the best talent, with very specific software development experience, and that talent is not always to be found next door to our Silicon Valley office.

Fast forward 10 years after the EA acquisition. I recently found myself having the same offshore discussion with a customer. A specific principal level engineer was located in an European country not known as a center for high tech. Why was it that we were proposing to invoice him at the same rate as the other US-based principal engineers? This customer had done their homework and evidence showed that the average engineering rates in this European country are significantly lower.  

I paused on the phone and thought back to our Embedded Alley days. What did I tell customers then? I realized that we never had a good, quantifiable way to explain to a customer why our engineering rates for developers outside the US, though lower than market rates in Silicon Valley, were significantly higher than the typical “outsourcing rates” in a particular location. We had talked about our hiring strategy and looking for the best talent wherever we might find it, but there were no metrics I could lean on.

Then I thought about the work this particular engineer had done at Embedded Alley; and then after the acquisition, he continued at Mentor Graphics (always working remotely from Europe). When he left Mentor, he contracted for Texas Instruments, then another US company, and finally, after the founding of Konsulko Group “rejoined” our team. Meanwhile he had had other opportunities, from contracting gigs to full time jobs in the US with H1B visa sponsorship.

And that’s when it struck me. This was not an engineer working in an offshore office at an offshore salary. “This is a globally employable engineer,” I said on the phone, “and we pay him a US level salary in order to retain him.” I continued to recount his work history and track record. The buyer understood and we moved forward with the deal.

What is a globally employable engineer? In my mind, it’s someone that could get a good job anywhere around the world due to demand of their skills. It’s someone with a minimum of ten years of experience, highly talented, with excellent English language skills and some customer-facing experience. The ability to travel when necessary helps a lot, and that means the ability to get a B1/B2 US visa for occasional visits. Such engineers may choose to continue to live in their home country, or elsewhere in the world, but tapping their talent does not come at offshore salary cost.

It is time for the high tech industry to move beyond Outsourcing 1.0, and embrace the Globally Employable model to access the best engineering talent on earth, wherever on the planet they choose to reside.  

Looking forward to the OSLS Half Moon Bay

/in /by

This week, Konsulko Group CEO Pete Popov will be attending the Linux Foundation’s Open Source Leadership Summit in Half Moon Bay, California. The OSLS has always been a premier forum for open source leaders convene to drive digital transformation with open source technologies, and learn how to collaboratively manage the largest shared technology investment of our time. An intimate event, OSLS fosters innovation, growth and partnerships among the leading projects and corporations working in open technology development. Hope to see you there.

New video released of “The Konsulko Story”

/in /by

CEO Pete Popov and CTO Matt Porter talk about the Konsulko Group’s 20-years of experience with Embedded Linux, and introduce the Konsulko team.

Created by multimedia director Alex Vlacos, the video was filmed in October 2017 during the Embedded Linux Conference in Prague, where key Konsulko engineers gathered to give technical papers and demonstrate new technology.

Tag Archive for: pete popov