Challenges when demoing / training / pitching complex systems

Over the last few days, I've been in a few vendor demos, trading partner reviews, product pitches, and project discussions, all reviewing complex systems or processes, and tools / software / services to help out. Some important, common, and somewhat random issues kept popping into my mind, all about trying to have a discussion about complex systems / interactions ... Always be mindful that if something was easy, we probably would have done it already. Be alert for things that…

Bug bad, bug good, bug Bug

Rothman suggests we use the term Defect, not Bug - as if Defect is a more honest / real word, and Bug is somehow more evasive, non-descript. Au contraire - my guess is that Ms. Rothman does not have a programming background! When you say to a Programmer that their software has a bug, they typically take great offense; I remember how fast a consultant turned from smooth professional to defensive techno-geek the instant I suggested their work product had…

Pendulum swings – Santayana says …

I saw Stewart's article on customized software in ComputerWorld this week, and googled (Googled?) a bit more and found a pair of good posts from Scavo (Keller/AMR started it all), speaking of an apparent trend back to favoring custom-built software in business today. A few thoughts ... A classic blunder made by many corporate IT groups is to buy into the idea that custom software is easy. It's certainly fun - much easier to develop a brand new piece of…

Chicken and egg aggravating? Just start somewhere …

Conversations this week with folks in multiple, different organizations I have connections to, about formal change controls. The general rule, especially for the non-public companies, seems to be reasonable levels of process, but not as well documented, automated, and not as rigidly enforced as the more rigorous among us would prefer. It was interesting talking with the groups that were most frustrated; the developers will talk the talk, but find ways to get around the process when crunch time comes…

If you want to be more than a programmer, stop programming

A lot of talking with the team yesterday, and I have a sore throat because of it - but we covered some pretty key concepts, stuff that is hard to reconcile in many tech staffers' minds, but must be dealt with. One conversation covered this person's desire to be thought of / leveraged as "more than a programmer". "That's great!" was my response -"... then close the issues that are getting assigned to you - without programming!". Recently, I am…

I have nothing to say and I am saying it and that is poetry

(attrib) I was in a meeting yesterday - first time with this particular group of folks, all at same time, on this topic, although I had already established a working relationship with all. Anyway, subject matter was one that most of them had talked about at length over the past few weeks, but I was a new addition to the mix. Suffice it to say, I didn't have too much to add to the conversation, not until the very end…

Communicating Complex Technical Concepts

We've faced this problem a few times, as we roll out a distributed application across a network of remote locations. A fairly typical challenge is to explain the impact of a technical architecture improvement in a relevant, meaningful way - without resorting to techno-jargon. A good approach includes: Keep it short - Too much detail and you will lose them. Find the balance between enough information to be valuable, but not so much as to be boring Focus on the…

Fractal Business Issues – Katamari Damacy at Work

Business issues / problems are like fractals. You can drill into the details or see things at a high level. The trick is to be able to understand what level you are looking at, and what level other folks may be at, and the relative difference that can contribute to missed communications. Some conversations at work this week have been interesting, and in hindsight I realized that I was seeing priorities / objectives / issues at one level, and my…

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

25 January, 2005
Tech Management, Hands-On
0 Comments

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…

Interesting Design Sessions

Had two interesting design sessions yesterday, both of which got me thinking / observing ... Push to Prod A team of techs, working in a Unix / Progress environment (QAD MFG/PRO eB2), reviewing our plans for improving our Dev/Test/Prod cycle for controlling / auditing the movement of source between environments. A little history - we didn't get off to a good start because of two key mistakes: Mistake #1: We started with the concept(s) of Development, Test, and Production environments,…