Socialtext has always been a perl shop. Traditionally, all the developers do perl, and the entire product has been built in perl (and HTML/Javascript/CSS in the browser, of course).

Thats changing with Socialtext People - a component written in Python. A project was undertaken to prototype the project in Python, and recently the question has arisen within the developer ranks: if almost all of the developers in the company are perlheads, and few have significant Python experience, shouldn't we just port the Python work back into Perl in the long term?

Here's several reasons why not:

1. The python is perfectly functional and there's no functional reason to reimplement it
2. Python itself is a terribly easy language to pick up, especially if you have previous programming experience.
3. The Python ecosystem is much more active than that of Perl these days, at least from what I've seen. It seems to me that there are a lot more of Python application developers in the market. I'd feel more comfortable as a hiring manager looking for application developers who have experience in Python than looking for developers who have Perl app dev experience.
4. A benefit of building with two dynamic languages is that it forces Socialtext developers to live in the chaotic world of heterogeneity and understand the enterprise customer's IT pain. The challenges with LDAP integration are a good toe-dip into this morass, but forcing adherence to (REST) interfaces by virtue of different language environments (including AJAX widgets) is a huge win on this angle.
5. The integration (both physical and logical) of the python and perl components is surfacing some architectural issues and providing motivation for some decomposition of the NLW Perl code. There seems to be universal agreement that the nlw blob is simply too big and impenetrable -- hopefully with external components that can't simply integrate via code hooks, there'll be more motivation to tease out some of the functionality even within the Perl codebase itself (handling of people profile data is a good example). Its very hard in an agile, incremental product development environment to take on architectural refactoring tasks - my hope is that the python work forces some of this work to happen.

Gabe, what are some of the reasons we would want to re-implement it in perl?

I think your point #3 is promoting more myth than fact. Perl jobs and perl developers are very numerous, and the perl community is tremendously active - CPAN is more active than ever.

I don't know where I stand on this particular issue for the Socialtext People module - I probably will go along with the status quo until something changes. I agree that all of our developers can likely hack on the people python code. My only concern is with the code duplication and deployment complexity.

contributed by Luke Closs on Jun 16 11:34am

Luke- I had the most hesitation in writing #3 because it was sure to engender this response, whether I was right or wrong.

I really wanted to avoid a language war post - the main point was that diversity in environments actually has its pluses. It helps to force open APIS and data formats over code. Contracts/agreement and documentation over "just read the source", etc... its more how the real world works.

contributed by Gabe Wachob on Jun 16 1:04pm

We're currently using ~100MB per pre-forked Apache process to run mod_perl+perl-code+data and another ~100MB on top of that to run mod_wsgi+python+data. From an "interpreter memory overhead" standpoint, it makes sense to have just one interpreter.

Maybe we can compile both to parrot, CIL or JVM-bytecode ;)

contributed by Jeremy Stashewsky on Jun 17 9:14am

• Permalink  |
• Comment here

We've been having internal discussions about how we can improve the "cohesiveness" our Story planning inside of our XP-/agile-like Iterations. A practice that's worked in my past job role of an XP Coach/Dev has been to hold a "kick-off" when beginning work on a Story.

The kick-off would be where Devs, QAs and Customers converged on what was actually going to get done -- a review of requirements, story-tests, and effort estimates. The kick-off would mostly happen at the beginning of an iteration, but occasionally mid-way through. It was an adaptation to the Customer having obligations outside of the group and not being 100% available for iteration planning. It was also a way to not "waste time" at the beginning of the iteration for stories that would slip from that iteration anyhow -- being a bit more pragmatic rather than predictive.

It made people happy; the Customer got what they wanted and QAs and Devs were in-sync on what needed to happen. It made the story budget more predictable versus not doing a kick-off. It reduced misunderstanding and brought the team closer together.

It did, however, promote laziness in Planning games before iterations. The "deferring" aspect of the kick-off made the Monday at the start of an iteration less hectic, but made it harder to plan a fully productive iteration (i.e. swapping in/out stories based on renewed estimates)

How can this apply to Socialtext? We aren't co-located; we're distributed. It's difficult for us to "get in the same place" -- even if that's a virtual place -- as a result of this. The transactional cost of communicating is also lot higher than in a face-to-face environment (i.e. you have to type instead of using hand gestures and whiteboards). We also tend to prefer working asynchronously -- a hard-stop to do a kick-off meeting is a pain.

Could this approach help Socialtext? I don't have an immediate answer... and it's probably best to have an answer from the "swarm". So, I've started a discussion internally and we'll see if we can adapt this practice to suit our needs.

I tag GabeW next for blogging.

• Permalink  |
• Comment here

Internally, Lyssa challenged our developers to make at least one public blog post this week. So here's mine - thanks for the poke, Lyssa. :)

This has been a really great year so far for the Socialtext development team, and Socialtext overall. Ingy called it - 2008 is the year of the wiki. But it's also been a time of much change within our team.

Starting in January (rather abruptly, I might add), we collapsed our several mini-teams into a single dev team, and called it the 'Swarm'. Our product managers worked hard to keep a few steps ahead of developers, developers worked hard to support each other, tackle debt and meet their commitments, and our QA team worked hard to keep up with developers and improve our automation. It's been hard work to be sure, some highs and lows, but we're really starting to come together as a team. This is increasingly evident to me as others take over driving roles in our process.

