tag:blogger.com,1999:blog-8951904624959546499.post8829610072651109398..comments2009-01-30T12:02:06.846-05:00Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8951904624959546499.post-27758259697081101652009-01-30T12:02:00.000-05:002009-01-30T12:02:00.000-05:00Thanks for your thoughts, Tripp. Yes, it is a "natural" way of communicating. <BR/><BR/>Now that you've spent a fraction of your brain on this, you'll have no problem noticing it.<BR/><BR/>You'll just have to decide if it's worth the effort.Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-23249517986881016962009-01-30T11:29:00.000-05:002009-01-30T11:29:00.000-05:00I hear what you're saying but I also think it's quite natural to speak like that, particularly when dealing with entities that you created or helped create. It really implies a sense of ownership and pride in what you do as well as defining what you are responsible for. And maybe that's the problem. <BR/><BR/>Developers are a very logical bunch(duh). We have to know where the boundries are because if we step over that boundry then it can cause problems in other parts of the code. When a bug is found in the code you wrote, there's no one to blame but yourself. Mabye too much compartmentalization. So if it's NOT your code that has the problem, you instantly recognize that as "they".<BR/><BR/>Once looking at a broader picture, it's harder to shift gears and see the problem within your circle of influence rather than outside it.<BR/><BR/>But all in all, I do agree that it would be better to try and speak more clearly. The hard part is recognizing when you are doing it.Trippnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-66157525492923220432009-01-30T08:40:00.000-05:002009-01-30T08:40:00.000-05:00Ah, good story, Michele. As long as we understand how the apps work, we can gather lots of info using our own little simulations of the real world, even if we have to break a few rules to do so.<BR/><BR/>I’m glad you liked this post. I was distracted all day yesterday, listening to people describe various scenarios between the many apps that support this place. I kept finding myself clarifying, “when you say ‘we’ process the file which module do you mean?”. <BR/><BR/>And the devs are the worst! It’s like their code is them…”When I get the data, if I see a null value I return a fault. I’m not sure if they do anything with the fault when I give it to themEric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-43073504841183790812009-01-29T18:52:00.000-05:002009-01-29T18:52:00.000-05:00Hi Eric,<BR/><BR/>You are definitely right about how personal the people involved in integrated products make their applications.<BR/><BR/>I actually just sat through a meeting today because of the very same thing. There was, however, one major difference. The controversy that began because I took the liberty of installing both applications on my machine to test. Months of confusion and about 100 email chains later, a meeting was called. I realize what I did changes the scope of what would "normally" be considered integration testing, but it gives me a clearer picture of what I am testing. Apparently it gave others heartburn as it really messed with the "definitions", tester roles, test plans, and status quo of the organizations. <BR/><BR/>Fortunately at the end of the meeting my civil arguements won out and I can continue to do what I have been doing without my hands being tied. I explained the value of it and how it would not really be overlapping in test efforts since the reasoning behind me testing this way was to provide my own data and have a better understanding of what the customer will encounter in the entire process, not just "does this data work". How can I even imagine what the user sees if I don't see it myself? What happens if the data is not pre-planned for the integration? What if mistakes are made by the customer and those end up in the files? Etc. <BR/><BR/>It does help to remember that at the end of the day either the stakeholders and customers are satisfied or they are not. "We" can work toward that a lot better than "Them" and "Us". <BR/><BR/>Good post!Michele Smithhttp://www.blogger.com/profile/05639189538178022310noreply@blogger.com