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…

Does IT make you productive (or, are you an existentialist or a fatalist)?

26 February, 2005
Requirements, Design
0 Comments

Interesting article in Thinking Faster, just getting around to capturing my comments ... On Requirements "The first reason that business folks don't get what they need from IT is because they aren't sure what they want" The fundamental challenge of capturing and managing knowledge - it's much easier to understand something than it is to describe, document, teach it. Why do so many organizations do knowledge transfer and training by saying "follow that person around for 3 months"? Of course,…

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…

Sell your Boss – Some Tech Observations

30 January, 2005
Business Value of IT
0 Comments

Saw this great post from Hyatt (referred from this blog, definitely worth syndicating) re: how to get decisions / results out of your manager / boss. Great stuff, pay attention to the details here, all of it is right on. A few additions I'd make to the list ... Keep it short - just like you, your boss is juggling multiple priorities, especially when you're reporting to a C-level person. If you can't develop and present an elevator pitch version…

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…

Motivating Maintenance Programmers

7 January, 2005
People Management, Application Development
0 Comments

Interesting conversation today with one of my application managers. As we move into the new year, we're doing some "spring cleaning" of the older projects in our PMO. Two from last summer had languished - efforts to develop simple web front ends for order inquiry and dealer information - and I asked my lead web developer to audit them (make sure we've got source code under version control, check out the tech architecture for the supporting database, etc.) before "closing"…

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,…