Forgot your password?
typodupeerror

Submission + - Ask Slashdot: What can Distrubuted Software Development Teams Learn from FLOSS?

An anonymous reader writes: As a long time free software proponent and team lead of a small development team (10+ ppl) in a midsized company I always try to intercorporate my experiences from both worlds. Lately I was confronted with the need to accept new team members from abroad working on the same codebase and I expect to have even more telecommuting people in my team in the future. All this while research suggests that the failure rate of virtual teams could be as high as 70%. On the other hand FLOSS does not seem to suffer from the same problems, despite being developed in a distributed manner more often than not. What can corporations and managers learn from FLOSS to make their distributed teams more successful? Consequently, what FLOSS tools, methods, rules and policies can and should be incorporated into the software development process in a company more often? I'm interested in the opinion of others especially regarding technical issues like source code ownership and revision control system, but also ways of communication, dealing with cultural differences, ...

Submission + - Some of the Greatest Science Fiction Novels Are Fix-Ups

HughPickens.com writes: What do science fiction classics like Asimov's Foundation Trilogy, Bradbury's Martian Chronicles, Van Vogt's Voyage of the Space Beagle, Simak's City, and Sturgeon's More Than Human have in common? Each of them is a "fix-up" — a novel constructed out of short stories that were previously published on their own. "This used to be one standard way to write a science fiction novel — publish a series of stories that all take place in the same world, and then knit them together into a book," says Charlie Jane Anders. "Sometimes a great deal of revision happened, to turn the separate stories into a single narrative and make sure all the threads joined up. Sometimes, the stories remain pretty separate but there are links between them."

The Golden Age science fiction publishing market was heavily geared towards magazines and short stories. And then suddenly, there was this huge demand for tons of novels. According to Andrew Liptak this left many science fiction authors caught in a hard place: Many had come to depend on the large number of magazines on the market that would pay them for their work, and as readership declined, so too did the places in which to publish original fiction. The result was an innovative solution: repackage a number of preexisting short stories by adding to or rewriting portions of them to work together as a single story. There's also something kind of beautiful about a novel in stories says Anders. You get more narrative "payoff" with a collection of stories that also forms a single continuous meta-story than you do with a single over-arching novel — because each story has its own conclusion, and yet the story builds towards a bigger resolution. Fix-ups are a good, representative example of the transition that the publishing industry faced at the time, and how its authors adapted concludes Liptak. "It’s a lesson that’s well-worth looking closely at, as the entire publishing industry faces new technological challenges and disruptions from the likes of self-publishing and micro-press platforms."

Comment Go back to university (Score 1) 416

That's what I did, one and a half year ago, when I found myself in nearly the same position as you are now. I literally felt a burnout syndrome creeping up slowly and that was for me the sign to change. Before you say you can't do that because of your family and so on: I have a 3 year old daughter and my university is 250km away and I don't get any financial support from the public hand. When I first got the idea, I didn't believe it was possible at all, but after some time and more thinking about it, more and more possibilities turned up for realization.

Most important, don't give up easily. What first seems impossible might turn out as a lovely new experience.

Comment Re:TV has been great for our kids (Score 1) 210

Empirical Research (I followed it closely after I became a father myself) shows, that TV does hinder brain development in young children. To put it simple: The medium is the problem not the shows (for example synchronization is skewed between audio and video signals). The younger the kids and the more they watch the worse it gets. Dr. Manfred Spitzer and Dr. Gerald Huether from Germany doing the most work here. The conclusion for me was to throw out the TV! The best decision I did in a long time. ;-) And my daughter? She is now 3 and a half year old. She outperforms 5-6 year olds in our environment in almost all regards (talking, reading glyphs and numbers, simple calculus, motorical skills, singing and most noticeable social skills. Is it because she didn't watch any TV so far? Judge yourself.

Comment Re:Keep up or shut up (Score 1) 785

> don't go running after new stuff simply because it's there.

Like introducing a source code revision system in 2008!!!, as I once had to. Not aiming at you here though, just an example...

There was this senior developer who always did the "hard" stuff on 8051 based embedded applications and thus was highly respected by managers who hadn't any clue. He used to assembler optimize things on a daily basis of course without documentation to make him unfireable. I took over the lead for rewriting the firmware as a switch to a FPGA based soft CPU was due anyway. On my team were: this old guy (around 55 years or something), his fellow coworker (heavily influenced by him) and a freshmen (6 month out of college).

You can't imagine what I went through to introduce SVN and a more modular instead of the former monolithic approach to this team. Not to speak of that crazy idea to look at C++ for a possible successor to C.

At the end the youngster did 2/3 of all the code and was paid 1/2 of what the seniors each got. For me it was an interesting experience stopping them from killing each other in the weekly meetings.

Comment Re:IDE Integration (Score 1) 667

Some large projects are organized and run in ways that require branching and merging. Some are organized and run in ways that don't. Generally these decisions are mandated by factors that have nothing to with any developers preference about source control or anything else, but are based on the external nature of the project at hand or management decisions or whatever.

i can't agree more. in the company i'm in we have switch the development process from a monolitic sourcetree with lots of braches (some of them proved themselfs unmergable, so they have to be maintained seperatly) to a modular aproach. this switch was only possible because we started a complete rewrite of the old code (besides switching from windows to linux at the same time) though. the old windows code is still maintained by a 10 members team, while the rewrite is done by 8 people. constantly branching and merging proved to be a big headache but was unavoidable. now we make heavy use of tags and a sophisticated modul versioning system and we didn't have to branch once 'til now.

Slashdot Top Deals

After all is said and done, a hell of a lot more is said than done.

Working...