In January, we started the year off with 4 1-week iterations with a hard stop at the end (a company face to face). We were jumping into the agile swarm with two feet, and hoping we could swim. We collectively stumbled through our new process, developing it as we went. For January, I put in a lot of extra work to get iterations set up and fleshed out, reasonably balanced using the best intuition we could find. After the face-to-face, we modified our process to work on a two week iteration, and formally made the iteration lead a role, attracting one of our talented seniour developers, Shawn Devlin. Since then, Shawn has done a great job leading the iterations. I feel shawn has kept us at a steady pace, where we're pushing ourselves, but not thrashing with too much. We've been regular in our attacks against our technical debt, and took a big step of completely removing Alzabo as a dependency. (Those of you intimate with the code will appreciate all the work that went into that).

Stepping back as Shawn took over the iteration lead reins was great - I could focus on our releases, and some core development work. I could get my head right down into the problems, and had complete trust in Shawn (and the people he was working with) to make good decisions. Creating releases with Ken Pier was fun and challenging as we iterated towards a standard release process that fit well with our new development process. We kept the good parts of past process (hopefully), and changed it where it made sense such that now we have a pretty standardized process AND several people that all know how to do it. Documenting the process in our Above the Flow process wiki has allowed us to start a rotating 'pumpking' or release manager role. It has been a great way to make sure the corners of our system are documented and that we're not as dependent on particular people.

As others start creating our latest releases, I'm enjoying stepping back again, and re-focusing on other new problems.

And I tag stash to make a blog post out here.

• Permalink  |
• Comment here

I through a FreeGeek connection, I was invited to talk on a panel for the Vancouver Knowledge Management-ers. Despite it being at 7:30am, I agreed. Here are the notes I'll be taking to speak with, for what they're worth.

Van KM Presentation Notes

About me - I'm a core developer at Socialtext, several years of experience using and deploying wikis.

About Socialtext - http://socialtext.com

• First Enterprise Wiki Company
• Sells hosted wikis and wiki appliances built - software as a service model
• Distributed product team - Executives, main office is in Palo Alto
• Office in New York, and product folks all over North America, 1 in Bangledesh, 1 in Argentina and 1 in Taiwan
• Drink our own champagne

How organizations share knowledge in interesting ways

I'm going to talk first about personal experience with wikis and collaboration, then about some general patterns, and finally about Socialtext's 4 main use-cases.

• Personal examples
• Sophos
• Notes was never used
• Wiki was better, but culture didn't support it
• NEC I18N
• Collaboration with engineers in Japan in 24h - What
• Hub for project planning - How
• Visible to all stakeholders
• Daily development
• Above-the-flow: blogging, documentation, interviews
• In-the-flow: Project planning, Product planning, Meeting Agenda/Notes, Documentation
• Socialtext F2F
• Wiki Eventspace
• Collaborate on meeting ideas beforehand
• Barcamp/unconference style organization
• Tremendously fun, productive and energizing
• In-the-flow vs Above-the-flow
• Traditional KM style forces above-the-flow or nothing
• Traditional KM asks people to step outside the flow of their work, do something extra to give back to the company
• Joe developer, you've worked 60 hours this week, now spend an extra 2 hours to do some extra work - case study, survey, ...
• It's too hard to get people to step above the flow
• People end up doing it in less structured ways anyways, but it's less efficient cause it's done ad-hoc
• Why wikis are different
• What wikis do that is different is they allow people to do their daily work differently, in a way that's more transparent
• NEC i18n - I didn't need to do extra work to get the benefits - I just worked in a more open way - created an enduring searchable asset
• Didn't collaborate because it was the right thing to do - collaborated because it was easier.
• What's changed: we're not adding another layer on everyone's job
• We're providing a better alternative to email - when you do something on a wiki, the knowledege becomes searchable and re-usable
• Eg: Blogging in the company - you mention some random little thing you were working on, now someone else can stumble upon that later. Even a mention is better than not doing a full write-up.
• From Ross: the principle activity is sharing, driven by social incentives. Contribution is simple and unstructured, isn't a side activity and there is permission to participate. Intelligence is provided by participants, both through the act of sharing and simply leaving behind breadcrumbs of attention.
• Use case: review/update the agenda for a meeting
• I wanted to do this last night! - or review the agenda.
• Socialtext offers Van KM group a hosted wiki.

4 core use cases

• Collaborative Intelligence
• 2-way communication between office and field, as well as field-to-field (hub and network)
• Participatory Knowledgebase
• Enable call center & help desk to capture & organize knowledge from customers and internal processes
• Wikis make capturing, organizing and finding the information easier, and part of in-the-flow activities.
• Flexible Client Collaboration
• Collaborating with partners and clients in a shared workspace
• Wikis provide a secure, shared workspace for project collaboration and coordination
• Business Social Networking
• Companies recognize the importance of collaborating with an ecosystem of customers, suppliers, distributors, resellors and other partners.
• Results in a rich source of insights for the company, and a energized and committed group of stakeholders

• Permalink  |
• Comment here

I like this geeky meme of sharing your shell history:

history | awk {'print $2'} | sort | uniq -c | sort -k1 -rn | head
76 cd
51 ll
33 vi
26 svk
26 ssh
24 perl
21 iterad
16 wikrad
14 dtrad
13 sb

-k1 is redundant since sort uses the first column by default.

contributed by daniel@hidden on Apr 17 10:07pm

     70 ls
     68 cd
     39 less
     29 st-admin
     27 cdcur
     24 rb
     19 st-config
     16 vi
     16 sta
     16 jobs

contributed by Rick Scott on May 8 5:43am

• Permalink  |
• Comment here