Thursday, July 5, 2012

Things you don't Learn in College (#1)

In 2004 I got my degree in Computer Engineering from Portland State University.  When I graduated, I was lucky enough to get a job in my field right off the bat.  With 8 years of Embedded System experience behind my belt, I often look back at what I never learned in college.  To get myself to write in here more frequently, I will take my time and write a series of posts about what I do on the job now that I didn't learn in college.

At PSU, and I bet at most college undergraduate Computer Engineering programs, you don't learn about Bill of Material (BOM) management.  And by BOM Management, I mean part numbers, model numbers, assemblies, sub-assemblies, engineering change orders (ECOs), etc.

For pure, high-level software development, this isn't necessary.  Your software is installed on a operating system, there isn't parts to keep track of.  But when you are writing hardware specific software, understanding how part management and change control is essential.  IE: When your firmware is ready for production, how do you add the binary release to the PCB BOM?  If you need to revisit a binary release from a past product, how do you pull that up?  How do you trace that binary, contained (often as a document) in a BOM, back to source control?  How do you get the exact manufacturer part number and spec of a sensor your software controls?

I remember the "on the job training" when I started at LogicPD, which involved using Agile (now owned by Oracle) and having a huge headache trying to understand how each part on a PCB has a part number, part numbers are grouped in a BOM, which also has a part number so that can be contained in another BOM.  This creates a hierarchy.  Then - change management, when you rev a part number versus create a new part number, and assessing whether a new part is form fit or function equavilient of an old one.  Sprinkle in manufacturer part numbers associated with internal part numbers, and reving a part number of BOM with an ECO.

A class or two on this would have been probably a little more important than say, the year of solid state physics I took.  I remember this series of classes being rediculously specialized.  It would have been great if I were getting a PHD, with a career of being a wafer/silicon scientist.  I guess it goes to show who PSU's biggest doners are (ahem, Intel).

Okay, stay tuned for more!

2 comments:

  1. Nice post! I lament that so few engineers get out of college understanding the practical aspects of engineering like BOMs, ECO, part specs, distributors, manufacturers, etc.

    To me, these are all aspects of the job that go beyond the technical (how does one design an 'X') and into the social (how does one create a team of people that designs, builds and supports an 'X'). It might be unfair to blame a college for not teaching this stuff - it's not technical, and it's not something that's going to have pat answers that can be objectively graded. Every company / team is a little different.

    The SW guys are starting to embrace this social stuff in terms of tracking bugs and sharing source code (version control), but it seems like the other engineering fields are either welded to the past ("we use paper drawings for everything because they worked so well on the panama canal project") or simply don't see an issue.

    In my current job, I've been in conversations with the head of sales trying to convince him that it really was worth his effort to tell the customer that we use a common source code base for all of our software; software builds come from a single repository of code. The old approach was that the source code for machine X resided mostly on machine X, and on the laptops of the last few engineers who worked on machine X. Machine Y was different, and no one could say exactly what those differences were. Welcome to hell.

    ReplyDelete
  2. Thanks for the feedback Kelly!

    I think I could have used a better word than "BOM Management". Maybe manufacturing concepts? Or production 101?

    I think it is a balance of a school teaching trade skills versus raw concepts/knowledge.

    I won't comment about that battle and whether or not I have or am currently going through it :)

    ReplyDelete