Your feedback is appreciated ...


The good and the bad about being a hands-on tech manager

Interesting project that I have to take a deep-dive on this week – has to do with automating a piece of barcode printing software, and integrating it with a newly developed labeling process out in the shop. Project was hitting some significant snags, and I was asked to step in. Here’s where hands-on software development skills are a boon and a curse …

The perception is that we’re trying to get the forms software to work in a certain way with the scanner; we’d like to minimize the interaction with the keyboard and eliminate the need for the mouse.

Note: Classic problem with the focus on GUI interfaces – everybody makes their forms / software work with a click of the mouse. Problem is, folks in a shop environment do not want to have to stop, find the mouse, find the cursor, click the button – it just slows them down. Sorta the same thing with data entry folks – they learn their keyboard and become quite fast, so make sure the app can be easily navigated using only the keyboard. Also – you’ll need to / be able to mimic keyboard entries with the scanner (and you can’t mimic mouse movements with a scanner).

Boon: Knowing how to anticipate user calls and complaints, and how real people interact with software, is a soft skill you can never underestimate.

Curse: Ya gotta be careful not to take over a developer’s effort, as they want to be able to express their own experience / develop their own skills.

The feeling was that we were struggling with the forms software and it was buggy, and I was asked to push the vendor for some tech help. First step, however, was to get a better, cleaner definition of the problem.

Note: Benefit of experience speaking here … this vendor is not a huge software house (heck, the stuff was written in England, these guys are just a VAR), and I knew we’d get little direct help – no bandwidth, not a hugely expensive piece of software. My actual approach was to define the root issue very simply, as we could probably devise a workaround or fix a bug in our thinking / implementation that was lost on the details.

Boon: When you know what it’s like to be on the receiving end of these “help me” calls, you know how to pose the question to get maximum results when you finally do get a tech support person on the line.

Curse: Here’s where I start getting sucked into the details of the project, which is good (because it’s a strategic effort and we need to get back on schedule) and bad (because it’s taking me away from 3-4 other key things on my todo list).

So, we developed a single form, with a single data field and single button. The goal was to get the scanner to fill out the field and press the button to print. The trick – and we sorta reverse-engineered / trial and error’d on this – was that the data field does not save your input until the field sees a LostFocus event. “Pressing return” (via scan) to make the button go does not gen this event, but mouse clicks and keyboards do.

Note: Even though the software has VB Script, it did not expose any objects, properties, or methods for us to program / change / trap. Still, knowing how Visual Basic or similar would work, we use those concepts to express what is happening.

Boon: Hands-on programming experience helps you develop a very specific definition of the problem; soft skills are required to make sure we clear away / remove all variables that don’t have anything to do with the root problem.

Curse: This is more of a curse on the project team – when I get involved to this level, I am “looking over their shoulder” in excruciating detail, and they cannot hide behind techno-jargon.

Turns out this makes sense if you imagine how a form with multiple fields would / could / should work. Bottom line, we realized the end user will have to scan the label (which will automatically tab to next object [field or button]) and then scan a code to hit enter.

Note: When analyzing how the software works, you can’t limit your thinking to how we want it to work; have to understand why it was designed this way – possibly for other / more complex / different forms?

Boon: Experience allows you to draw on old programming / implementation projects for examples of different ways to do forms / scanning / data capture (for example).

Then, we found out that the mechanics of the forms processing software did not give us enough hooks to add code that did what we wanted – like blanking out an input field and positioning the cursor wherever we wanted. The forms object is not exposed enough to us – only simplistic VB Scripting allowed. So, we opted to punt and scramble to create an Access mini-application that will manage the read/write to the database, plus the screen actions that we want.

Curse: Nothing like realizing in excruciating detail that we’ll have to toss out a good chunk of code and do a rewrite using a different “platform” – MS Access, in this case. Still, it’s nice to have that kind of back-up solution in your pocket.

That was all yesterday. Today’s task – to see how fast we can completely rewrite the basic application!


No comments for “The good and the bad about being a hands-on tech manager”

Post a comment