Building Superior Embedded Systems
12 December 2023 by Phillip Johnston • Last updated 14 March 2024Fantastical schedules are a common problem we (and many others) experience. These are schedules that are completely unrealistic and usually known to be so. However, some influential portion of the team/leadership insists that the schedule is valid and must be met. Even if the “drop dead” date is valid (e.g., the company will run out of money), the reason is rarely communicated to the team. There are several causes that can lead to fantastical schedules. Multiple may be present at any time. Arbitrary Schedules Created by Management Schedules Rely …
Continue reading “Fantastical Schedules are an Industry Problem”
12 December 2023 by Phillip JohnstonEven with the best documentation, those who originally created the product are usually better at fixing/modifying it than their replacements. This is because they hold context and design paradigms within their head that may not have been documented or effectively communicated with others. However, there are limitations: People forget, which means that an original creator may be no better than one of their successors after time has elapsed. Fundamental concepts and design goals change over time and/or may have been invalidated by successors, rendering their knowledge useless. As the original development team cycles off, software …
Continue reading “Original Creators Are Better at Maintaining a System Than Their Replacements”
12 December 2023 by Phillip JohnstonAll software will age, and all systems that last long enough become legacy systems. But even knowing this, we don’t tend to emphasize maintenance when teaching new developers. So much of the material is focused on creating new programs. But this misses the fact that most of the work we do is maintaining – fixing and extending – existing programs. In fact, maintaining existing software will often be the first thing that a new programmer does, with developing new software from scratch coming later. We need to teach developers the necessary software maintenance skills, since …
Continue reading “We Don’t Do a Good Job of Teaching Software Maintenance”
7 June 2023 by Phillip Johnston • Last updated 12 June 2023Building and shipping an embedded system requires coordinating efforts across several disciplines: mechanical, electrical, firmware, backend servers, application software – just to name a few. You can’t ignore any of these factors if you’re going to ship successfully. A common challenge is that the leadership for an embedded product, especially at an early stage company, tends to be biased in one of two directions. These biases result in situations that I’ve repeatedly witnessed in my career. Hardware-focused (whether a mechanical or electrical engineer) Hardware development and build dates drive …
Continue reading “Successful Embedded Product Development Requires Well-Rounded Leadership”
Continue reading "Q&A: To What Degree Should We Understand Other Disciplines?"
10 March 2023 by Phillip Johnston • Last updated 5 April 2024 We’ve encountered a pitfall at several companies: developers and maintainers were viewed as two separate classes of people. The development class would be responsible for building new systems and getting them to the “shipping” point. One the project shipped, they would help with initial EFFA and debugging efforts. Following that period (perhaps ~3 months), the team would move on to a new system. At this point, new people are brought in to maintain the system and improve it from that point forward. This creates a number of predictable …
Continue reading “Anti-Pattern: Creators Don’t Stick Around for Maintenance”
8 December 2022 by Phillip Johnston • Last updated 14 February 2024“Not Invented Here” (NIH) syndrome is a significant problem for technology companies. NIH is a tendency to avoid code, products, standards, or techniques that come from outside of an organization. With software development, NIH is often associated with the idea that your internal team could do a better job, with a higher quality result, and incur a lower overall cost than any existing solution. In today’s market, you can purchase or find open source solutions for large portions of your system, including supporting infrastructure. You can buy pre-certified radio …
Continue reading “Not Invented Here Syndrome is a Business Problem”
10 January 2022 by Phillip Johnston • Last updated 7 November 2022Collectively, as an industry, we seem to pride ourselves on “overwork”. We brag about how hard we work, how many late nights and weekends we spent getting something out. We brag about the sacrifices made to make something work. This is madness, because software development and system design are creative tasks. This culture of overwork is actually reducing the effectiveness of software developers: Overwork reduce the quality of our creative thinking Overwork increases the rate that we introduce errors into our work There is an upper limit for time …
Continue reading “The Industry Prides Itself on Overwork”
22 December 2021 by Phillip Johnston • Last updated 29 October 2024We often hear the advice that “well written code doesn’t need documentation” or “write code so that comments are unnecessary”. These statements ignore the fact that code is much harder to read than it is to write, even for skilled and experienced developers. As you’re writing code, it all makes sense in your head. You have all of the details at the top of your minds. You have a clear picture of the problem you’re solving and the reason you chose that particular implementation. The “self-documenting code” you’ve produced …
Continue reading “It’s Harder to Read Code Than It Is to Write It”