Don't Accept Snap Answers Too Quickly
A few years ago, I was working on an interface project, and wanted to have the ERP system send copies of any and all transactions that have changed over the past few days. I've done this before on other platforms, so I asked the lead developer what I thought was a no-brainer request:
- Do the transaction files capture a date/time stamp somewhere in the record, each time the record is modified - DateLastUpdated, something like that?
His answer came back almost immediately ... No. Well, I guess this is possible, but we're working with a fairly up-to-date ERP, and I've worked with enough systems and data bases to know that many/most applications timestamp their records when updating, or maybe write changes to a log file of some sort. And the answer came back just a tad too quickly ... so I asked the question again, but this time I took some time to preface my question with an apology (of sorts) ...
- I mean no disrespect, I am fully aware of your experience and skill on this particular platform - but I need to be clear, because I think I'm asking for something that's fairly basic.
I just need you to be a tad more specific when you say 'the system doesn't do that'.
Is it more accurate to say 'I have never seen the system do that' or do you know for a fact that that the system cannot do that?
It's a subtle difference, but it's important to drill into this level of detail. Most of us are pushed for time and quick to come up with the fast answers, so we can move on to the next item in the todo list. Answering off the top of our head is a pretty normal response, I do it a lot myself, but this was a pretty important feature request because the lack of it meant a ton of additional work in other areas. Besides, I'm humble enough to know there are many features and functions in any platform I've ever worked on that I don't fully understand - never had the need. Plus, I don't see a ton of wildly original thought and unique features in many of these system that we work with. In cases like this, I'm asking for something that I've seen in another platform, assuming that the author of this platform was a reason intelligent person and has added that same basic functionality.
Truth be told - in this instance, the transaction file in question did not have a DateLastUpdated field, and we had to look at transaction logs to get the information we needed. Still, the developer in question had little problem with my pushback; he readily acknowledged that he did not have the layout of this particular table memorized, and had never heard of such functionality - but the concept made sense, and he was happy to look. Besides, if his snap answer was wrong, it would have saved him a ton of work ...
Drilling into the specifics like this (do you know No, or do you Not Know?) applies to more than just software developers. Engineers lawyers, accountants, sales reps - many folks from across the business are faced with questions that they try to answer from their Experience, hoping for the Quick Answer. It takes some confidence to question the "local expert" - but if the right questions saves a ton of effort, searching for a workaround - well, that's an excellent question to ask.
Previously ...- Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
- Making the internal pitch? Learn from the entrepreneurs (October 10, 2005)
- Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
- Misapplying the Pareto principle (January 7, 2006)
- Beware the Self Fulfillling Prophecy (May 23, 2006)
- Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
- War Stories from the Change Management front (August 21, 2006)
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
- Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
- Communication is the responsibility of ... (August 19, 2007)
- Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
- PM Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
- Innovation That Matters - Substance Over Style (January 12, 2008)
- Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
- Why are those Old Programmers so slow in picking up on the Intarweb? (April 6, 2008)
- There ain't much IT in IT Management (May 7, 2008)
Technorati Tags: best practice, collaboration, design, development, hands on, people management, project management, tech management,
Labels: application development, collaboration, development, hands on, innovation, project management
posted by James P. MacLennan at 9:53 PM
| Permalink
| 0 Comments
