The day begans like any other. Wonder into the office around 9am. Greeting a few coworkers before settling into my desk. Opening up Gmail to check what fires need stamping out and taking a tour through the calendar to learn about the day’s meetings. Eight meetings today. More than I like to see, but nothing terrible. I update my to do list with any critical information I think I need to gather prior to the important meetings, and then grab my mug and make my way to the cafeteria.

I grab a cheese stick from the cooler and get in line at the coffee machine, making small talk and catching up as I wait for my mocaccino. I love the fancy coffee machines that work has. With caffeine in hand, I walk to my first stand-up. The Product Security team is small, with only three developers. They are embedded in the other Scrum teams to provide their expertise when necessary. The meeting passes without incident, so I make my way to second standup, the engine team.

The engine team is larger, with 8 dedicated developers and 3 quality assurance people. I learn about unexpected complexity for one of the important projects and that a key developer will be out next week, meaning I’ll need to re-examine story alignment and delivery time frames. I make a note of the two.

Off to my third stand-up. Thankfully this is the once a week meeting along all us product owners, so we can keep one another abreast of our project status. Mostly to track interdependencies and knowledge share. Next week’s release is being pushed a week to make space for a critical patch to an older version. Good news for me, extra buffer room so the testers will be less rushed.

After a brief half hour at my desk to catch up on emails, I head off to a story-authoring meeting. We met last week to draw up the story map, detailing the various ways the project personas would interact with the feature. Since then, I’d broken the map into pieces and wrapper stories around the different portions of functionality. Presenting to the group, we reviewed the requirements and scopes assigned to each story. Some past muster, are sized, and added to the backlog. Others are deemed too vague, too large in scope, or we are still waiting on final UI mocks, and are left in the authoring state. Overall, a good meeting, productive.

Lunch: Indian take out, can’t be beat

After lunch I run an uneventful chartering session for the next medium sized project for the team. There is a little contention defining the extent of the build out, and eventually everyone agrees on the phase 1 work and what would be put off until the next phase.

This is followed by two back-2-back, one-on-ones with my product managers. Who are both unhappy we are “behind” schedule. Once again I repeat the discussion of the sized work from developers on the story and the amount of calendar time required to build it. If they want it sooner, what part of the feature do they want cut… Oh, you still want everything? …

With my mid-afternoon coffee, I settle into my desk to pound out the story delta from the authoring meeting this morning, clean up the chartering document, and chat up the user experience people over instant messenger to get a rough idea on when their work will be done.

I review my updated to do list from the days meetings, schedule a follow up authoring meeting from this morning, a new story mapping meeting from the charter that I ran, and turned by attention to reviewing the project backlog for my team. One project has been fully passed onto testing, three are making good progress, and I update the state for one from backlog idea to “authoring” to mark the transition into the authoring state.

Last meeting of the day, QA hand-off. We start the meeting with my re-presenting the story, describing the need for the feature that was built and my criteria for validating the feature works as expected and the environments it needs to work in. The developer takes over, describes the new settings, how to access the feature, and provides a short five minute demo of the feature. They then cover a few edge cases they ran into that they’d like QA to take a closer look at. Successful hand-off, great end to a busy day.

I stop by my boss’s desk to chat for a few minutes and reflect on the days work. I then grab my backpack and head home. Glad to have the day’s work behind me, happy to know everything is progressing smoothly. At least as smoothly as one could expect a software project to go. I think to my self, being a Product Owner isn't so bad.

For the past month, I’ve been working part time on a Microprocessor selection tool (micro-tool) that my company plans to use to reduce the time it takes to run a trade study for selecting microprocessors for new projects. The primary aim of the program is to encourage/ force the technical leads to re-use processors from old projects to reduce the learning curve of new parts. This will facilitate code re-use, will allow re-use of existing compilers, and will decrease the time to a final schematic layout. (Surprise, parts often don’t work exactly like the spec. sheets state, and prototype boards must be built to discover differences between real parts and the spec sheet.)

I was the third developer to work on the code, the first being an intern who left at the end of last summer; the second was a junior developer who was let go during layoffs in November. Needless to say, the code was not in great shape. I spent a day looking over the code, held a meeting with the project sponsor, wrote up a short requirement description and got to work.

After two weeks time, the program was running. Searches returned the correct data, the user could enter their trade study criteria, rank the various results against each criteria, and everything was exported to an excel spreadsheet so the artifacts could be archived for future reference. The project sponsor was thrilled, “Now, let’s get this running with the production database tables…”

“Tables?” I asked. Turns out, contrary to what everyone had said previously, the micro-tool would be searching not against one table, but five. Furthermore, the five tables were not homogeneous.

1. Same type of data was encoded with different data types in different tables. Integer in two, floating point in two, and a string in the last.
2. Values were stored with different scales. RAM size was stored as bytes in four tables and as words in the fifth.
3. Key search values, such as ROM size, did not exist in all five tables.

Liberal usage of projecting new columns, renaming columns, and unions allowed me to extend my search routine to all five tables within a day. In a similar amount of time, I extended the display portion of the program to notify users from with database table a result originated.

