This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Remote Development Panel
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Panel: David Buck, Dan Antion, James Foster, Avi Bryant, Niall Ross, Dave Pennington
The panel introduced themselves - all are (or have recently) been doing remote development. Dan starts off - anything to avoid? Dave Buck - if the end users are remote, it's much, much harder to get good feedback. Hmm. Vendors all face this, so it's nothing new. James Foster: That's a business model issue, not a development problem. James reiterates the point I just made - if you are a vendor of any sort, your end users are all remote. To his mind, very little changed, because the vendor is already remote. Niall - Agrees with James. Any Agile project can be maade remote, but the people really should meet socially first - it will help to get rapport up. Hmm - BottomFeeder and TypeLess were developed over an IRC with no meeting beforehand. How much open source work progresses that way? David P - Doing commercial development when the remote folks are across a border creates its own problems. Most of his problems have been hardware based - no easy way to replicate the environment from a remote spot. James Foster - equipment issues really depend on your corporate set up. If IT makes it easier, it is. If they make it harder,. it's not. Niall - in that situation, we have a remote connection setup. David P - this case was with a customer who bought a cheap component, no prior relationship. It was supposed to "just work". Avi Bryant - Is there a scale that cannot be crossed remote? No, Open Source (my point above) manages projects like this remotely. Squeak, for instance, has 50 developers, all remote David P - but, it would have gotten harder the more detail the customer wanted to get into. Willing to work hands off made it easy Avi - We have cases where we have real design discussions - they take longer due to time/distance. Email is less efficient. Things spread out over time
Dan Antion - time and design is just where we wanted to go next. How does that go? We do small things remote, but large projects with design? James Foster - yeah, that's how it's commonly understood. Partition the tasks and farm it out (as per outsourcing). (of course, this is one of things that Scott Ambler warned against). Projects are laid out to encourage long distance interactions in order to build team development. Separating out tasks leads to silos Dave P - Time zones are a huge issue - For instance, can lose a day if you miss the email window to somewhere far enough away. Holidays across borders are an issue - someone you need may not be available (although, he says, Dan Antion was there :) on the 4th of July). Dave Buck - Partner on ElastoLab was working one daya week from 8 a - 8 p on ElastoLab. Dave works 8-5 on consultiing projects - not a lot of overlap (hey, try IRC interactions with folks in Germany or Australia :) ). Dan Antion - issue with users, as they time shift and telecommute. Niall - usually use a computer sharing device and work together. Use drawing tool instead of white board, etc.
Side note - the teams here all sound small (other than Squeak)
Avi - Finding out reasons for a decision are possible to find via transcript logs, etc. Question for Niall - what tools for connectivity? - NetMeeting (Windows only). Also used PC Anywhere (not great for pair development, ok for remote management). Have to be able to switch control quickly. Also used COAST and some Lotus Notes plugins. Somewhere in between the other two in ease of use. James Foster - reiterates that with customer being remote, these problems are not unique to remote development. They end up being the same. His customers are hospitals - HIPAA is interpreted as not allowing any data access - so remote help is back to screen descriptrion over the phone, talking through what's happening. The impediment is already there. David Buck - remoteness adds a need for more doc, since issues cannot be directly talked through or demonstrated. How to load up code, build an app, etc.
Dan Antion - Face time - how do you manage the need for periodic face time? Do you go to the users, do they come to you? Neither? Dan finds the conversations to be shorter and more to the point Niall - May be personality - finds it easieir if he knows the persson he's talking to personally. Otherwise, how to judge how to talk with them? Dave P - First face to face after 3 years of email was terrifying - how would it go, would they like each other? Worked out, now use IM. More inclined to talk on phone - before personal meeting, would never have used phone James Foster - all have started with things becoming remote over time, with personal relationships pre-existing. The pre-existing relationship enabled the remote relationship Dave P - have not personally met many of their clients - for custom development, it's all been remote, no personal contact, all email James Foster - Is it part of the Smalltalk culture and the size of the community that allows that? Would it work as well in a bigger culture? Feels like he "knows" people who hee has met only electronically via reputation. Dave P - Will speak to NYC STUG in September - they know him by name and reputation - he does not know them. He's curious how they will take him Niall - things go differently in commercial work than they have in Open Source Camp Smalltalk work. Gives impression of having imagined John Brant by reputation, then in person
Question Managerial? How does that go? Niall - managed such a team with remote folks. Have to take account of remoteness when holding meetings. Can actually run all people as remote even if they are local Dave Buck - not if there's time shifting/time zone issues
Response from Terry Raymond - started working with SOOPS in Holland - started with going over there to meet entire team before starting, so as to enable smoother flow later. Adapts to time shifting by moving his day. Uses IRC/IM extensively.
Dave P - It can all depend on when you "happen to be motivated" as well. There needs to be adaptation to time shifts by all parties. Somehow, have to arrange time overlap. As a self employed consultant, have to deal with "just in time" schedule Niall - Can deal with time shifting by doing some work "after hours" and overlapping from home James Foster - time shifting happens locally as well. Niall - if you are willing to work from home, you can obviate some of these time shifting issues.
Dan Antion - Technology? Are there issues with the existing Smalltalk tools? Are some better/worse than others? Sometimes you 'miss' giving someone what they need to get work done, and the time shift issue just blows that day. Avi - remote development in Squeak was hard without version control systems. Avi spent the last year building tools to solve that issue. Integrated with CVS, but that's non-trivial with the way Smalltalk works (load order, sub/superclass, etc). Ended up bringing a lit of the CVS tools up into Squeak to solve that NiallNetMeeting didn't work with the client's Java based (Swing) UI. Never had such an issue with ST. Avi - Shared Screen - in Squeak, there's Nebraska, a Squeak specific tool. Connect as many as you want, everyone gets their own cursor 9need lots of screen turf). Heading out to Squeak BOF James Foster - underlying tool support for moving source around. VA with ENVY - hard if you are not on the same library manager. Lots of work arounds, but they are work arounds. This is a challenge that does not exist locally, unlike the others. Need truly high bandwidth to address that Dan Antion - works with a high school graduate, segregated to own repository. Same issue Dave P - Expect the client to provide them with what they need, so that they can do the work locally. Use mock objects to simulate databases, etc. Also have to make sure that they are working on a version of their own tools (or compat) that the users have. i.e., no good using an upgrade no one else has. Dave Buck - Source Code Management was easiest issue, using Store. Connected/Disconnected development, used Postgres (no client libs required). Made it easy at that level Niall - ENVY is chatty, too much so for remote development. Export code, share screens, etc. Don't use remote db with ENVY Dave Buck - hard to specify what the developer should load. Used a Wiki to manage that information in a shared space. Worked "well enough" - time shifting was a far bigger issue. Niall - Remote development trained them to do pair programming. Get two people around two keyboards, but share the screen. Hmm - might this solve some of the objections you hear? Solves issues with "not my machine", ergonomics, etc. Learned from remote, and now routine for Niall. Share screens, not keyboard. Get headsets for you phone! - makes a huge, huge difference. Simulates being next to each other Dave Buck - interested in Avi's shared screen work pattern. Niall - Smalltalk tools do that James Foster - agrees that PC Anywhere is subpar, NetMeeting is ok. Citrix and terminal server work pretty well. More than two people can share. There are connectivity issues that make this harder or easier. If IT insists on controlling "everything", then things are hard. Easier to try and "fly under the radar". Working away from IS can actually make things easier, sicne you can avoid policies that don't help. Dave Buck - What if you work on Classified projects? Can't do any of that stuff. Niall - All the tools have bandwidth requirements. Either you have it, or you are screwed. Things like COAST work well even on slow dialup.
Question - what about VNC? Niall - swapping control makes things harder (as per PC Anywhere).
Question - What about division of labor in remote development?
Dan Antion - carve things up into well defined blocks of the system. Dave P - does the same, but more implicitly Terry Raymond from the audience - sharing code in a publish/merge with shared code is hard, with or without remote development. Looking tot rearrange packaging to starat avoiding that. Me - in VW development, we mostly have projects partitioned, not the same level of sharing Terry talks about Niall - Doing pairing to obviate the whole issue. The merge issues were orthogonal to remoteness.
Dan Antion - selling this to non-technical management - How do you do that? How do sell using a developer far away when you have soft and hard costs - even if it's cheaper in raw salary terms?
James Foster "Remote Development is a bad form of development, unless something else is worse" - i.e., someone is moving, corporate office is moving, etc. It may be the best choice given a sub-optimal situation. Dave P - Any resentment that builds up from people who are living/working in less desirable places? "Someone has to stay local" can cause grief? James Foster - It can, but doesn't think so. Niall - another bad but better than failure is working over holidays due to issues. Dave Buck - Agrees with James Foster. If it's not possible, it's not possible. Me - we got remote developers mostly because we couldn't get them any other way Dave P - cannot imagine working any way but remote.
Dan Antion - Wrap up. Slides with questions on the CD. Link on the CD where Dan will update.
Previous Topic
