Even when using TDD, there comes a time when the inevitable occurs that you need to run the application and see how the changes you made effect the application in whole.
In the application I work on, it is very large with a environment that is large and brittle. When I need to run the application, I dread it. About 25% of the time, you need to overcome other problems to get to the meat of your testing. Some of these problems can be overcome by getting a newer version of the source code. Some of these problems can be overcome by getting newer binaries of "second party" DLLs we use. Some problems are within the database or web servers, so it get outside of your control.
This is what I would like to dub "Marco Polo Testing".
Marco Polo Testing - phrase - The act of executing a large piece of software to test a single aspect of it. Upon trying to arrive at the single aspect, you encounter many different unexpected situations. None of these situations were predictable, you have little to no control over any of them. By the time you arrive at the place in the software you wanted to test, you've forgotten why you were going there.
From wikipedia, Exploration
Exploration is the act of searching or traveling for the purpose of discovery, e.g. of unknown regions, including space (space exploration), for oil, gas, coal, ores, caves, water (Mineral exploration or prospecting), or information.
The term can also be used to describe the first incursions of peoples from one culture into the geographical and cultural environment of others. Although exploration has existed as long as human beings, its peak is seen as being during the Age of Discovery when European navigators travelled around the world discovering new worlds and cultures.
In scientific research, exploration is one of three purposes of research (the other two being description and explanation). Exploration is the attempt to develop an initial, rough understanding of some phenomenon.
Monday, May 14, 2007
Friday, May 11, 2007
verbiage
my friend and former co-worker, jay flowers developed a strong aversion to our workplace based upon his continue frustration of how stupid we acted. (well, that's my take on it). one of ironies within the irony is that jay came up with these on his own, but he was one of the worst spellers (self-admittedly) i ever met in my entire life; no, he is the worst.
anyway, he used verbiage that was off-the-wall, teaching me phrases such as "the forces", "oral tradition" and others.
since he has left our place where we gather from 9-5 in exchange for u.s. currency, and i have tried to keep his legacy alive and i amuse myself with some of the verbiage i come up with to describe the silliniess of our plight/condition.
i also am trying to find things to post here on a daily basis that document my walk across this this third rock from that star.
so here it is, the 1st in a series of pretty gosh darn funny (at least it amuses me) verbiage i have taken to using around my workplace.
preface: we build software consumed by someone who runs it by a 3rd party 1st. this 3rd party independently tests it before the end consumer accepts it. sometimes, these release get stuck with the 3rd party for a long, long time.
i said today, "there is code to support unit test in the production code".
one of my peers question, "in production, like the users have it???".
"well, released code," i said.
"oh, ok, not in production.", he said.
"ok, well, we released it, let's call it shelf code, then.", i said. and the term "shelf code" was born.
shelf code - noun - code that has left the building, staged to be deployed to the end users, but probably will be in this purgatory for a long, long time.
anyway, he used verbiage that was off-the-wall, teaching me phrases such as "the forces", "oral tradition" and others.
since he has left our place where we gather from 9-5 in exchange for u.s. currency, and i have tried to keep his legacy alive and i amuse myself with some of the verbiage i come up with to describe the silliniess of our plight/condition.
i also am trying to find things to post here on a daily basis that document my walk across this this third rock from that star.
so here it is, the 1st in a series of pretty gosh darn funny (at least it amuses me) verbiage i have taken to using around my workplace.
preface: we build software consumed by someone who runs it by a 3rd party 1st. this 3rd party independently tests it before the end consumer accepts it. sometimes, these release get stuck with the 3rd party for a long, long time.
i said today, "there is code to support unit test in the production code".
one of my peers question, "in production, like the users have it???".
"well, released code," i said.
"oh, ok, not in production.", he said.
"ok, well, we released it, let's call it shelf code, then.", i said. and the term "shelf code" was born.
shelf code - noun - code that has left the building, staged to be deployed to the end users, but probably will be in this purgatory for a long, long time.
Thursday, May 3, 2007
Data is a mess
Found out today that the MB labs data is a utter mess. Everyone blames on people that are no longer there. But, everyone there has allowed to continue to be that way for a long time (eight or more years).
Going to try to straighten some of it out, not the data, but the way it's striped off and put into the entities.
Going to try to straighten some of it out, not the data, but the way it's striped off and put into the entities.
Subscribe to:
Posts (Atom)