had a nice reminder about some simple testing techniques with a stopwatch/log file timestamps.

we are working on a distributed webapp that includes normal ejb/sql persistence, an in-memory jena semwebby set of models (triples+1), and blaze rules.

with some creative use of killing the development server to clear memory, running code to clear tables, and including or excluding running rules, we had the makings of some simple macro-level tests.

what we found was that consecutive runs caused a linear growth over time. Hmmm.

well, “consistency is a quality all to itself” i always say! at least the performance issue can be tackled and measured and improvements can be detected.

Turn off rules. We found that running rules caused a discrete delta performance hit. Allowing the database to grow had negligible effects on performance.

two new issues in jira!

• keep the in-memory jena models cleaned up after their use is no longer required.
• examine performance issues around rules

it is funny how easy one can get fooled by apparent coincidences in software development troubleshooting. three people. three similar issues with getting an app up and running after, apparently all pointing to the same culprit jar file.

things worked on friday… did an update on sunday, errors. yet the system works fine on the dev server. hmmm.

upshot was that fred’s error was that he was running his own build (i’ll save commenting on that for another blog post), and didn’t even have the jar. but since he knew i had the same apparent problem, he became fixated on some other cause.

my error turned out to be really weird copy of the directory in a weird location (that i didn’t even think of looking in!). how that happened, i dunno. i will attribute it to my lack of prowess on my new mac and i probably screwed up some linux command.

fortunately, tim came to the rescue and helped me find my error. quick directory deletion, i was back in action. his manifestation of the error was yet a third incarnation.

but on the surface, all errors pointed to the same jar file. when in reality, it had nothing to do with that specific jar file! beware rabbit holes and trick mirrors!

we were discussing how simply being “in the same room” is not enough to make for a successful project. I contended that a distributed team can force the issue of doing best practices in terms of collaboration and being very visible.

when i worked with a team in St. Petersburg, RU, I would be onsite 2 weeks per month. i would have been more effective being onsite 100% of the time. (We were developing software products at TogetherSoft.) However, being a distributed team meant i had to increase the level to which we ensured we always worked by being open, communicative, and extra visible. so, we were more certain to have collaborative tools…

• tools to control the features — not a bunch of cards physically limited to sitting in some room.
• models and design ideas on wikis — not just on a whiteboard
• design by interface to avoid dependencies whose impact can be exaggerated in distributed team dev
• web meetings to discuss items with the team (usually said documentation and design ideas)
• plans and progress visible in wiki

the benefit? this not only served the local purposes of the team, but it was useful for anybody else who might be interested, or who wished to collaborate — without having to be in the same room (or continent). Also very useful for newcomers to join the project mid-stream.

some teams would be content with doing just enough to meet their local needs. which is fine. (an extreme example might be a solo developer that does not docs or design or project wiki.) my point was that if you want to succeed and you are doing distributed team dev, you better adopt some best practices that help keep everyone on the same page. this can lead to a distributed team having to go further than a local team would in terms of building a collaborative workspace and artifacts. Obviously, nothing precludes a local team from doing the same activities, it is just that a local team need not to it to succeed; whereas, a distributed team lives and dies by proper collaborative techniques and tools.

so, while a local team can do the same level of collaboration as a distributed team, they do not have to, and often do not. the converse is not true. a distributed team will quickly fail if good practices are not followed.

maybe a corollary to my point… if you cannot do development well locally, you likely will not get any better results when you add in 12 time zones.

we have been doing agile development with teams across 4 continents now… with success. sure, sometimes i wish we were together, but skype and other techniques can help bridge the gap.