Engineering “Smell”

In software development, a phrase that gets used frequently is “code smell” – referring to an “odor” that code has or develops due to poor initial design or inattention to refactoring during continued development or maintenance.  Hallmarks of “code smell” include things like copying and pasting blocks of code instead of refactoring into callable functions, classes that have or develop multiple responsibilities, overly broad interfaces, and so on.

I think engineering departments can have smell too. Hallmarks of engineering smell include:

  • teams that develop processes, tools and frameworks with no expectation of coordinating efforts with other teams; effort is duplicated and uneven; autonomy and flexibility are valued much more highly than collaboration and long-term efficiency
  • teams are made responsible for maintaining more active products than they have resources for; the business comes to count on heroics and although many products are offered, quality and response times are poor and competitors have more up-to-date feature sets
  • teams launch “V1” of a product and then are re-assigned to focus on another product; engineers are given limited opportunity to develop architectural expertise before being reassigned elsewhere; sense of ownership suffers; architecture rots in place as only critical patching is permitted
  • teams avoid choosing service or product related names since there is the expectation of frequent product focus reassignment; or in the case of contracting, the business usually fails to win a contract renewal for subsequent work beyond initial efforts (or fails to direct the expertise developed in the contract into their own offerings)
  • career growth is narrowly defined to include skill acquisition only; there are no levels; hiring is limited to a narrow band of experience ranges; mentorship is not a priority since recruiting purposely attempts to hire engineers of similar ability
  • in addition to discouraging technical hierarchy, non-technical career growth is also narrowly defined to skill acquisition; leadership roles available to individual contributors are end with becoming a team lead and are not considered a promotion but a lateral
  • being a generalist is actively encouraged (makes it easier to assign you to something new for the next project) and developing deep architectural expertise is discouraged

This leads to key questions to ask when evaluating any engineering organization, whether you are a part of it, considering joining it, or contracting with it:

  • Against what standards can I expect the engineering organization to deliver? How can I judge the likelihood that the organization can deliver high quality, consistent work across all features and beyond V1?
  • What capacity is there in the organization to take on work? What evidence is there that underperforming products and technologies are regularly pruned to make room for new opportunities or to continue or increase investment in successful products? How much does this organization rely on heroics to make up for poor planning?
  • Who are the architects, the mentoring engineers? What are their visions for the organization and products and the technologies they work with? What evidence is there of allowing people to specialize, to learn and own something deeply long-term?
  • How are the teams named and organized? Are they aligned to products and services? Do they share processes and standards? Is a sense of product ownership actively encouraged? When a product is sunset, how are the engineers helped to find new homes in the organization? When a new project is undertaken, how is it staffed?
  • Are there career ladders — i.e. technical leadership and people management? Are there examples of people that have “risen the ranks” more than a single “rung.” To what extent is first line and middle leadership valued? Is it considered a promotion? Do they hire junior and staff engineers or is hiring limited to senior only? Are senior leadership positions routinely staffed from outside?

It’s the beginnings of a “sniff test” there. I expect I’ll be writing more on this. Comments?

Photo by Csaba Tomcsak from FreeImages

STM32WXX Project

I’ve been working on a ARM Cortex M4 based weather station with APRS transmitter as part of my Masters in Electrical Engineering at the University of Washington. I’m making good progress. It is FreeRTOS based and I’ve gotten all the tasks and queues running and time, location, and weather data flowing. I integrated with the real time clock just to find out that it drifts 5 minutes per hour – looks like I’ll need to periodically re-synchronize that with the GPS signal, LOL.

This is a complete rebuild of the Texas Instruments Tiva based project with a better  sensor for weather and an MCU from the much more popular STM32 family.

Next step is to write an AX.25 packetizer and the modulator. You can follow my progress here or on GitHub: https://github.com/allendav/STM32WXX

NFC and Apple Card

When you get your Apple Card, you’re invited to hold your phone near the card to activate it. I wondered if it was communicating with the card or something in the packaging.

One destructive outburst later, I had my answer. An NFC device inside the packaging:

A quick download of the “Hold” app from the iOS store reveals the simple URL the NFC device prompts the phone to access (and then activate the card):

Embedded LiveWire

The e-moto has five processors to manage performance and app-based connectivity, according to HD’s chief engineer for EV Technology, Sean Stanley.

TechCrunch, “Inside Harley-Davidson’s EV shift with a ride on its LiveWire

I would very much like to 1) own a LiveWire (had the pure joy of a demo ride back in August) and 2) learn more about these five processors. 🙂

My own photo, taken during the Harley LiveWire Demo Event in August in Seattle at the Wick.