I recommended merging the various tables, or at least fixing the data types to make them the same across all tables and was given a big red light. Supposedly, there are applications that the electrical engineers use that are tied to the current schema, and they don’t want to risk them breaking. Even after I explained how database views could be used to prevent changes in existing applications. While taking advantage of adding data consistency to the database. It would help if the database administrator was a trained in database management, instead of electrical engineering.

The other day I ran into a very strange issue while debugging a problem at work. We were evaluating a new microprocessor for use in one of our products and had been trying to exercise all the different functionalities the processor had to offer.

I was testing out the input capture functionalities and discovered that the first capture (rising edge of input pulse) always worked correctly, but the second edge was never detected. After some digging, it appeared as though the I2C communication routines were interfering with the capture.

I turned on debugger, ran code and it broke inside the I2C routine, hanging waiting for a reply which was never going to come (test code had no time outs). I commented out all calls to the I2C code within the program, reran it, and the debugger once again broke inside the I2C routine. Somehow, the program counter was jumping to an unused block of code. I know it was unused because the compiler complained about the unused segment.

Putting on my debugger hat, I placed a break point immediately after the first capture, and stepped through the code, one line at a time. On the following line, something strange happened

counter += 1;

Instead of advancing to the next instruction, the program jumped almost to the beginning of memory (15 bytes after the end of the memory mapped register range). I repeated this several times, always with the same result. As an experiment, I rearranged a few lines of code and reran. This time, the code jumped on a different line, but landed in the same location.

The only thing I know of in microprocessor land which can change your execution point is a faulty processor, or more likely, a interrupt occurring. After poking though the map file, I realized the I2C routine was the first executable block in code, and the decoded instruction 0xFF which fills all unused space is a move instruction.

MOV A, B

It makes sense, that a bad jump into unused space would eventually land the code in the I2C routine, but that was triggering the interrupt? A five minute search yielded the solution.

The code we were using was based on example code provided by the vendor. I hacked the various pieces together and changes from interrupt driven function to polling driving functions. Unfortunately, I missed the line in the initialization routine where the input capture interrupt occurred. Most surprisingly, the compiler allows us to enable an interrupt, without defining an interrupt handler. (In this processor, all interrupt controls had direct bit access. They were not grouped together requiring a byte mask.)

The interrupt event occurred and the program counter was loaded with the default value from the interrupt table. We have no idea how 0xFFFF from the table was translated into 0x034A which is where execution picked back up. Commenting out the interrupt enable line resolved our issue and we were able to finish evaluating the board.

Morals:
1) Interrupts are evil. They introduce too much variability into the execution process.
2) Sample code is a great place to start from, but don’t base your demonstration code on it
3) Debugging takes time and patience, take a break once in a while to relax and clear your thoughts

I first encountered the concept of unit conversion in the second grade. Where I was taught to convert pints to gallons, feet to inches, and ounces to pounds. Event with constant practice, there were a few units that I was just never able to get, such as the peck, fathom, or the hogshead. It amazes me to this day, that these units (all of the above) are still in use, when there is a clean, simple unit of measurement that has been accepted by the majority of the world: SI (metric).

Having a mixture of different methods to report the same concept (different units) introduces many engineering challenges. Primarily, one needs to be constantly vigilant when reporting data or receiving data, that the data has been properly labeled with the correct units. All data sheets should have standard locations to list units and software APIs should explicitly and cleanly state units on parameters and returned values.

The most famous example if software routines using the wrong units was the Mars Climate Orbiter probe that crashed due to a software conversion. In a nut shell, a routine was called to determine the amount of force exerted by the space craft thrusters after firing. The exerted force was factored into the navigation routines to determine the craft's new trajectory as it guided itself towards mars. The trajectory routines expected data in newtons (metric force unit) but was given thrust data in pound-force (imperial force unit). This resulted in a small amount of error each time a course correction was performed. Over the multi-million mile journey to Mars, the craft drifted roughly 45 km. A very small distance, but large enough to spell doom for the craft.

Earlier today, while sitting at my desk I overheard a conversation between two of our system's engineering engineers, taking about a small collection of requirements they had received from one of our customers. The two requirements dealt with the types of storage environments our final products would have to survive (temp, humidity, dust, ect). One in particular caught my ear. The requirement was worded similar to as follows:

The device shall not be damaged by dust particles, 100-500 micrometers in diameter, traveling at 50 mph.

Hearing this stopped me cold; one requirement mixed two different systems of measurements. I pointed this out to the guys and they laughed. Then they showed me an even more distressing requirement.

The device shall do something at either X g/ft or Y g/m^3.

In this instance, not only were systems of measurement mixed, the two provided units could not be converted into one another. One was mass per distance, and the other was mass per volume. I got assurances from the requirement guys that they would have the customer clarify what they meant. I then took a drink of coffee, put my headphones back on, and got back to work. My first order of business, verifying I'd documented all the units for my public facing routines in my code.